GNU bug report logs - #79141
31.0.50; The tab-bar-format-align-right cache doesn't take face changes and per-frame faces into account

Previous Next

Full log

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Steven Allen <steven <at> stebalien.com>
Cc: 79141 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#79141: 31.0.50; The tab-bar-format-align-right cache
 doesn't take face changes and per-frame faces into account
Date: Wed, 06 Aug 2025 19:37:37 +0200

Steven Allen <steven <at> stebalien.com> writes:

> Juri Linkov <juri <at> linkov.net> writes:
>> Instead of reverting the change maybe it would be better to add
>> a customizable cache function that anyone could change to adapt caching
>> to own needs by adding more cache keys such as e.g. '(selected-frame)',
>> '(face-all-attributes 'default)', 'face-remapping-alist', ...
>
> That's going to lead to a very poor user experience; we can't reasonably
> ask users just "figure it out". I'd be less concerned if this were just
> a weird edge-case, but causes issues with `global-text-scale-adjust'.
>
> I've looked into what it would take to make a bug-free cache without
> modifying Emacs core and/or advice, and it's not simple. You'd need to
> use `object-intervals' to extract all the face properties, then parse
> the face properties to extract the faces (both inline faces and named
> faces), then use face-all-attributes to extract the attributes. At that
> point, you might as well just recompute the width.

A simpler solution, which might cover most scenarios, would be to only
compute the default line pixel height or pixel height of the tab-bar
face and use that together with the propertized string as the
frame-local cache key.

> If modifying Emacs core is on the table, the simplest solution I can
> think of is to:
>
> 1. Have a per-frame cache.
> 2. Update a global `face-modification-tick' (similar to
> `buffer-modification-tick') whenever faces are updated, invalidating the
> cache whenever this changes.

A face-modification-tick or hook sounds like a great idea, independent
of the problem here. I'd imagine there are plenty of other use cases,
which right now require ugly hacks or potentially expensive
recomputations.

> Unfortunately, that second part would likely require modifying
> `internal-set-lisp-face-attribute' (in C) and it feels kind of icky. On
> the other hand, having the ability to detect that faces have changed
> _is_ kind of useful.

Daniel

Previous Next

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