Subject: bug#75291: closed (Re: bug#75291: Redisplay not updating fringe when face filter changes)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 18 Jan 2025 09:30:02 +0000

Your bug report

#75291: Redisplay not updating fringe when face filter changes

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
75291: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75291
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes
From: Eli Zaretskii <[email-masked]>
To: Daniel Colascione <[email-masked]>
Cc: [email-masked]
Date: Sat, 18 Jan 2025 11:29:16 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> Date: Sat, 04 Jan 2025 15:24:43 -0500
> From: Daniel Colascione <[email-masked]>
> 
> On January 4, 2025 2:12:05 AM EST, Eli Zaretskii <[email-masked]> wrote:
> >> From: Daniel Colascione <[email-masked]>
> >> Cc: [email-masked],  [email-masked]
> >> Date: Fri, 03 Jan 2025 15:57:37 -0500
> >> 
> >> Eli Zaretskii <[email-masked]> 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.
> 
> Directly, without going through face-remap? We already caution against that and should do so more
> strongly. I don't think it's worth supporting direct modification of the 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.
> 
> Somehow, the basic case we have in face-remap seems to work already. I've put a change in master to
> handle the window parameter filter case. Seems to work for me now without observable downsides. No extra
> flickering. There's also a way to turn it off.

No further comments, so I presume the bug is fixed, and I'm closing
it.

Subject: Redisplay not updating fringe when face filter changes
From: Daniel Colascione <[email-masked]>
To: [email-masked]
Date: Thu, 02 Jan 2025 12:30:16 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

Sometimes we don't redraw when its effective face changes indirectly due
to a face filter condition evaluating differently.

An explicit redraw-display works around the problem, but it shouldn't be
necessary and is an efficiency hit.

See the code below:

;; -*- lexical-binding: t -*-

;; emacs -Q

(setf my-window (selected-window))

(dolist (face '(default fringe))
  (face-remap-add-relative
   face `(:filtered (:window foo t) (:background "green"))))

(set-window-parameter my-window 'foo t)

;; During this sit-for, background and fringe should be green
(sit-for 1)
(set-window-parameter my-window 'foo nil)

;; Enable to work around bug
(when nil
  (redraw-display))

;; During this sit-for, background and fringe should be their original
;; color (probably white), but only the background changes.
;; Without redraw-display, the fringe remains green.
(sit-for 1)