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

Previous Next

Package: emacs;

Reported by: Daniel Colascione <dancol <at> dancol.org>

Date: Thu, 2 Jan 2025 17:31:02 UTC

Severity: normal

Merged with 74876

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Michal Nazarewicz <mina86 <at> mina86.com>
To: Daniel Colascione <dancol <at> dancol.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 75291 <at> debbugs.gnu.org
Subject: bug#75291: Redisplay not updating fringe when face filter changes
Date: Thu, 02 Jan 2025 20:24:44 +0100
> Eli Zaretskii <eliz <at> 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»




This bug report was last modified 124 days ago.

Previous Next


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