bug#75291: Redisplay not updating fringe when face filter changes

[Michal Nazarewicz <mina86@mina86.com>]

> Eli Zaretskii <eliz@gnu.org> writes:
>> I think this is bug#74876 again.  I tried to explain there why the way
>> the fringe drawing is implemented doesn't work well with
>> face-remapping (or with changes in the fringe face in general).
>>
>> Maybe I'm missing something, but supporting what this and that bug
>> want would need a rewrite of update_window_fringes (and possibly also
>> the way we record fringes' attributes in the glyph row).

On Thu, Jan 02 2025, Daniel Colascione wrote:
> (BTW: my code uses pre-redisplay-function, not a command hook. I've
> tried it both ways and found the redisplay hook to be more reliable.)

FYI, the actual auto-dim-other-buffers code doesn’t use
pre-command-hook.  It uses hooks for window, buffer or focus changes.

> Anyway, given that the feature has been implemented twice now, maybe we
> can find some way to make it work efficiently?

Since I managed to work-around the issue, I haven’t looked closely at
the low-level details of the redrawing code.  From afar it certainly
looks like it should be easy to force redrawing of fringes only, but
I also trust Eli’s opinion on complexity of this task more than my
impressions.

While I’d like to have a function indicating that particular window’s
fringes need to be updated (maybe something like ‘(force-window-update
window t)’, I won’t have time to work on this any time soon.

> Ideally, a change to a face in which the change couldn't possibly affect
> layout (e.g. changing a background color) would be pretty efficient from
> a redisplay POV, since we wouldn't have to even try to reflow any
> text.

I don’t think it’s that simple.  Even if all you’re changing is colour,
you still need to redraw the text.  At best, without anti-aliasing there
may be some way to optimise it but I doubt complicating the code to
support that would be worth it.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»