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.
|
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)
|
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)
|
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...
|
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)
|
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)
|
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.
|