Subject: bug#71883: [PATCH] Fix tab-bar-auto-width with customized tab-bar-tab-face-function

From: Ship Mints <[email-masked]>
Date: Thu, 4 Jul 2024 17:11:44 -0400

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 <[email-masked]> 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.
>