#2830 4.3pre15: RegEx can't be used to find zero width match
Hello
Thanks again for a wonderful programmers' word processor.
In jEdit 4.3pre2, you can quickly add a comma (or anything else) to the end of every line by
1. Press Ctrl-F
2. Check "Regular expressions"
3. Enter $ under 'Search for'
4. Enter , under 'Replace with'
5. Pressing Alt-A
The above would match the end of the line, and add a comma to the end.
In jEdit 4.3pre9, this does not happen.
You have to instead match a character AND the end of the line. If you want to match empty lines, you have to 'Search For' (\n)$ and 'Replace with' ,$1 or $1, but this only has the desired affect for every second line. Using 'Search for' $(\n) and 'Replace with' ,$1 matches all but the last line in the buffer.
In jEdit 4.3pre2, $ alone on its own would match the end of the line BEFORE the \n. And this would give the desired effect.
Best regards
Carlos
Logged In: YES
user_id=75113
Originator: NO
This was caused by rev 8169. If I remove the check for the empty string match, then this works. Matthieu, since it's not clear from the checkin message, what was that trying to fix?
Carlos, in your particular case you could try matching "(.+)$" and use "$1," as the substitution. But that won't match empty lines.
Logged In: YES
user_id=1101980
Originator: YES
Thank you Vanza for looking into this.
Carlos
Logged In: YES
user_id=1101980
Originator: YES
Hello all
As reported, the above-mentioned functionality has been lost.
The ability to intentionally match just the END of the line has been lost.
In any mult-line buffer matching the regular expression $ returns no results.
It should instead match the end of every line, regardless of whether that line is empty or not.
The inverse, i.e. intentionally matching the START of the line, is possible though. Both $ and ^ are valid regular expressions, so I don't see why the same shouldn't be true for $.
Vanza suggested the changes made in revision 8169.
Regards
Carlos
Logged In: YES
user_id=2023622
Originator: NO
I'll start by saying I really appreciate jEdit.
That being said this issue has been driving me nuts since it was introduced! I never realized how often I use the end of line to make things happen when reformatting or generating code. So I'll just add to the pile and request this be moved up the food chain to be fixed.
Thanks,
Chris
Logged In: YES
user_id=1483238
Originator: NO
The change (r8169) was made to fix a bug #1601718.
[ 1601718 ] jEdit freezes on regexpr "||"
https://sourceforge.net/support/tracker.php?aid=1601718
(I found this from a entry in CHANGES.txt for jEdit 4.3pre9.)
But I think zero-width-match itself should be allowed. I'm looking for
the way to avoid the infinite loop like the care of isMatchingEOL()
introduced to fix a bug #1541009.
[ 1541009 ] 4.3pre6 regexp find: hangs + huge memory waste
https://sourceforge.net/support/tracker.php?aid=1541009
Logged In: YES
user_id=1483238
Originator: NO
Another bug #1959834 was reported for some other zero width match.
https://sourceforge.net/support/tracker.php?aid=1959834
I changed the summary to cover it (while wondering why "^" works), and
set the priority as set in #1959834.
I found that old RESearchMatcher (which was removed in r5443) had
interesting code about zero-width-match in its nextMatch() method.
> // some regexps (eg ^ by itself) have a length == 0, so we
> // implement this hack. if you don't understand what's going on
> // here, then go back to watching MTV
> if(!firstTime && _start == 0 && _end == 0)
> {
Adding some care like the above might solve this problem.
Logged In: YES
user_id=935841
Originator: NO
Since the XSearch plugin still uses the old regex engine, it should behave the same way as the 4.2final regex search did, so until it's fixed in core, you can get the old regex behavior by installing that plugin.
Hello all
I would like to confirm that this bug is still present in jEdit 4.3-pre15.
With "Regular Expressions" turned on
-- Matching with just $ returns no matches.
-- Matching with just ^ returns no matches
Worryingly as well, matching with just ^ takes magnitudes longer than matching with just $
This is a bug that affects me, the development team at my company, and I'm sure many others.
Regards
Carlos
Hi please try again with the latest trunk, it should work now