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 #43 received at 79141 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> daniel-mendler.de, 79141 <at> debbugs.gnu.org
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: Tue, 12 Aug 2025 11:07:08 -0700

Juri Linkov <juri <at> linkov.net> writes:

> close 79141 31.0.50
> quit
>
>> I don't have a clear idea what should the proposed modification hook be
>> used for, so I'm not sure whether we need to expose anything to Lisp.
>> If you or someone else could describe the proposed use of such a tick,
>> I could try providing a more useful advice.
>
> Since no one has an idea how to use such a tick,
> I had to revert the last change.
>
> Anyone who needs a (possibly unreliable) caching version, it's easy
> to create a copy of the existing 'tab-bar-format-align-right',
> add caching to it, and use in 'tab-bar-format'.

I can describe it in this case, at least:

1. Any time any face attribute is updated, the "tick" would be incremented.
2. We'd change `tab-bar--align-right-cache' to be (cached-tick . cached-string).
3. When checking the cache, we'd check if (new-tick . new-string) is
    `equal-including-properties' to (cached-tick . cached-string).

IMO, the real question is: where else would/could we use this. Adding a
new `face-modification-tick' just to support this one cache seems a bit overkill.

Previous Next

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