[Top][All Lists]

[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).


reply via email to

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