GNU bug report logs - #75291
Redisplay not updating fringe when face filter changes

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#75291: closed (Redisplay not updating fringe when face filter
 changes)
Date: Sat, 18 Jan 2025 09:30:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 18 Jan 2025 11:29:16 +0200
with message-id <86wmesbhcj.fsf <at> gnu.org>
and subject line Re: bug#75291: Redisplay not updating fringe when face filter changes
has caused the debbugs.gnu.org bug report #75291,
regarding Redisplay not updating fringe when face filter changes
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
75291: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75291
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Daniel Colascione <dancol <at> dancol.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Redisplay not updating fringe when face filter changes
Date: Thu, 02 Jan 2025 12:30:16 -0500

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)

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 75291-done <at> debbugs.gnu.org
Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes
Date: Sat, 18 Jan 2025 11:29:16 +0200

> Date: Sat, 04 Jan 2025 15:24:43 -0500
> From: Daniel Colascione <dancol <at> dancol.org>
> 
> On January 4, 2025 2:12:05 AM EST, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> From: Daniel Colascione <dancol <at> dancol.org>
> >> Cc: 75291 <at> debbugs.gnu.org,  mina86 <at> mina86.com
> >> Date: Fri, 03 Jan 2025 15:57:37 -0500
> >> 
> >> Eli Zaretskii <eliz <at> 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.
> 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.