[Top][All Lists]

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

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

From: martin rudalics
Subject: Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]
Date: Fri, 17 Feb 2006 08:48:45 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> Maybe what will cut it is: using some kind of after/before-change-function
> (which doesn't have to be in font-lock-after-change-function) detect when
> a terminator is added/removed and in that case add a font-lock-multiline
> property on the whole element (which will cause the whole element to be
> (re)fontified not matter what jit-lock thinks, but the whole-element
> fontification will only happen this one time since the font-lock-multiline
> property is removed afterwards).

Text within "<<" ... ">>" would have to keep its multiline property
forever.  Take:


"bar" wouldn't be highlighted specially.  Insert the closing ">":


"bar" would be highlighted specially. Now overwrite "r" by "z":


Who'd be responsible for highlighting "baz" specially?

Also, checking for the presence of "<<" ... ">>" round window-start just
when the buffer changes is insufficient.  You have to check also
whenever you jump to an arbitrary buffer position preceded by
unfontified text, scroll the window back into unfontified text, or
change your window configuration - lazy-lock.el knows the according

> Another way: move the special treatment of the first line from
> font-lock-keywords to font-lock-syntactic-keywords.  Then the
> after/before-change-function only needs to move
> jit-lock-context-unfontify-pos.

With jit-lock and the "first line" before window-start that wouldn't
change a thing.  `font-lock-fontify-syntactically-region' and
`font-lock-fontify-keywords-region' have identic arguments - at least
when called by `font-lock-default-fontify-region'.  Calling
`font-lock-fontify-syntactically-region' from

(min jit-lock-context-unfontify-pos beg)

instead of `beg' would fix this but you won't get rid of a multiline
property here either.  And, when you insert the contents of an entire
file into the current buffer you would have to fontify them all before
you were able to continue working.

reply via email to

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