Summary: | Kate: #pop prematurely ends parent context if parent ends at an end-of-line | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-syntax-highlighting | Reporter: | Christopher Jacobs <MrChristopherJacobs> |
Component: | framework | Assignee: | KWrite Developers <kwrite-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cullmann, simonandric5, slong, walch.martin, xavier.kde |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 5.49 | |
Attachments: | Testcase syntax file |
Description
Christopher Jacobs
2011-08-18 20:55:23 UTC
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. |