|
From: SourceForge.net <no...@so...> - 2008-10-15 20:17:56
|
Bugs item #1671312, was opened at 2007-02-28 23:06 Message generated for change (Settings changed) made by solrac776 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1671312&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: search and replace Group: Regressive (new to devel) Status: Open Resolution: None Priority: 8 Private: No Submitted By: Carlos (solrac776) Assigned to: Matthieu Casanova (kpouer) >Summary: 4.3pre15: RegEx can't be used to find zero width match Initial Comment: 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 ---------------------------------------------------------------------- Comment By: Carlos (solrac776) Date: 2008-09-28 15:15 Message: 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 ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2008-05-29 20:47 Message: 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. ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2008-05-29 20:42 Message: 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. ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2008-03-04 00:05 Message: 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 ---------------------------------------------------------------------- Comment By: Chris OConnor (cpoconno) Date: 2008-02-29 17:40 Message: 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 ---------------------------------------------------------------------- Comment By: Carlos (solrac776) Date: 2007-08-04 16:02 Message: 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 ---------------------------------------------------------------------- Comment By: Carlos (solrac776) Date: 2007-03-08 21:11 Message: Logged In: YES user_id=1101980 Originator: YES Thank you Vanza for looking into this. Carlos ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (vanza) Date: 2007-03-07 05:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1671312&group_id=588 |