emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: C++-mode: Syntax highlighting: wrong color for funct


From: Alan Mackenzie
Subject: Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]
Date: Wed, 15 Feb 2006 20:13:44 +0000 (GMT)

Hi, Martin!

On Tue, 14 Feb 2006, martin rudalics wrote:

> >>With the matcher function above text in quotation marks won't be
> >>fontified when I start typing stuff like "<<foo" as long as there is
> >>no closing quotation mark.  Now if the closing quotation mark is
> >>entered a few lines below the line containing the opening quotation
> >>mark, font locking won't see the opening quotation mark and the
> >>multiline quotation won't be fontified.


> > Indeed.  You can use contextual refontification, tho:

> >    (if jit-lock-context-unfontify-pos
> >        (setq jit-lock-context-unfontify-pos
> >              (min jit-lock-context-unfontify-pos
> >                   (re-search-backward "<<" limit t))))

> > it's specific to jit-lock, tho.

>Provided the "<<" is still after window-start, though.

>In any case, it's completely inappropriate to search tags in the hook.

[ Small linguistic point: "search" = "durchsuchen"; "search for" =
"suchen".]

>The hook should trigger an idle timed function that would do the search.
>And you could calmly replace the 1000 characters limit by something more
>useful.

I disagree profoundly.  This would interact with other idly timed
functions, some of which might well already be fontifying up to the bits
being searched.  The font locking code is already very complicated, and
this extra complication would make it very difficult indeed to debug.

I think the function should be run from the after-change hook, brute
force fashion.  Should it prove too slow[*], then would be the time to
implement a more sophisticated strategy.

[*] I have a 166 MHz PC, available for testing for "too slow".

-- 
Alan Mackenzie (Munich, Germany)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]