#3396 Find next with regexp "^.*\n" matches only one of two lines
I tried to match a number of lines like this:
16129 | MID_4970798054876149185 | CID_8253430266032120559 | BID_CID_4951531772787116693 |
16130 | MID_4970798054876149185 | CID_8253430266032120559 | BID_CID_4951531772787116693 |
16131 | MID_4970798054876149185 | CID_8253430266032120559 | BID_CID_4951531772787116693 |
16132 | MID_4970798054876149185 | CID_8253430266032120559 | BID_CID_4951531772787116693 |
16133 | MID_4970798054876149185 | CID_8253430266032120559 | BID_CID_4951531772787116693 |
16138 | MID_4970798054876149185 | CID_8253430266032120559 | BID_CID_4951531772787116693 |
16135 | MID_4970798054876149185 | CID_8253430266032120559 | BID_CID_4951531772787116693 |
16134 | MID_4970798054876149185 | CID_8253430266032120559 | BID_CID_4951531772787116693 |
with this regexp ^(\w| ).*\n.
(note that the lines begin with a space)
The regexp matches what I want, but only every other line. I think the reason for this is that it also seems to match the line start on the next line (indicated by highlighting a cursor wide area in the beginning of the next line. See the attached screen shot). When use the same regexp in e.g. Eclipse it matches what I expect.
screen shot
Hi, I don't understand the problem : this regex should match any line starting by a space or a letter ?
what is expected here ?
As I wrote in my initial comment, only every other line is matched. In Eclipse it worked as I expected (that is, every line is matched).
But I don't understand what do you mean by "every other line".
Do you mean that instead of highlighting those lines, all other lines are highlighted ?
In fact if I use your regex
^(\w| ).*\n
no line is highlighted. I have to remove \n
why not use $ instead of \n at the end of your pattern? then it will match every line.
I don't normally match for the \n character itself because $ works on all platforms and \n
might be followed by a linefeed on others.
Why is this reported in "plugin bugs" and not "bugs"? Does this refer to some specific plugin?
I can reproduce the behavior he's describing exactly, on 4.3.2 and on the trunk. Maybe it depends on the platform's newline delimiter: I'm on Linux.
In fact, there's a related but worse issue on the trunk:
1) Change the second line of a buffer to be nothing but the letter a
2) Position your cursor immediately before the a, on the same line
3) Perform a regex search for ^a
Result: No match found, until you wrap the search around to the beginning of the buffer.
I think that the culprit is that lines 107-122 of PatternSearchMatcher.java are ignoring the first "^" match if the beginning of the search is not at the start of the _buffer_, when they should be ignoring the first match if the beginning is not at the start of a _line_.
I think the strange "selecting a non-character at the beginning of the line" displayed in the screenshots is a separate issue.
Here is a simpler reproduction recipe:
1. Having a text like this (spaces are not significant):
1
2
3
4
5
2. Do search with regexp "^.*\n". Now the first line "1" is selected.
3. Do find next (F3 by default).
Expected: The second line "2" is selected.
Actual: The third line "3" is selected.
In contrast, doing Hypersearch gives every line as the occurence. Also,
Find previous matches every line.
Use of "^.*$" can be a good workaround.
Oh ok it is search, I thought it was about the Highlight plugin
Thanks Evan, to pointing out the culprit. I took a look at it.
Unfortunately I found no easy solution for that, as long as we keep the
meaning of the flag "start" of a public abstract method (API);
SearchMatcher#nextMatch().
http://www.jedit.org/api/org/gjt/sp/jedit/search/SearchMatcher.html#nextMatch\(java.lang.CharSequence,%20boolean,%20boolean,%20boolean,%20boolean)
It seems that the flag we really want there is "True if the start of the
text is the beginning of a line", instead of the current one.
I think we need some more analysis to choose a good way to go; for
example, justifications to change the meaning of the flag, or to add a
new method to keep the compatibility, or any other way ...
In SearchAndReplace, the find methods are using that parameter to mean "beginning of buffer" (hence the bug), but the replace methods (see _replace) are already using it to mean "beginning of line". The only plugin in SVN that uses SearchMatcher (other than XSearch, which has its own) is Highlight, and it also uses that parameter to mean "beginning of line".
Thanks Evan again. Now I see a bug in the javadoc, which made me write
the wrong code at r13402 for patch #1923613.
http://jedit.svn.sourceforge.net/jedit/?view=rev&rev=13402
http://sourceforge.net/support/tracker.php?aid=1923613
I'll fix this.
Fixed in r19327.