Menu
▾
▴
#2783 Escaped quotes messed up (since pre9)
closed-fixed
nobody
8
2007-01-29
2007-01-08
No
Hello All,
Attached file showcases a bug with the PHP syntax highlighting.
The syntax highlighting messes up for me with the first escaped quote in the javascript embedded in the PHP echo statement on line 7 and stays messed up until the closing parenthesis on line 25.
As of SVN revision 8320, I can recreate this on a full "native install" (dist) on a Mac 10.4.8, Intel Core Duo.
Kevin
PHP Syntax Highlighter Borker
Logged In: YES
user_id=285591
Originator: NO
This bug appears also in python, but not in java.
It seems the escape char doesn't work anymore for some languages, no idea of the reason yet.
The bug appeared between 4.3pre8 and 4.3pre9
Logged In: YES
user_id=1504176
Originator: NO
This bug appears also in shellscript mode.
Logged In: YES
user_id=1700880
Originator: NO
It looks like, at least with php, this applies only to double quotes. If the string is one enclosed by single quotes then you can add an escaped single quote inside the string without breaking the syntax highlighting.
Logged In: YES
user_id=663176
Originator: NO
I've been working on the PHP mode file quite a lot in the last months (but not in the last weeks) and I cannot reproduce your issue with it.
You can get the php.xml at: http://codeprobe.de/pub/jedit/ - just place it in ~/.jedit/modes/.
I still have some issues to solve (mainly highlighting internal php functions as keywords again, which is a regression to the current mode file).
Logged In: YES
user_id=1700880
Originator: NO
That php.xml file looks like it fixes the quote escaping problem for me.
Logged In: YES
user_id=663176
Originator: NO
I've marked another bug a dupe of this - seems to be caused by the same bug.
Unassigning myself, because it is not a bug in the php.xml mode file - there just seems to be a workaround in the updated one I've referred to.
I think bug 1600458 ("Use ESCAPE attribute from imported rules (bind to rule)") might be related.
Logged In: YES
user_id=285591
Originator: NO
hi, this bug is fixed in SVN (I only removed the ESCAPE rule from the literal delegate rules).
I hope it will not break anything
Please also try other edit modes to see if they have problems too
Logged In: YES
user_id=1271235
Originator: YES
This does indeed seem to fix the issue with escaping quotes and syntax highlighting for at least these modes:
Perl, PHP, C++
It does not seem to work with shellscript double quotes, though that may be my inexperience seeping through. This is my test line:
POEM="He cried, \"Don't shout! / and wave it about, or all the rest will be wanting one too!"
Additionally, jEdit seems noticeably slower when I un/escape a quote, or finish a quote. Basically, when jEdit has to redraw the rest of the buffer, it takes it about a half second.
However, this may be a symptom of another bug 1647652, having to do with redrawing the buffer.
Since I don't know the internals, I'll let someone else decide if this bug needs to re-opened or not.
Logged In: YES
user_id=918212
Originator: NO
What is the problem with your POEM testline? I entered it and it got highlighted correctly
Logged In: YES
user_id=285591
Originator: NO
Hi Vampire, this bug was fixed by the php.xml I put in SVN, but if you use the php.xml from 4.3pre9 you should have a bug (unless Blueyed fixed it, I don't remember well).
The fix was to remove the escape="\" in a delegate rule (the calling rule has the same escape char, and having both escape attribute make them not working. I don't know why but it works :)
http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/modes/php.xml?r1=8106&r2=8791
Logged In: YES
user_id=918212
Originator: NO
I had a look at the code again and I think it is right as it is. Before my changes it was not possible that you have a rule that started with the escape sequence. These rules were simply ignored. Now, after my change, the rules in the delegate take precedence over the escape rule. The problem with the modefiles, or at least in PHP, was, that in the delegate there were an own escape rule that was identical to that of the parent, so the delegates rule took precedence and the parents was ignored and therefore the delegates end was not escaped. I think it is the correct behaviour now and the modefiles relied on a bug which can considered a bug itself. What do you think?
Logged In: YES
user_id=918212
Originator: NO
Ok, as we discussed I fixed the problem at the root of evil now. :-) Maybe we schould revert the changes made to the modefiles, what do you think about that?
The fix is in SVN rev. 9125 and will be in 4.3pre10.