Re: region-based face-remapping

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Tue, 9 Jan 2024 16:31:30 -0500
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel@gnu.org
> 
>  Did you try to use jit-lock-register machinery?
> 
>  Maybe Stefan (CC'ed) will have better ideas.
> 
> I haven’t.  In my (limited) understanding and experience, all the font-lock 
> apparatus is highly tuned to
> after-change modifications.  Here we need to (in addition) mark regions (old 
> and new) as outdated,
> even when the buffer hasn’t changed at all, just based on the movement of the 
> (selected window’s)
> point.  I can know how to expand modified regions with 
> `font-lock-extend-region-functions’, but I don’t
> know how to inform font-lock that “even though you didn’t see changes, trust 
> me, these regions are in
> need of updating”.  I would do this in a PCH, rate-limited by a timer.

It is not true that jit-lock is based on editing changes.  It uses a
special text property to mark regions already fontified, so resetting
that property will cause the corresponding region to be re-fontified
on the next redisplay cycle.

> Maybe it’s as simple as calling `font-lock-flush’ on those regions?  If so, 
> can you call font-lock-flush
> multiple times in a row on overlapping regions without creating issues?  Does 
> font-lock-flush do the
> right (JIT) thing, even when you mark a very large region?

Yes, AFAIU.  But it might be overkill for your case.

> And (this is the big one) how do you handle two chef’s both with their spoons 
> in the font-locking pot
> at the same time?
> 
> 1 Normal font-lock responding to changes in the buffer to refontify regions.
> 2 PCH+timer marks regions for refontification when the buffer-modified-tick 
> or treesitter
>  region-of-interest changes (the former because you can no longer trust that 
> equal regions are in
>  fact equivalent).

Don't worry about that, redisplay and jit-lock know how to deal with
that.

> Seem like there’d be a bunch of unnecessarily repetitive refontification in 
> such a scheme.  And
> marking large regions with `font-lock-flush’ every 75ms as you type also 
> seems problematic.

That could be, but I'm quite sure this can be optimized if it works
for your use case.

> For disclosure, I’ve never used jit-lock-register, and personally find the 
> font-lock documentation light
> on details for implementing non-standard fontification scenarios such as this.

That's why I asked Stefan to join this discussion.

>  That's exactly what JIT font-lock solves, right?  Editing a buffer
>  changes the text, and thus the faces that need to be put on the text
>  change also.  For example, something that was a comment can become
>  non-comment, or vice versa.  Isn't what you describe similar (read:
>  identical), except that the faces themselves are different, i.e. not
>  font-lock faces?
> 
> I guess so. The difficulty seems perhaps the other way around: updating 
> font-lock JIT for both buffer
> modifications and (potentially) point movement (simultaneously, without 
> stepping on each other!).

Again, don't worry about that.  Once redisplay cycle starts, changes
are basically frozen, so whatever was done in the buffer gets
fontified.  If there's a followup change, it will be fontified again.