Version: unspecified (using KDE 4.6.0) OS: Linux When working on a syntax highlighting file for Kate, I came across an instance where I wanted to evaluate a token and pop back into the parent context. The parent context ends if the end of the line is read. When I tested the new syntax highlighting, I found that I was popping an extra step out of the parent context, even though I wasn't at the end of the line. Here's a minimal example of the highlighter syntax, which attempts to find highlight text between backslashes within a string differently than the string itself: <context name="normal" attribute="Normal Text" lineEndContext="#stay"> <DetectChar char="'" attribute="String" context="string"/> </context> <context name="string" attribute="String" lineEndContext="#pop"> <DetectChar char="'" attribute="String" context="#pop"/> <DetectChar char="\" attribute="String" context="string escape"/> </context> <context name="string escape" attribute="Normal Text" lineEndContext="#stay"> <DetectChar char="\" attribute="String" context="#pop"/> </context> Given the input: ... 'this is string text\ escaped text \ and more string text' ... the highlights on "and more string text" are from the "normal" context, rather than the "string" context. Changing the value on the attribute "lineEndContext" from "#pop" to "#stay" fixes the problem (but then incorrectly carries the string context to the next line). Reproducible: Always Steps to Reproduce: 1. Insert the example into a katepart syntax highlighting file (alter the names to avoid clobbering if necessary). 2. Restart Kate (or any other program reading the katepart syntax highlighting files) and open a file. 3. Paste the example input string onto a line Actual Results: "and more string text" is highlighted as Normal Text instead of String. Expected Results: "and more string text" would be highlighted as a string. Kate version: 3.6.0 (wasn't an option in the pulldown list)
Thanks for detailed report, need to look into this.
Seems for me fixed in kate.git master. I tried the above context and got the correct hl for your text: 'this is string text\ escaped text \ and more string text' Complete line red, beside the " escaped text " part.
Thanks for looking into this. I've had a workaround in place since the original report a few versions back and haven't gone back to check that this was now working. I'm not in front of my linux box at the moment, but I can check first thing tomorrow morning.
Thanks, hope it works for you, too. If not, please reopen, want to have this fixed for KDE 4.10, but think it was just a sideeffect of an other bug I fixed some weeks ago.
I've just verified that the given example works as intended. However a related example still has the hilighting problem -- if the escaped text contains a new line, the bugged behavior I described returns. Example: ... 'This is some quoted text \ some escaped text \ and some more quoted text' Should I open a new bug for this (assuming a search doesn't turn up someone else having submitted it)?
We can just reuse this bug ;)
Oh, man, *this* is the reason I've been unable to fix makefile.xml. I can't do a better testcase: suffice to say I get exactly the same issue, when trying to lineContinue an assignment eg: foo = bar $(var) \ $(baz) quux when $(baz) pops it terminates the prior context, and actually jumps all the way back to the start context, not to the grandparent. Same with a command recipe: \t grep foo $(blah) $(blah) \ $(bar) $(baz) You can see it here too, whereby the expansions in the first line pop back to the same context (which has lineEndContext="#pop") but with an expansion after a lineContinue the #pop seems to kill the stack and it goes back to the Start context.
Created attachment 80643 [details] Testcase syntax file
Hello, I encounter a similar issue when embedding a context having lineEndContext="#stay" (named "brace-string") into a hierarchy of contexts having lineEndContext="#pop" (default_context, keyword_context, keyword_option_context). All of this is a testcase, of course. I test it with the following code: *default_context* keyword *keyword_context* -option foobar *keyword_context* keyword *keyword_context* -option "foobar" *keyword_context* keyword *keyword_context* -option {foobar} *keyword_context* keyword *keyword_context* -option {foo bar} *default_context* *default_context* I expected to fall back to the keyword_context after {foo\nbar} but it appears I am falling back to default_context.
This is finally fixed with Kate 5 using KDE Frameworks >= 5.49. It is recommended to use upcoming KDE Frameworks 5.51. The fix came as part of switching the the KSyntaxHighlighting framework, so Kate itself does not have a syntax highlighting engine anymore. Sorry it took sooo long.