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

[Juri Linkov <juri@linkov.net>]

>>>> 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.