GNU bug report logs - #71883
[PATCH] Fix tab-bar-auto-width with customized tab-bar-tab-face-function

Previous Next

Package: emacs;

Reported by: Joseph Turner <joseph <at> breatheoutbreathe.in>

Date: Mon, 1 Jul 2024 20:43:02 UTC

Severity: normal

Tags: patch

Fixed in version 31.0.50

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Adam Porter <adam <at> alphapapa.net>, 71883 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: bug#71883: [PATCH] Fix tab-bar-auto-width with customized tab-bar-tab-face-function
Date: Thu, 4 Jul 2024 17:11:44 -0400
[Message part 1 (text/plain, inline)]
Seems reasonable and thank you for soliciting my input. You're the expert
with tab-bar, I'm just a happy minor contributor. I do have
activities/tab-bar UI features I use and don't want to break. Relevant to
this particular discussion, I rely on activities-tabs face to visually
differentiate activities-controlled tabs (I put a one-pixel box around the
tab).

I do similar things for tabs under other control regimes and have
customized formatters for groups and tabs for both colors and content
(prefixes for group names, prefixes for tab names that have "project"
buffers). And lots of customization around general usage; e.g., you know
about the work I did on optionally collapsing tab group members (Emacs 31!).

-S

On Thu, Jul 4, 2024 at 2:04 PM Juri Linkov <juri <at> linkov.net> wrote:

> >>>> Probably this is not needed after implementing a variable with
> >>>> a predicate function, since it could be set to 'always' to return t.
> >>>> Then activities.el could set this to a function that checks for a
> symbol.
> >>>
> >>> If it seems appropriate, I'd suggest using a list of predicate
> functions,
> >>> which could be used with `run-hook-with-args-until-success'. That way
> there
> >>> wouldn't be any contention with other libraries which also wanted to
> set
> >>> that function.
> >> Would you agree to use add-function instead?  For example, in
> tab-bar.el:
> >>    (defvar tab-bar-auto-width-predicate #'tab-bar-auto-width-faces)
> >> Then in activities.el you could use:
> >>    (add-function :after-while tab-bar-auto-width-predicate
> >> activities-predicate)
> >
> > Isn't advice generally intended for users to use in their configs, rather
> > than for libraries to use?  If we have here an opportunity to design an
> API
> > that is extensible by multiple libraries, wouldn't that be preferable to
> > asking downstream libraries to apply multiple levels of advice and the
> > problems that would raise?
> >
> > IOW, what would the problem be with using
> > `run-hook-with-args-until-success' on a list of functions?  If there is
> > one, I must be missing something.  :)
>
> Advice is intended for users and external libraries.
> Only in core it should be avoided.
>
> But `run-hook-with-args-until-success' is fine with me too.
>
> Let's see what Joseph and Stephane think.
>
[Message part 2 (text/html, inline)]

This bug report was last modified 333 days ago.

Previous Next


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