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

[Eli Zaretskii <eliz@gnu.org>]

> From: Daniel Colascione <dancol@dancol.org>
> Cc: 75291@debbugs.gnu.org,  mina86@mina86.com
> Date: Fri, 03 Jan 2025 15:57:37 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Doesn't that only support face remapping with :filtered attribute?
> >> > What about the more general case where the fringe face is remapped in
> >> > a way that's independent of the windows?
> >> 
> >> That seems to work already. It's only in the fringe that I see problems
> >> --- it just doesn't seem worth it to limit the redraw to the fringe.
> >
> > Sorry, I don't understand.  I _was_ talking about the fringe face.
> 
> I misread your question. To answer it: what are the circumstances in
> which the effective fringe face can change behind our backs?

For example, face remapping via face-remapping-alist.

> Any change to a face attribute proper will cause a redraw anyway.

Changes in face attributes set the frame's redisplay flag, but that
just tells the display engine to disable some radical optimizations,
like considering only the selected window and only the line where the
cursor is.  AFAIU, this will not necessarily cause all the fringes of
all the frame's windows to be redrawn, because we only redraw the
fringes of the glyph rows that we consider changed.

> The face-remap.el functions call force-mode-line-update to make sure
> face remapping lists take effect

force-mode-line-update sets a buffer-specific flag that disables some
redisplay optimizations, but I don't think that guarantees redrawing
of all the fringes of all the windows which show that buffer.

So I'm not sure we have that covered.  But if you have tested that and
this actually work, fine; I don't pretend to know for sure this won't
work.