From: SourceForge.net <no...@so...> - 2008-03-18 21:42:53
|
Patches item #1845842, was opened at 2007-12-06 14:27 Message generated for change (Comment added) made by forevermore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1845842&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Petersen (forevermore) Assigned to: Marcelo Vanzin (vanza) Summary: perl.xml qq([test) syntax higlighting broken Initial Comment: It appears that the regex handler to match the closing parenthesis is matching on the open-bracket character and preventing the string (qq is the same as " ) from closing. ---------------------------------------------------------------------- >Comment By: Chris Petersen (forevermore) Date: 2008-03-18 14:42 Message: Logged In: YES user_id=162554 Originator: YES I'm attaching a new diff that "fixes" the multi-brace-type problems, but it's imho pretty messy.. It does: * unrelated typo fix of word "apostrophe" * unrelated addition of string markup for (var=>val) pattern for hash definitions * split qr// matching out so that it's marked up as regexp instead of string * split all q[qrxw]? patterns into four parts, to handle non-brackets as well as the individual bracket styles (which aren't supposed "nest" mismatched styles -- e.g. qr() should track parens but NOT brackets or braces). It's messy, but it does work properly now except for the fact that it still doesn't honor escaped characters, but I think that's a jEdit bug, not a problem with the mode file. The file in SVN also has a large mismatch between tab and space indentation (some of which possibly comes from my patch), so it might be nice to standardize that for the final check-in, too. File Added: perl.xml.diff ---------------------------------------------------------------------- Comment By: Chris Petersen (forevermore) Date: 2008-03-17 12:10 Message: Logged In: YES user_id=162554 Originator: YES I also completely missed the fact that the original reason for submitting this bug wasn't just because escaped parens weren't being honored, but because jEdit was trying to pair up all potential characters rather than only the single one defined by the qq tag. Thus, if I try to use something like qq( foo[ ) (which is equivalent to " foo[ "), jEdit tries to look for a closing ] before it will close the string. In reality, only the () chars should work for the match because that's the character that follows qq. So there are really two issues here: * escape characters are not being honored * The QUOTED rule is trying to match too many kinds of nested brace/paren characters instead of just the one that is requested by the q operator/tag. ---------------------------------------------------------------------- Comment By: Chris Petersen (forevermore) Date: 2008-03-17 01:22 Message: Logged In: YES user_id=162554 Originator: YES Yes, that's why I said "Something's still not quite working properly, even with this patch." and "I'm wondering if this might be a jEdit bug in the rules matching, or if we need a new feature to allow for escape characters in those sequences." There seems to be some sort of bug in jEdit's parsing code which means that if you want to track balanced parentheses: qq( foo() bar ); # this works fine you cannot then allow for escape parenthesis characters: $x = qq( foo\( bar ); #this doesn't close the string until another ) appears If you apply my original patch, the second case then works fine, but the first is then breaks. This is what leads me to believe that there is a bug in the highlighting engine that is preventing it from honoring escape characters. btw, I apologize for not responding to this sooner -- for some reason I have not been receiving email notifications about replies to bugs here. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (vanza) Date: 2008-02-24 21:42 Message: Logged In: YES user_id=75113 Originator: NO Hi Chris, I tested your patch and, while it does fix the issue you mention, it seems to break some code due to the removal of the QUOTED rule set. The reason I added that was because of this code: eval(q[sub d { my $time=gmtime(); $time=~s/... (...) +(\d+) (........) ..(..)/$2 $1 $4 $3/; print DEBUG "$time <$_[0]>\n"; }]) if $DEBUG; (From: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1659666&group_id=588) Since your patch doesn't keep the brackets balanced, the q[ matching will stop at the "0]>\n" part and highlighting will be incorrect. So unless that's invalid perl code, I think we need some level of balancing, at least, to keep things correct. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2008-02-24 13:39 Message: Logged In: YES user_id=935841 Originator: NO assigning to vanza to review... ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2008-02-24 13:39 Message: Logged In: YES user_id=935841 Originator: NO assigning to vanza to review... ---------------------------------------------------------------------- Comment By: Chris Petersen (forevermore) Date: 2008-01-28 16:28 Message: Logged In: YES user_id=162554 Originator: YES Something's still not quite working properly, even with this patch. Basically, I'm trying to fix the perl syntax highlighting for q//, q(), and other forms of this string quoting method. In recent svn (haven't checked in a few days), the following patterns work fine: q/foo/ q(foo) q( foo() ) However, this fails: q( foo\) ) My initial patch just removed the open/close brace matching rule: <RULES SET="QUOTED" DEFAULT="LITERAL1"> <SPAN_REGEXP NO_LINE_BREAK="FALSE" TYPE="LITERAL1" MATCH_TYPE="OPERATOR" DELEGATE="QUOTED" HASH_CHARS="|[{(/"> <BEGIN>([\[{\(])</BEGIN> <END>~1</END> </SPAN_REGEXP> </RULES> That let q( foo\) ) match properly, but broke q( foo() ). My next attempt was to add an ESCAPE="\" to the span_regexp tag under rules, and to the main one that defines the q() regexp (around line 200), but neither had any effect. I'm wondering if this might be a jEdit bug in the rules matching, or if we need a new feature to allow for escape characters in those sequences. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2008-01-18 13:54 Message: Logged In: YES user_id=935841 Originator: NO moving to the patches tracker... ---------------------------------------------------------------------- Comment By: Chris Petersen (forevermore) Date: 2008-01-18 12:54 Message: Logged In: YES user_id=162554 Originator: YES Attaching a new diff. I don't know why the QUOTED rule was originally created, but perl's qq// type operators don't need to be balanced because they just contain strings. I've also broken qr// format out into a different delegate because it should match other regex pattern colors. Other fixes still include: * typo fix of word "apostrophe" in a comment * color code unquoted hash definitions as literal1 (e.g. a => 'b') File Added: perl.xml.diff ---------------------------------------------------------------------- Comment By: Chris Petersen (forevermore) Date: 2008-01-16 15:08 Message: Logged In: YES user_id=162554 Originator: YES Attaching a diff against svn trunk that works around the qq() syntax matching problem. It also adds a match for literals in hash definitions like (a=>'b') where "a" should be a string), and fixes the "avoid confusion with a sequence of two divisions" section to be a little more restrictive to avoid some false positives. File Added: perl.xml.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1845842&group_id=588 |