Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#609 "^" doesn't match all lines

development
closed-accepted
Tony Balinski
Program (402)
9
2008-10-06
2008-01-12
Bert Wesarg
No

To reproduce:

start nedit in a clean NEDIT_HOME

create the following document and move the cursor back to the beginning:

-----cut-----
1
2
3

5
6
7
-----cut-----

open the search dialog in 'regex' and 'keep' mode and search for "^"

keep pressing "Find" to cycle through all lines

you will see that line 5 is never matched

NEdit release of Jan 12, 2008

Built on: Linux, 486, GNU C
Built at: Jan 12 2008, 10:26:44
With Motif: 2.2.3 [@(#)Motif Version 2.2.3]
Running Motif: 2.2 [unknown]
Server: The X.Org Foundation 10300000
Visual: 16-bit TrueColor (ID 0x23, Default)
Locale: en_US.UTF-8

Discussion

  • Thorsten Haude
    Thorsten Haude
    2008-01-13

    • labels: --> Program
    • milestone: --> development
    • priority: 5 --> 9
    • status: open --> open-accepted
     
  • Thorsten Haude
    Thorsten Haude
    2008-01-13

    Logged In: YES
    user_id=119143
    Originator: NO

    I don't see this bug with the 5.5 binary.

    NEdit 5.5
    Sep 30, 2004

    Built on: Linux, 386, GNU C
    Built at: Oct 1 2004, 15:55:40
    With Motif: 2.1.30 [@(#)Motif Version 2.1.30]
    Running Motif: 2.1 [unknown]
    Server: The XFree86 Project, Inc 40300001
    Visual: 24-bit TrueColor (ID 0x23, Default)
    Locale: de_DE@euro

     
  • Bert Wesarg
    Bert Wesarg
    2008-01-13

    Logged In: YES
    user_id=122956
    Originator: YES

    But you see the bug with current CVS HEAD?

     
  • Bert Wesarg
    Bert Wesarg
    2008-01-13

    Logged In: YES
    user_id=122956
    Originator: YES

    But you see the bug with current CVS HEAD?

     
  • Thorsten Haude
    Thorsten Haude
    2008-01-13

    Logged In: YES
    user_id=119143
    Originator: NO

    Yes, that's why I set the Resolution to Accepted.

     
  • Thorsten Haude
    Thorsten Haude
    2008-01-13

    Logged In: YES
    user_id=119143
    Originator: NO

    It seems that on repeated searches, searchMatchesSelection() (search.c) returns True for empty selections if the search term is not empty but zero-width (as in the example, where ^ matches "").

    So it would solve the problem at hand if we would let searchMatchesSelection() return False for empty selections. Further, since BufGetEmptySelectionPos() is only called by searchMatchesSelection(), we can change *that* to do as promised: "[...] returns TRUE for empty selections" (note not "non-existing selections").

    (It doesn't help that the documentation about selection.zeroWidth is less than clear: 'Width 0 selections aren't "real" selections, but they can be useful when creating rectangular selections from the keyboard.' So since selection.zeroWidth is a char, what does it hold? A boolean? (Would that imply a True for selection.selected?) An "A" for "A-Ok, continue with your work!!"?)

     
  • Thorsten Haude
    Thorsten Haude
    2008-01-20

    Logged In: YES
    user_id=119143
    Originator: NO

    I did the BufGetEmptySelectionPos() transmogrification, please have a look.
    File Added: SF1869862-searchline.2008-01-20.3.diff

     
  • Bert Wesarg
    Bert Wesarg
    2008-09-21

    Unfortunately, the proposed fix breaks backwards search. Thanks anyway.

     
  • I am maintaining some source code which was not originally written by me. Sometimes the work was just as simple as some search/replace with nedit. It is really scared to know this bug in nedit as this is about the very basic function of a text editor. I think we need to have a fix in the next release.

     
  • Tony Balinski
    Tony Balinski
    2008-10-01

    The problem lies in search.c: SearchAndSelect(). If there's a current matching "selection" (even zero-length IIUC), search starts at the start of this selection +/-1 depending on direction; otherwise the current cursor position is used, -1 for backward searches (variable beginPos). Now if a forward search matches *at* this start position, and is zero-length, the search is repeated at beginPos + 1. This is correct when beginPos was set to the cursor position, but this second search shouldn't be done if beginPos was based on current selection, because it has *already* been incremented.

    I have fixed my source code but cannot just now apply my change to the CVS repository. (I'm getting "ssh_exchange_identification: read: Connection reset by peer". Any ideas?)

     
  • waiting for your fix...

     
  • fixed not been committed to 5.6-BETA!!!

     
  • Tony Balinski
    Tony Balinski
    2008-10-06

    • assigned_to: nobody --> ajbj
    • status: open-accepted --> closed-accepted
     
  • Tony Balinski
    Tony Balinski
    2008-10-06

    It is now.

    As it was checked in on MAIN already, and tried by others, I'm closing this now. Anybody finding some other fault can reopen if needs be.