Version: 2.4.1 (using KDE 3.4.1, Debian Package 4:3.4.1-1 (3.1)) Compiler: gcc version 3.3.6 (Debian 1:3.3.6-5) OS: Linux (i686) release 2.6.13.1 Hi, I attach tab-based outline (there is nothing else than just different levels marked by different number of <TAB>s in the beginning of the line; originally from VimOutliner <http://www.vimoutliner.org>). I can create pretty good highlighting for the outline, but I have not figured out how to create folding -- how to say that the region for folding goes from the one line to the last line before the next line of the same indentation? I hoped to find inspiration in LaTeX highlighting file (\section{} are similarly without the closing tag), but apparently it is not possible (or otherwise LaTeX file would have it). Or did I miss something? Will it be possible in the next version of kate/katepart? What about adding new value #pop to endRegion, which would mean that the current line is the beginning of the new region? I.e., if I would have this line <RegExpr attribute="OL6" context="OL6" \ String="^\t{5}[^:\t]" \ beginRegion="level6" \ endRegion="#pop"/> or (for LaTeX) <RegExpr String="\\(part|chapter|section\ |subsection|subsubsection|paragraph\ |subparagraph)(?=[^a-zA-Z])"\ attribute="Structure"\ context="#stay"\ beginRegion="structure" \ endRegion="#pop" />
Created attachment 12628 [details] <TAB>-based outline syntax highlighting file
Created attachment 12629 [details] Example of <TAB>-based outline
Still can't be done in 2.5.6. This also affects other syntaxes, for example diff output. Confirming the wish.
We need a property to indicate that remaining regions of a specified name OR all should be closed.
...except it still has to affect the previous line, because the line you detect this on is already a new region. Are these the same issue or should they be two separate bugs?
I think we should think that in, because there is no way to really detect this. Either, the attribute needs an argument to indicate that closing should be on the above line, or we'd need to assume shomething, like if the match is at column 0, the closings should be at the line above (that would probably suffice for most cases)
> Either, the attribute needs an argument to indicate that closing should > be on the above line, or we'd need to assume something, like if the match is > at column 0, the closings should be at the line above (that would probably > suffice for most cases) I assumed that one of those would be the way to fix this, yes. The second option as-is is wrong, I think you meant to add the condition that the rule is lookAhead=yes :-). But it still sounds risky; at minimum, I think we would need a way to turn it off. My preference would be for the first option; make people tell kate that they need this behavior. Easier closing of multiple levels would help here, but I don't think either is strictly needed for the other to be useful, which was my point. (I get by without for my diff.xml, but it's broken without being able to close on the previous line.) Anyway I'm fine with leaving the two suggestions in the same bug, I was merely making an observation. :-)
On Tuesday 27 February 2007, Matthew Woehlke wrote: > Easier closing of multiple levels would help here, but I don't think either > is strictly needed for the other to be useful, which was my point. (I get > by without for my diff.xml, but it's broken without being able to close on > the previous line.) Anyway I'm fine with leaving the two suggestions in the > same bug, I was merely making an observation. that could either be a seperate property, or a string in the same property.
I'm adding some comments here for a few reasons: * To indicate that I am also interested in seeing this fixed (so I can fold documents using TWiki markup (and my extensions to it)--in folding TWiki marked up text, I (initially) want to fold sections based on TWiki heading markers (---+, ---++, ---++++++ corresponding (and convertible) to HTML H1 thru H6)--there is no ending markup for the TWiki heading markers, they are ended by the next opening marker (or the end of the file/record). * To indicate that I'm not sure whether it should be considered a wish list item or a bug fix. I mean, I thought the lookAhead="true" parameter should allow kate to see that next marker and (if I have the right rules defined in the context), end that section based on the next new marker without consuming that marker so that a new section could be started using that same unconsumed marker (again, assuming I have the right rules defined in the new context that kate should switch on first seeing but not consuming that marker. Re that second point, I really don't care (and am not attempting to argue) whether this should be considered a bug or a wish list/RFE item--my point is that if I'm wrong about this, I have a definite misunderstanding of how lookAhead should work, and I would appreciate any clarification that can be offered.
> I thought the lookAhead="true" parameter should allow kate to see that next > marker and (if I have the right rules defined in the context), end that section > based on the next new marker without consuming that marker so that a new section > could be started using that same unconsumed marker (again, assuming I have the > right rules defined in the new context that kate should switch on first seeing > but not consuming that marker This is correct. The problem is that this results in ending the previous section on the *same* line that the new one begins on, which is not what is desired.
On Monday 05 March 2007 11:24 am, Matthew Woehlke wrote: > ------- Additional Comments From mw_triad users sourceforge net 2007-03-05 17:24 ------- > > I thought the lookAhead="true" parameter should allow kate to see that next > > marker and (if I have the right rules defined in the context), end that section > > based on the next new marker without consuming that marker so that a new section > > could be started using that same unconsumed marker (again, assuming I have the > > right rules defined in the new context that kate should switch on first seeing > > but not consuming that marker > > This is correct. The problem is that this results in ending the previous section on the *same* line that the new one begins on, which is not what is desired. Matthew, Thanks (again)! (Maybe this time it will sink in ;-) regards, Randy Kramer PS: I won't expand the bug report any further by adding my thanks there. ;-)
I thought I had a brilliant idea when I decided to change my end region RegExprs to include a \n, e.g., "\n---\+\+ " but that didn't work at all, and now I think I remember reading somewhere (maybe an SOC proposal) that kate currently doesn't do multi-line searches (i.e., kate can't look for a \n (newline) using a RegExpr search. So: * my brilliant idea didn't work ;-( * but now I'm wondering whether, if that SOC proposal that I think I recalll reading actually does improve kate's search so it can handle multi-line searches, maybe that will solve the problem (or at least let my attempt at a workaround work)?
Hmm, yes, '\nfoo' should match on the line before 'foo', so that should work. So, if KATE gets multi-line regexpr matching, then we can close this. For now I think adding a rule to close a fold on the previous line would be less work, so let's see what happens first...
There are several wishes here: 1. indentation based folding depending on the amount of white spaces at the beginning of the line. Python uses this, too. With KDE 4.11, text folding was rewritten, and we finally have bug-free indentation based folding for Python. Using the indetnation-based folding one achieves the same that is asked for here with tabs. 2. Ending a folding region in the previous line. This works now in KDE 4.11, too: If a folding region stops at column 0, it is moved to the end of the previous line. Therefore, the issues raised here in this report are addressed as far as I can see. If there are more wishes, please open a new report. And please keep in mind: The highlighting is not meant to be a full-fledged parser for languages. So we won't implement arbitrary rules rules e.g. spanning multiple lines.