bugGNU nano - Bugs: bug #50030, searching for anchor \B or \b does...

 
 

bug #50030: searching for anchor \B or \b does not work correctly

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Wed 11 Jan 2017 05:14:15 PM UTC  
 
Severity: 3 - NormalStatus: Fixed
Assigned to: Benno Schulenberg <bens>Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 26 Jan 2017 09:06:16 PM UTC, comment #6:

Fixed in git, 64aa8757.

Searching for and replacing of \b and \B now work correctly, in both directions.

With REG_STARTEND, we cannot set regmatches[0].rm_eo to anything other than the length of the haystack, because otherwise it would find ghost word endings where the search range ends.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sun 15 Jan 2017 04:01:40 PM UTC, comment #5:

There were three problems: \B and \b did not match at the tail of the line during a backward search (which was easily solved by beginning the search at the terminating NUL byte instead of at the final character byte (which might in fact have been the final byte of a multibyte character)), and \> matched every letter of the first word on each line during a backward search (this was caused by regexec not working properly with \> when using REG_STARTEND -- it works fine for the \< anchor -- in short: glibc bug!).

These last two patches should fix the problems completely. Whoever is paying attention, if you can test, that would be great.

(file #39483, file #39484)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 14 Jan 2017 06:57:29 PM UTC, comment #4:

Okay, nearly working. Only a backward search for \B does not match at the tail of a line when a forward search would.

(file #39475, file #39476)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 14 Jan 2017 03:19:20 PM UTC, comment #3:

Brrr... But regexec() does not return multiple matches -- it only returns the first match (and optionally the matches of subexpressions). Useless.

We need the flag REG_STARTEND, to be able to start the search at a different point than the beginning of the haystack. REG_STARTEND is part of glibc since about 2004, so I guess we should be able to use it by now. (Although maybe we will have to test for it? And just leave out the regex abilities when it's not available?)

Anyway, working on a patch now. The forward case is working already here, for both \B and \b. Backward searches are more confusing...

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Sat 14 Jan 2017 12:31:15 PM UTC, comment #2:

The first of the two new patches handles also multibyte characters correctly for the \B case. The second patch makes the lone \b case kind of work -- by itself it matches the last character of a word instead of the character beyond it. Which goes wrong if your try to replace \b (for example, to put quotes around all words).

All this special-casing of BOW anchors and EOW anchors is wrong and just chapuzas. What needs to be done is:

1) Start searching from where the cursor is.
2) For a normal search, ignore any match at the starting point of the search and restart searching from the next character.
3) For a regex search, ignore the first match if it is at the starting position of the search, and take the second match instead. That second match is a true match because it will not be affected by the falsehood of the haystack seeming to begin at the starting point of the search.
4) If there is no second match (when the first match is at the starting point), there is no match at all and we can skip to the next line.
5) If the first match is after the starting point, it is valid and there is no need to look at the second match.

(file #39472, file #39473)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 13 Jan 2017 03:35:14 PM UTC, comment #1:

Attached patch fixes the problem for the \B anchor. But only in the forward direction -- backward searches still skip a match half of the time. And in the forward direction, also the first blank lines is skipped.

Meanwhile I've figured out to search for regexes in Emacs: Ctrl+Alt+S (or Ctlr+Alt+R for the backward direction). (It would have been easy to find out: info emacs regex.)

The patch does not bother with moving a multibyte character left or right after an initial match at the origin -- somehow I couldn't make that work. Also, the patch does not do anything for the \b anchor yet; that is more complicated.

(file #39465)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Wed 11 Jan 2017 05:14:15 PM UTC, original submission:

To reproduce, run 'src/nano +2,21 README'. The cursor sits on the first 'n' of "nano". Now type: ^W M-R \B <Enter>. Surprisingly, the cursor goes to the second 'n' of nano. But the first occurence of a non-word boundary is between the 'n' and the 'a', so the cursor should go sit on the 'a'. And only after an M-W it should go to the second 'n', and on a second M-W it should go to the 'o'. But when inside words, nano skip one boundary on every M-W, and then mistakenly sees the end-of-word boundary as a non-word boundary, because the cursor goes sit on the space /after/ a word. Weird. And /bad/.

I can't figure out how to search for a \B or \b anchor in vim and emacs, but in the 'nice editor' (ne) it works correctly: when searching for \B (Ctrl+Shift+_ \B <Enter>, followed by multiple Ctrl+G), it will go sit on every letter in a word except the first, and will never sit on the space after a word. Great.

Furthermore, \b is not just the beginning-of-word anchor, it is also the end-of-word anchor. So it should match both with the first letter of a word, and with the first non-letter after a word. But nano does only the first -- 'nice editor' does it correctly.

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

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bens (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 14 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 24 Feb 2017 10:20:13 AM UTCbensOpen/ClosedOpen=>Closed
    Thu 26 Jan 2017 09:06:16 PM UTCbensStatusReady For Test=>Fixed
    Sun 15 Jan 2017 04:01:40 PM UTCbensAttached File-=>Added 0001-search-begin-from-where-we-are-to-be-able-to-find-th.patch, #39483
      Attached File-=>Added 0002-search-make-the-b-and-B-anchors-work-correctly-in-bo.patch, #39484
      StatusIn Progress=>Ready For Test
    Sat 14 Jan 2017 06:57:29 PM UTCbensAttached File-=>Added 0001-searching-begin-from-where-we-are-to-be-able-to-find.patch, #39475
      Attached File-=>Added 0002-searching-make-the-b-and-B-anchors-work-correctly-in.patch, #39476
    Sat 14 Jan 2017 06:53:35 PM UTCbensAttached File#39465=>Removed
    Sat 14 Jan 2017 12:31:15 PM UTCbensAttached File-=>Added 0001-searching-begin-the-search-where-we-are-to-be-able-t.patch, #39472
      Attached File-=>Added 0002-searching-make-a-b-anchor-also-match-the-end-of-a-wo.patch, #39473
    Fri 13 Jan 2017 03:35:14 PM UTCbensAttached File-=>Added 0001-searching-begin-the-search-where-we-are-to-be-able-t.patch, #39465
      StatusNone=>In Progress
      Assigned toNone=>bens
    Wed 11 Jan 2017 05:16:34 PM UTCbensSummarysearching for ancor \B or \b does not work correctly=>searching for anchor \B or \b does not work correctly

    Back to the top


    Powered by Savane 3.1-cleanup1