[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master 05a5a94: Correct calculation of CC Mode's font-
From: |
Stefan Monnier |
Subject: |
Re: [Emacs-diffs] master 05a5a94: Correct calculation of CC Mode's font-lock region. |
Date: |
Mon, 30 Mar 2015 20:34:57 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
>> 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