Re: region-based face-remapping

[Eli Zaretskii <eliz@gnu.org>]

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