= Introduction The problem has been reported years ago for diff outputs and more recently for wiki source (see references [1] and [2] below), but I could not find a satisfying answer. Maybe an entry here would help to clarify the need and reason why it could not be answered. = The Problem If you try to write a syntax highlighter that would render the structure of a text like the one you are reading, you will be tempted to use *endRegion* in conjunction with *lookAhead* to say that a line that begins with '= ' should start a region you may call "Section" (that start with a "Header") and close the previous one. An example highlighting code could be: <!-- Rule 1 --> <StringDetect String="= " column='0' context='Header' lookAhead='true' endRegion="H1" beginRegion="H1" /> However, this does not work, as the highligter: - won't believe that the region ends //before// the "= " - even if it would, it would not consider that a region that ends before the first character of a line actually ends by the end of the previous line. Applying a rule such as the "Rule 1" above results in a region that eats up two 'Header' lines. = The Scope As stated in __Introduction__, the problem has been reported for diff output, as well as for wiki texts, such as the present one. It basically impacts //every// attempt to highlight something that is written pure text with the intention of being read by we, humans: wiki or mail of course, but also reports from machines (as in the diff example). = The Doom After reading [1], it looks like it's impossible to cope with the case. I must admit I don't really understand the use case given as answer. But I still wonder. The fact that the highlighter works on a per-line basis certainly does not prevent it to identify an end-of-line, nor to set something in between lines to the due one. = Conclusion Following language.dtd, it seems pretty natural that "Rule 1" would work. The suggester's main request in [1] "RFC: Highlighter suggestion, lookAhead + endregion = end one line earlier" looks pretty good. =References [1] http://comments.gmane.org/gmane.comp.kde.devel.kwrite/10232 [2 ]http://www.archivum.info/kwrite-devel@kde.org/2007-02/00161/Re-Kate-folding-nested-(for-TWiki-Markup).html Reproducible: Always
Possible fix: https://git.reviewboard.kde.org/r/111540/
Git commit 8300891b72f7716f25494d42ab01edba36e7bf12 by Dominik Haumann. Committed on 17/07/2013 at 07:40. Pushed by dhaumann into branch 'master'. allow endRegion and startRegion in combination with lookAhead FIXED-IN: 4.12 REVIEW: 111540 M +44 -39 part/syntax/katehighlight.cpp http://commits.kde.org/kate/8300891b72f7716f25494d42ab01edba36e7bf12
Hi Dominik Thanks for your patch. It looks like: - it succeeds at ending the region before the matching - but fails at ending it at the end of the line before in case the matching occurs at the very beginning of a line Could you confirm ? I'm attaching an highlighting XML and a slightly modified version of the original message for test purposes.
Created attachment 81221 [details] Kind of Wiki highlighting; considers line beginning with "= " as section headers Highlighting code announced in the previous message
Created attachment 81222 [details] Original message with a "= " fixed - testcase
Created attachment 81227 [details] [PATCH] Set end-of-region to the end of the previous line when it occurs at column 0 Dominik Here's a patch to move the "end of region" to the end of previous line when it is at column is 0. It is not benign: it changes in the doHighlight API, in the sense that it removes "const" on "prevLine". It's necessary however. I don't have the whole picture: using the patch may require patches somewhere else. I've tested it against the previous attachments, and it works as expected.
Review request: https://git.reviewboard.kde.org/r/111628/
Thanks, Dominik
@Hulahup: I've added a comment to https://git.reviewboard.kde.org/r/111628/ In essence, I think there are corner cases where the highlighting would break: Say line 5 adds a closing fold to line 4, and line 5 is rehighlighted. Then, each rehighlight adds another closing fold to line 4 (if line 4 is not rehighlighted). In other words, the closing folds add up, which is the wrong behavior. So a correct patch would need to mark line 5 as depending on the previous line, so an extension to KateTextLine is needed. This then indeed should work. Comments welcome.
@Dominik The use case you're pointing out may also presumably dealt with an ad-hoc analysis at addAttribute level, instead of line dependencies, doesn't it? Anyway, it makes me feel the patch is simply at the wrong place. I was originally searching for where the actual folding is performed, not where lines are analysed, but I could not find my way in the code. What do you think? If this fits better, could you guide me through the code?