[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: A problem with highlighting: matching blank lines
From:       Bruce Hoult <bruce.hoult () gmail ! com>
Date:       2005-02-07 22:17:44
Message-ID: 391c06200502071417eb1cd3 () mail ! gmail ! com
[Download RAW message or body]

On Mon, 7 Feb 2005 22:45:15 +0100, Anders Lund <anders@alweb.dk> wrote:
> On Monday 07 February 2005 22:34, Christoph Cullmann wrote:
> > I would like more a new tag like <DectectBlankLine> instead of an
> > additional attribute for context
> 
> Blank lines are skipped during the highlighting loop. So we'd either have to
> drop that (meaning try all the current context's rules on the empty string
> which makes no sense), or treat such a rule specially. After all, the
> highlighting operates on the current line.

I'm not sure that it makes no sense.  Most of them (other than
suitable RegExprs) won't match, of course, but that can be discovered
very quickly in almost all the matchers with a simple test on the line
length and return.  Many don't have that at present -- and blindly
just assume they can grab the first character -- but it's not a big
job to change that and I can't see it making a big speed difference. 
*Especially* when you consider that at the moment every rule is tried
at every possible offset in each line, which can be dozens of times.

There is, however, a lot of other code written with the assumption
that a zero-length match means "no match" so quite a lot of work may
be needed in KateHighlighting::doHighlight.


As motivation for why matching zero length lines is useful (needed,
I'd say), consider file formats such as RFC822 email headers and other
things that use the same general format (news, HTTP, MIME, the Dylan
programming language).  You want a different formatting context for
the header than you do for the body and the way you find the end of
the header is to look for a blank line.

I don't mind whether a RegExpr of "^$" (or anything else that matches
a blank line -- and other stuff -- such as "^\s$") is made to work, or
a new tag or attribute is added.  It does look as if a new attribute
on context is the least coding.

-- Bruce
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]