Re: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]

[martin rudalics <rudalics@gmx.at>]

 >>DONE.  In the process, I moved the processing of font-lock-lines-before
 >>from font-lock-default-fontify-region into
 >>font-lock-after-change-function and jit-lock-after-change, so as to be
 >>able to stop them interfering with eachother.
 >
 >
 > As discussed and agreed in this list, font-lock-lines-before should simply
 > be removed since it is subsumed by the new feature.
 >
 > Also, I thought we had agreed that this new feature should be in
 > f-l-default-fontify-region rather than f-l-after-change-function.  I believe
 > it is *wrong* for it to be in f-l-after-change-function where it is mostly
 > useless: you can already get the same result by using an
 > (non-f-l)after-change-functions hook that sets the
 > font-lock-multiline property.

Any functionality replacing `font-lock-lines-before' should be able to
handle the following `jit-lock' related scenario: "Display an arbitrary
range of a buffer such that the area preceding that range has not been
(syntactically- or keyword-) fontified yet."  With other words, any such
functionality should handle changes of `window-buffer', `window-start',
or `window-height' as well.  `after-change-functions' is of no use here.

An aside: About 20 major modes set `font-lock-syntactic-keywords'
currently.  None of them sets `font-lock-syntactically-fontified'.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642