bugGNU nano - Bugs: bug #56845, +/string does not find the...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #56845: +/string does not find the "string" at the start of the file

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Sun 01 Sep 2019 12:33:51 PM UTC  
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  Benno Schulenberg <bens> Open/Closed:  Open

Mon 02 Sep 2019 07:11:28 AM UTC, comment #4: 

Ah, yes, nice!  Setting 'skipone' to FALSE for a forward search from the command line works.  Thanks.  Patch applied (with modified commit message) and pushed to master: commit 8853bc44.

(The wipe_statusbar() is needed for a backward search, to clear the "Search Wrapped" message.  For symmetry it is done for both directions.  It also distinguishes a +/search from a normal load.)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sun 01 Sep 2019 08:22:29 PM UTC, comment #3: 

Does findnextstr() already support doing this with its skipone parameter? Attached patch seems to work.

Why did the code already clear HUSH messages? Goto line displays the "Read N lines" message, but search removes it. The wipe_statusbar() on HUSH code should be removed, unless it has a purpose other than removing the "Read N lines" message.

(file #47427)

Brand Huntsman <brand>
Sun 01 Sep 2019 03:11:14 PM UTC, comment #2: 

Attached is the more general patch that works also for regexes.  It's not just a bunch of extra lines, it's ugly too.  :|

(file #47420)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sun 01 Sep 2019 02:56:19 PM UTC, comment #1: 

Attached patch works for plain strings, but not for regexes, so it's not good enough.  But changing the starting position to EOF for forward searches is a nuisance: when nothing is found, the position has to be changed back to top of file.  That's a bunch of lines for one special, uncommon case.  :|

(file #47419)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sun 01 Sep 2019 12:33:51 PM UTC, original submission:  

(Original report by Derek Wolfe in bug #54535, comment #37.)

To reproduce, run:

  src/nano  +/201  NEWS

Note that the cursor sits on "2019.06.18 - GNU nano 4.3", instead of on "2019.08.25 - GNU nano 4.4" at the start of the file.

When giving a search string at startup (+/string), the user will expect the cursor to be placed on the very first occurrence of that string, also when that string is right at the start of the file.  This is so because the user specifies the search string before the file is even loaded, so conceptually the search starts in some limbo space before the actual start of the file and an occurrence at the start of the file will and should be found.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by brand (Updated the item)
  • -email is unavailable- added by bens
  • -email is unavailable- added by bens
  • -email is unavailable- added by bens (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-09-02 bens StatusIn Progress => Fixed
    2019-09-01 brand Attached File- => Added find-queries-at-start-of-file-when-searching-from-command-line.patch, #47427
    2019-09-01 bens Attached File- => Added start-at-EOF-for-forward-search.patch, #47420
    2019-09-01 bens Attached File- => Added special-case-an-occurrence-at-head-of-file.patch, #47419
        StatusNone => In Progress
        Carbon-Copy- => Added dwwolfe1
        Carbon-Copy- => Added brand

    Back to the top


    Powered by Savane 3.5