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

Previous Next

Full log

Message #8 received at 75291 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 75291 <at> debbugs.gnu.org
Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes
Date: Thu, 02 Jan 2025 19:50:29 +0200

> From: Daniel Colascione <dancol <at> dancol.org>
> 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)

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

Previous Next

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