Re: [Emacs-diffs] master 05a5a94: Correct calculation of CC Mode's font-lock region.

[Stefan Monnier]

>> Please use the present tense, even for "rename" ;-)
> Do you mean I should change the commit message on that commit?  Can I
> actually do that?

No, what's done is done.

> ensure (start end) covered the location where re-rendering was needed,
> the re-rendering still failed to take place.

How can you tell.  What does "re-render" mean for you?
`jit-lock-force-redisplay' is not meant to re-run font-lock.  It is only
meant to refresh the display so that it reflects the `face' properties
that were already set by an earlier jit-lock run.

> However, when I tried changing L13 to set 'fontified to nil, the
> re-rendering happened even when the location was far before `start'.

Setting it to nil will cause that forces redisplay to not only re-render
the buffer but also re-fontify (i.e. re-run font-lock).  This is a very
different need from the one jit-lock-force-redisplay is designed to address.

> Assuming that jit-lock-force-redisplay is not going to work, it follows
> that any buffer bits to be fontified which come earlier than
> after-change-functions's `beg' need to have their 'fontified text
> property set to nil, and this needs to happen at after-change time
> (during redisplay is too late).  This necessity even applies to
> extending change regions to whole lines.

Yes and no.  The current code indeed has a weakness in that there's no
way for a jit-lock-function (e.g. font-lock) to tell jit-lock which part
of the buffer it actually did re-fontify (so that jit-lock can in turn
use jit-lock-force-redisplay when needed).  I've been meaning to address
this for years, but never got around to it.  This is only a problem when
a change on one line affects the display on a *previous* line (and this is
done via font-lock-extend-region-functions), so it's rarely problematic.

This said, if a change on line N needs some other line M<N to be
refreshed, and yet font-lock-extend-region-functions doesn't move beg
from N to M (because the two don't need to be refreshed at the same
time, for example), there's yet another way to handle it, which is to
use jit-lock-multiline (which affects jit-lock-context's fontification,
so line M will be refreshed after jit-lock-context-time).


        Stefan