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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71883 in the body.
You can then email your comments to 71883 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Emacs Bugs Mailing List <bug-gnu-emacs <at> gnu.org>
Cc: Adam Porter <adam <at> alphapapa.net>, Ship Mints <shipmints <at> gmail.com>
Subject: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Mon, 01 Jul 2024 13:42:20 -0700

[Message part 1 (text/plain, inline)]

The function tab-bar-auto-width determines which tabs to automatically
resize based on the face applied to each tab's text.  If the face is one
of tab-bar-auto-width-faces, then the tab gets resized.  However, if
either tab-bar-tab-face-function or tab-bar-tab-group-face-function is
set to a function which does not apply one of tab-bar-auto-width-faces,
then the tabs which have a different face are not auto resized.

A real-world example of this issue is in activities.el:

https://github.com/alphapapa/activities.el/issues/76

In the proposed patch, instead of checking each tab's face, we check
that the symbol at the start of each tab keymap matches

(rx bos (or "current-tab" "tab-" "group-"))

Thank you!!

Joseph

[0001-Auto-resize-based-on-keymap-symbol-not-face.patch (text/x-diff, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 71883 <at> debbugs.gnu.org, Adam Porter <adam <at> alphapapa.net>,
 Ship Mints <shipmints <at> gmail.com>, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Tue, 02 Jul 2024 09:55:08 +0300

> The function tab-bar-auto-width determines which tabs to automatically
> resize based on the face applied to each tab's text.  If the face is one
> of tab-bar-auto-width-faces, then the tab gets resized.  However, if
> either tab-bar-tab-face-function or tab-bar-tab-group-face-function is
> set to a function which does not apply one of tab-bar-auto-width-faces,
> then the tabs which have a different face are not auto resized.
>
> A real-world example of this issue is in activities.el:
>
> https://github.com/alphapapa/activities.el/issues/76

Thanks for the request.

Maybe activities.el could add its face to tab-bar-auto-width-faces?

If not, then what about allowing tab-bar-auto-width-faces to have
the value t that means that all tabs should be resized regardless of
what faces they have.

> In the proposed patch, instead of checking each tab's face, we check
> that the symbol at the start of each tab keymap matches
>
> (rx bos (or "current-tab" "tab-" "group-"))

> -(defvar tab-bar-auto-width-faces
> -  '( tab-bar-tab tab-bar-tab-inactive
> -     tab-bar-tab-ungrouped
> -     tab-bar-tab-group-inactive)
> -  "Resize tabs only with these faces.")

Sorry, we can't remove the existing variable to not break user configs.

> @@ -1250,8 +1244,8 @@ tab-bar-auto-width
> -        (if (memq (get-text-property 0 'face (nth 2 item))
> -                  tab-bar-auto-width-faces)
> +        (if (string-match-p "\\`\\(?:current-tab\\|\\(?:group\\|tab\\)-\\)"
> +                            (symbol-name (nth 0 item)))

Matching the symbol name with the hard-coded regexp doesn't look right.
Maybe better to add a new variable that contains a predicate function?
When it returns t then resize.

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

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 71883 <at> debbugs.gnu.org, Adam Porter <adam <at> alphapapa.net>,
 "Joseph Turner via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Tue, 2 Jul 2024 09:42:42 -0400

[Message part 1 (text/plain, inline)]

I like both ideas. Supporting t seems idiomatic. `activities' could add its
face to the list, or a user in her configuration via documentation.

On Tue, Jul 2, 2024 at 2:59 AM Juri Linkov <juri <at> linkov.net> wrote:

> > The function tab-bar-auto-width determines which tabs to automatically
> > resize based on the face applied to each tab's text.  If the face is one
> > of tab-bar-auto-width-faces, then the tab gets resized.  However, if
> > either tab-bar-tab-face-function or tab-bar-tab-group-face-function is
> > set to a function which does not apply one of tab-bar-auto-width-faces,
> > then the tabs which have a different face are not auto resized.
> >
> > A real-world example of this issue is in activities.el:
> >
> > https://github.com/alphapapa/activities.el/issues/76
>
> Thanks for the request.
>
> Maybe activities.el could add its face to tab-bar-auto-width-faces?
>
> If not, then what about allowing tab-bar-auto-width-faces to have
> the value t that means that all tabs should be resized regardless of
> what faces they have.
>
> > In the proposed patch, instead of checking each tab's face, we check
> > that the symbol at the start of each tab keymap matches
> >
> > (rx bos (or "current-tab" "tab-" "group-"))
>
> > -(defvar tab-bar-auto-width-faces
> > -  '( tab-bar-tab tab-bar-tab-inactive
> > -     tab-bar-tab-ungrouped
> > -     tab-bar-tab-group-inactive)
> > -  "Resize tabs only with these faces.")
>
> Sorry, we can't remove the existing variable to not break user configs.
>
> > @@ -1250,8 +1244,8 @@ tab-bar-auto-width
> > -        (if (memq (get-text-property 0 'face (nth 2 item))
> > -                  tab-bar-auto-width-faces)
> > +        (if (string-match-p
> "\\`\\(?:current-tab\\|\\(?:group\\|tab\\)-\\)"
> > +                            (symbol-name (nth 0 item)))
>
> Matching the symbol name with the hard-coded regexp doesn't look right.
> Maybe better to add a new variable that contains a predicate function?
> When it returns t then resize.
>

[Message part 2 (text/html, inline)]

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: 71883 <at> debbugs.gnu.org, Adam Porter <adam <at> alphapapa.net>,
 "Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>, Ship Mints <shipmints <at> gmail.com>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Tue, 02 Jul 2024 09:25:10 -0700

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

>> The function tab-bar-auto-width determines which tabs to automatically
>> resize based on the face applied to each tab's text.  If the face is one
>> of tab-bar-auto-width-faces, then the tab gets resized.  However, if
>> either tab-bar-tab-face-function or tab-bar-tab-group-face-function is
>> set to a function which does not apply one of tab-bar-auto-width-faces,
>> then the tabs which have a different face are not auto resized.
>>
>> A real-world example of this issue is in activities.el:
>>
>> https://github.com/alphapapa/activities.el/issues/76
>
> Thanks for the request.
>
> Maybe activities.el could add its face to tab-bar-auto-width-faces?

Unfortunately, this isn't possible.  activities.el sets
tab-bar-tab-face-function to

(defun activities-tabs--tab-bar-tab-face-function (tab)
  "Return a face for TAB.
If TAB represents an activity, face `activities-tabs' is added as
inherited."
  ;; TODO: Propose a tab-bar equivalent of `tab-line-tab-face-functions'.
  (let ((face (funcall activities-tabs-tab-bar-tab-face-function-original tab)))
    (if (activities-tabs--tab-parameter 'activity tab)
        `(:inherit (activities-tabs ,face))
      face)))

so there's no face symbol to match against.

> If not, then what about allowing tab-bar-auto-width-faces to have
> the value t that means that all tabs should be resized regardless of
> what faces they have.

Would you be willing to send a patch with this idea?

>> In the proposed patch, instead of checking each tab's face, we check
>> that the symbol at the start of each tab keymap matches
>>
>> (rx bos (or "current-tab" "tab-" "group-"))
>
>> -(defvar tab-bar-auto-width-faces
>> -  '( tab-bar-tab tab-bar-tab-inactive
>> -     tab-bar-tab-ungrouped
>> -     tab-bar-tab-group-inactive)
>> -  "Resize tabs only with these faces.")
>
> Sorry, we can't remove the existing variable to not break user
> configs.

You're right.

>> @@ -1250,8 +1244,8 @@ tab-bar-auto-width
>> -        (if (memq (get-text-property 0 'face (nth 2 item))
>> -                  tab-bar-auto-width-faces)
>> +        (if (string-match-p "\\`\\(?:current-tab\\|\\(?:group\\|tab\\)-\\)"
>> +                            (symbol-name (nth 0 item)))
>
> Matching the symbol name with the hard-coded regexp doesn't look right.
> Maybe better to add a new variable that contains a predicate function?
> When it returns t then resize.

What would be passed to the predicate function?

Thanks for the review!

Joseph

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

From: Juri Linkov <juri <at> linkov.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 71883 <at> debbugs.gnu.org, Adam Porter <adam <at> alphapapa.net>,
 Ship Mints <shipmints <at> gmail.com>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Tue, 02 Jul 2024 20:34:43 +0300

>> If not, then what about allowing tab-bar-auto-width-faces to have
>> the value t that means that all tabs should be resized regardless of
>> what faces they have.
>
> Would you be willing to send a patch with this idea?

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.

>>> In the proposed patch, instead of checking each tab's face, we check
>>> that the symbol at the start of each tab keymap matches
>>>
>>> (rx bos (or "current-tab" "tab-" "group-"))
>>
>>> -(defvar tab-bar-auto-width-faces
>>> -  '( tab-bar-tab tab-bar-tab-inactive
>>> -     tab-bar-tab-ungrouped
>>> -     tab-bar-tab-group-inactive)
>>> -  "Resize tabs only with these faces.")
>>
>> Sorry, we can't remove the existing variable to not break user
>> configs.
>
> You're right.

But we could deprecate tab-bar-auto-width-faces in Emacs 30,
and in Emacs 31 replace it with a function that matches a symbol name
like in your patch.  Then users will have time to get the function into use.

>>> @@ -1250,8 +1244,8 @@ tab-bar-auto-width
>>> -        (if (memq (get-text-property 0 'face (nth 2 item))
>>> -                  tab-bar-auto-width-faces)
>>> +        (if (string-match-p "\\`\\(?:current-tab\\|\\(?:group\\|tab\\)-\\)"
>>> +                            (symbol-name (nth 0 item)))
>>
>> Matching the symbol name with the hard-coded regexp doesn't look right.
>> Maybe better to add a new variable that contains a predicate function?
>> When it returns t then resize.
>
> What would be passed to the predicate function?

I think only 'item' should be passed to the function,
there is no other useful information here.

Then in Emacs 30 this function could check for a face name
in (nth 2 item), and in Emacs 31 a symbol name in (nth 0 item).

But only if a symbol name covers all cases currently supported
by the face name.  Let's see with the face->symbol mapping:

  tab-bar-tab -> current-tab
  tab-bar-tab-inactive -> tab-N
  tab-bar-tab-ungrouped -> tab-N, unfortunately there is no separate symbol
  tab-bar-tab-group-inactive -> group-N
  tab-bar-tab-group-current -> there is no current-group, but this could be added:

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index edec6543a82..66fb9490ce8 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1044,7 +1044,7 @@ tab-bar--format-tab-group
 when the tab is current.  Return the result as a keymap."
   (append
    `((,(intern (format "sep-%i" i)) menu-item ,(tab-bar-separator) ignore))
-   `((,(intern (format "group-%i" i))
+   `((,(intern (if current-p "current-group" (format "group-%i" i)))
       menu-item
       ,(if current-p
            (condition-case nil

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

From: Adam Porter <adam <at> alphapapa.net>
To: Juri Linkov <juri <at> linkov.net>, Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 71883 <at> debbugs.gnu.org, Ship Mints <shipmints <at> gmail.com>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Tue, 2 Jul 2024 18:10:07 -0500

Thanks to all for working on this.

On 7/2/24 12:34, Juri Linkov 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.

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

From: Juri Linkov <juri <at> linkov.net>
To: Adam Porter <adam <at> alphapapa.net>
Cc: 71883 <at> debbugs.gnu.org, Ship Mints <shipmints <at> gmail.com>,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Wed, 03 Jul 2024 09:27:17 +0300

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

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

From: Adam Porter <adam <at> alphapapa.net>
To: Juri Linkov <juri <at> linkov.net>
Cc: 71883 <at> debbugs.gnu.org, Ship Mints <shipmints <at> gmail.com>,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Wed, 3 Jul 2024 14:50:24 -0500

On 7/3/24 01:27, Juri Linkov 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.  :)

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

From: Juri Linkov <juri <at> linkov.net>
To: Adam Porter <adam <at> alphapapa.net>
Cc: 71883 <at> debbugs.gnu.org, Ship Mints <shipmints <at> gmail.com>,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Thu, 04 Jul 2024 20:57:23 +0300

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

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: Re: 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)]

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: Adam Porter <adam <at> alphapapa.net>, 71883 <at> debbugs.gnu.org,
 Ship Mints <shipmints <at> gmail.com>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Mon, 15 Jul 2024 22:12:46 -0700

[Message part 1 (text/plain, inline)]

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

> Let's see what Joseph and Stephane think.

Please see the attached patches, where the first three commits are
intended to be applied to the emacs-30 branch, and the final commit
removes the obsolete `tab-bar-auto-width-faces' on master.

Does this change warrant a NEWS entry?

Thanks!

Joseph

[0001-Use-current-group-symbol-for-current-tab-group-item.patch (text/x-diff, attachment)]

[0002-Add-abnormal-hook-to-determine-which-tabs-to-auto-wi.patch (text/x-diff, attachment)]

[0003-Mark-tab-bar-auto-width-faces-obsolete.patch (text/x-diff, attachment)]

[0004-Remove-obsolete-tab-bar-auto-width-faces.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, shipmints <at> gmail.com,
 juri <at> linkov.net
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Wed, 17 Jul 2024 14:18:52 +0300

> Cc: Adam Porter <adam <at> alphapapa.net>, 71883 <at> debbugs.gnu.org,
>  Ship Mints <shipmints <at> gmail.com>
> Date: Mon, 15 Jul 2024 22:12:46 -0700
> From:  Joseph Turner via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Juri Linkov <juri <at> linkov.net> writes:
> 
> > Let's see what Joseph and Stephane think.
> 
> Please see the attached patches, where the first three commits are
> intended to be applied to the emacs-30 branch, and the final commit
> removes the obsolete `tab-bar-auto-width-faces' on master.

I'm not sure I understand why they need to be installed on emacs-30.
Is this a regression in Emacs 29 or Emacs 30?  What bad things will
happen if we install the changes on master instead>

> Does this change warrant a NEWS entry?

Yes, since you are adding a hook variable.  Obsolescence of a variable
also requires a NEWS entry.

> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
> Date: Mon, 15 Jul 2024 22:07:22 -0700
> Subject: [PATCH 4/4] Remove obsolete tab-bar-auto-width-faces
> 
> * lisp/tab-bar.el (tab-bar-auto-width-faces):  Remove.
> (tab-bar-auto-width): Only run tab-bar-auto-width-functions.

We don't usually remove a variable one major release after it has been
obsoleted.  It's too soon.

Thanks.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, shipmints <at> gmail.com,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Fri, 19 Jul 2024 09:42:41 +0300

>> Please see the attached patches, where the first three commits are
>> intended to be applied to the emacs-30 branch, and the final commit
>> removes the obsolete `tab-bar-auto-width-faces' on master.

Thanks for the patches, although I agree with Eli that the changes
on emacs-30 should be minimal.

> I'm not sure I understand why they need to be installed on emacs-30.
> Is this a regression in Emacs 29 or Emacs 30?  What bad things will
> happen if we install the changes on master instead>

Replacing hard-coded logic with customizable variable
for external packages like activities.el is needed
as soon as possible on emacs-30 because hard-coded logic
hinders the use of packages.

However, there is no hurry to change the default behavior
to match a symbol name instead of checking face names.
Therefore I think better to move the existing code

  (memq (get-text-property 0 'face (nth 2 item)) tab-bar-auto-width-faces)

to the new predicate function on emacs-30.  Then activities.el
can change it to another function that matches a symbol.

Then on master the default body on the new predicate
could be replaced from checking the face to match a symbol.
Also changes in tab-bar--format-tab-group should be on master as well.

>> Does this change warrant a NEWS entry?
>
> Yes, since you are adding a hook variable.  Obsolescence of a variable
> also requires a NEWS entry.

Then addition of tab-bar-auto-width-functions requires a NEWS entry on emacs-30.
And obsolescence of tab-bar-auto-width-faces requires a NEWS entry on master.

>> * lisp/tab-bar.el (tab-bar-auto-width-faces):  Remove.
>> (tab-bar-auto-width): Only run tab-bar-auto-width-functions.
>
> We don't usually remove a variable one major release after it has been
> obsoleted.  It's too soon.

Indeed, it could be obsoleted on master.
This will provide a minimal set of changes on emacs-30.

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Thu, 25 Jul 2024 11:11:01 -0700

[Message part 1 (text/plain, inline)]

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

>> I'm not sure I understand why they need to be installed on emacs-30.
>> Is this a regression in Emacs 29 or Emacs 30?  What bad things will
>> happen if we install the changes on master instead>

No regression.

> Replacing hard-coded logic with customizable variable
> for external packages like activities.el is needed
> as soon as possible on emacs-30 because hard-coded logic
> hinders the use of packages.
>
> However, there is no hurry to change the default behavior
> to match a symbol name instead of checking face names.
> Therefore I think better to move the existing code
>
>   (memq (get-text-property 0 'face (nth 2 item)) tab-bar-auto-width-faces)
>
> to the new predicate function on emacs-30.  Then activities.el
> can change it to another function that matches a symbol.
>
> Then on master the default body on the new predicate
> could be replaced from checking the face to match a symbol.
> Also changes in tab-bar--format-tab-group should be on master as well.

Much as I'd like to use these changes asap, I think this patchset should
go entirely on master.  I see these changes as adding functionality
(making tab-bar tabs more extensible) rather than bug fixes.

>>> Does this change warrant a NEWS entry?
>>
>> Yes, since you are adding a hook variable.  Obsolescence of a variable
>> also requires a NEWS entry.

Please see attached patches.

Thanks!

Joseph

[0001-Use-current-group-symbol-for-current-tab-group-item.patch (text/x-diff, attachment)]

[0002-Add-abnormal-hook-to-determine-which-tabs-to-auto-wi.patch (text/x-diff, attachment)]

[0003-Mark-tab-bar-auto-width-faces-obsolete.patch (text/x-diff, attachment)]

[0004-etc-NEWS-Announce-tab-bar-auto-width-functions.patch (text/x-diff, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Thu, 25 Jul 2024 21:18:57 +0300

>> Replacing hard-coded logic with customizable variable
>> for external packages like activities.el is needed
>> as soon as possible on emacs-30 because hard-coded logic
>> hinders the use of packages.
>>
>> However, there is no hurry to change the default behavior
>> to match a symbol name instead of checking face names.
>> Therefore I think better to move the existing code
>>
>>   (memq (get-text-property 0 'face (nth 2 item)) tab-bar-auto-width-faces)
>>
>> to the new predicate function on emacs-30.  Then activities.el
>> can change it to another function that matches a symbol.
>>
>> Then on master the default body on the new predicate
>> could be replaced from checking the face to match a symbol.
>> Also changes in tab-bar--format-tab-group should be on master as well.
>
> Much as I'd like to use these changes asap, I think this patchset should
> go entirely on master.  I see these changes as adding functionality
> (making tab-bar tabs more extensible) rather than bug fixes.

Are you sure there is no hurry to make tab-bar more extensible
for activities.el?  Then let's push to master for Emacs 31.

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Thu, 25 Jul 2024 11:52:19 -0700

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

>>> Replacing hard-coded logic with customizable variable
>>> for external packages like activities.el is needed
>>> as soon as possible on emacs-30 because hard-coded logic
>>> hinders the use of packages.
>>>
>>> However, there is no hurry to change the default behavior
>>> to match a symbol name instead of checking face names.
>>> Therefore I think better to move the existing code
>>>
>>>   (memq (get-text-property 0 'face (nth 2 item)) tab-bar-auto-width-faces)
>>>
>>> to the new predicate function on emacs-30.  Then activities.el
>>> can change it to another function that matches a symbol.
>>>
>>> Then on master the default body on the new predicate
>>> could be replaced from checking the face to match a symbol.
>>> Also changes in tab-bar--format-tab-group should be on master as well.
>>
>> Much as I'd like to use these changes asap, I think this patchset should
>> go entirely on master.  I see these changes as adding functionality
>> (making tab-bar tabs more extensible) rather than bug fixes.
>
> Are you sure there is no hurry to make tab-bar more extensible
> for activities.el?  Then let's push to master for Emacs 31.

The effect on activities.el is purely cosmetic.  I think it's fine to
wait for 31.

Thanks for thinking it through together with me!

Joseph

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, shipmints <at> gmail.com,
 juri <at> linkov.net
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Thu, 25 Jul 2024 22:09:01 +0300

> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  adam <at> alphapapa.net,
>   71883 <at> debbugs.gnu.org,  shipmints <at> gmail.com
> Date: Thu, 25 Jul 2024 11:11:01 -0700
> 
> +** Tab Bars and Tab Lines
> +
> +*** New abnormal hook 'tab-bar-auto-width-functions'.  This hook
> +allows you to control which tab-bar tabs are automatically resized.

The first line should be a single complete sentence.

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, shipmints <at> gmail.com,
 juri <at> linkov.net
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Thu, 25 Jul 2024 16:00:10 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  adam <at> alphapapa.net,
>>   71883 <at> debbugs.gnu.org,  shipmints <at> gmail.com
>> Date: Thu, 25 Jul 2024 11:11:01 -0700
>> 
>> +** Tab Bars and Tab Lines
>> +
>> +*** New abnormal hook 'tab-bar-auto-width-functions'.  This hook
>> +allows you to control which tab-bar tabs are automatically resized.
>
> The first line should be a single complete sentence.

Thanks!  See patches.

[0001-Use-current-group-symbol-for-current-tab-group-item.patch (text/x-diff, attachment)]

[0002-Add-abnormal-hook-to-determine-which-tabs-to-auto-wi.patch (text/x-diff, attachment)]

[0003-Mark-tab-bar-auto-width-faces-obsolete.patch (text/x-diff, attachment)]

[0004-etc-NEWS-Announce-tab-bar-auto-width-functions.patch (text/x-diff, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Tue, 06 Aug 2024 09:59:51 +0300

Thanks for the patches.

> -   `((,(intern (format "group-%i" i))
> +   `((,(intern (if current-p "current-group" (format "group-%i" i)))

I pushed this part to master now.

> +(defun tab-bar-auto-width-predicate-default (item)
> +  "Accepts tab ITEM and returns non-nil for tabs and tab groups."
> +  (string-match-p
> +   ;; (rx bos (or "current-tab" "current-group" "tab-" "group-"))
> +   "\\`\\(?:current-\\(?:group\\|tab\\)\\|\\(?:group\\|tab\\)-\\)"
> +   (symbol-name (nth 0 item))))

In this part please remove the current group from the default implementation,
because it looks too ugly, and it was not resized before this change, since
tab-bar-auto-width-faces didn't contain the tab-bar-tab-group-current face.

> -        (if (memq (get-text-property 0 'face (nth 2 item))
> -                  tab-bar-auto-width-faces)
> +        (if (run-hook-with-args-until-success 'tab-bar-auto-width-functions item)

I wonder how users are supposed to handle tab-bar-tab-ungrouped now?
Since it can't be distinguished from grouped tabs (both have tab- symbols),
is this how users should customize this now:

  (setq tab-bar-auto-width-functions
        `(,(lambda (item)
             (and (string-match-p
                   "\\`\\(?:current-tab\\|\\(?:group\\|tab\\)-\\)" (symbol-name (nth 0 item)))
                  (not (eq (get-text-property 0 'face (nth 2 item))
                           'tab-bar-tab-ungrouped))))))

> +(make-obsolete-variable 'tab-bar-auto-width-faces 'tab-bar-auto-width-functions "30")
> [...]
> +*** The 'tab-bar-auto-width-faces' variable is now obsolete.
> +Use 'tab-bar-auto-width-functions' instead.

Actually I see no need to obsolete the variable instead of deleting it right away
since it's not used anywhere anymore.

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized tab-bar-tab-face-function
Date: Fri, 09 Aug 2024 05:15:38 -0700

[Message part 1 (text/plain, inline)]

On August 5, 2024 11:59:51 PM PDT, Juri Linkov <juri <at> linkov.net> wrote:
>Thanks for the patches.
>
>> -   `((,(intern (format "group-%i" i))
>> +   `((,(intern (if current-p "current-group" (format "group-%i" i)))
>
>I pushed this part to master now.
>
>> +(defun tab-bar-auto-width-predicate-default (item)
>> +  "Accepts tab ITEM and returns non-nil for tabs and tab groups."
>> +  (string-match-p
>> +   ;; (rx bos (or "current-tab" "current-group" "tab-" "group-"))
>> +   "\\`\\(?:current-\\(?:group\\|tab\\)\\|\\(?:group\\|tab\\)-\\)"
>> +   (symbol-name (nth 0 item))))
>
>In this part please remove the current group from the default implementation,
>because it looks too ugly, and it was not resized before this change, since
>tab-bar-auto-width-faces didn't contain the tab-bar-tab-group-current face.

If the simpler change brings feature parity, go for it!

>> -        (if (memq (get-text-property 0 'face (nth 2 item))
>> -                  tab-bar-auto-width-faces)
>> +        (if (run-hook-with-args-until-success 'tab-bar-auto-width-functions item)
>
>I wonder how users are supposed to handle tab-bar-tab-ungrouped now?
>Since it can't be distinguished from grouped tabs (both have tab- symbols),
>is this how users should customize this now:
>
>  (setq tab-bar-auto-width-functions
>        `(,(lambda (item)
>             (and (string-match-p
>                   "\\`\\(?:current-tab\\|\\(?:group\\|tab\\)-\\)" (symbol-name (nth 0 item)))
>                  (not (eq (get-text-property 0 'face (nth 2 item))
>                           'tab-bar-tab-ungrouped))))))

I'm not sure.  I have never used group tabs.

>> +(make-obsolete-variable 'tab-bar-auto-width-faces 'tab-bar-auto-width-functions "30")
>> [...]
>> +*** The 'tab-bar-auto-width-faces' variable is now obsolete.
>> +Use 'tab-bar-auto-width-functions' instead.
>
>Actually I see no need to obsolete the variable instead of deleting it right away
>since it's not used anywhere anymore.

If it's okay to remove defvars without obsoletion notice, then I'm in favor of deleting it now.

Thanks!

Joseph

[Message part 2 (text/html, inline)]

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Fri, 09 Aug 2024 05:25:21 -0700

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

> Thanks for the patches.
>
>> -   `((,(intern (format "group-%i" i))
>> +   `((,(intern (if current-p "current-group" (format "group-%i" i)))
>
> I pushed this part to master now.
>
>> +(defun tab-bar-auto-width-predicate-default (item)
>> +  "Accepts tab ITEM and returns non-nil for tabs and tab groups."
>> +  (string-match-p
>> +   ;; (rx bos (or "current-tab" "current-group" "tab-" "group-"))
>> +   "\\`\\(?:current-\\(?:group\\|tab\\)\\|\\(?:group\\|tab\\)-\\)"
>> +   (symbol-name (nth 0 item))))
>
> In this part please remove the current group from the default implementation,
> because it looks too ugly, and it was not resized before this change, since
> tab-bar-auto-width-faces didn't contain the tab-bar-tab-group-current face.

If the simpler change offers feature parity, that sounds good to me.

>> -        (if (memq (get-text-property 0 'face (nth 2 item))
>> -                  tab-bar-auto-width-faces)
>> +        (if (run-hook-with-args-until-success 'tab-bar-auto-width-functions item)
>
> I wonder how users are supposed to handle tab-bar-tab-ungrouped now?
> Since it can't be distinguished from grouped tabs (both have tab- symbols),
> is this how users should customize this now:
>
>   (setq tab-bar-auto-width-functions
>         `(,(lambda (item)
>              (and (string-match-p
>                    "\\`\\(?:current-tab\\|\\(?:group\\|tab\\)-\\)" (symbol-name (nth 0 item)))
>                   (not (eq (get-text-property 0 'face (nth 2 item))
>                            'tab-bar-tab-ungrouped))))))

I don't use tab groups, so I don't know if anyone will want to do this.

>> +(make-obsolete-variable 'tab-bar-auto-width-faces 'tab-bar-auto-width-functions "30")
>> [...]
>> +*** The 'tab-bar-auto-width-faces' variable is now obsolete.
>> +Use 'tab-bar-auto-width-functions' instead.
>
> Actually I see no need to obsolete the variable instead of deleting it right away
> since it's not used anywhere anymore.

If it's okay to remove defvars without obsoletion, I'm in favor of it.

Thanks!

Joseph

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

From: Juri Linkov <juri <at> linkov.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Mon, 19 Aug 2024 19:57:13 +0300

close 71883 31.0.50
thanks

>>> +(defun tab-bar-auto-width-predicate-default (item)
>>> +  "Accepts tab ITEM and returns non-nil for tabs and tab groups."
>>> +  (string-match-p
>>> +   ;; (rx bos (or "current-tab" "current-group" "tab-" "group-"))
>>> +   "\\`\\(?:current-\\(?:group\\|tab\\)\\|\\(?:group\\|tab\\)-\\)"
>>> +   (symbol-name (nth 0 item))))
>>
>> In this part please remove the current group from the default implementation,
>> because it looks too ugly, and it was not resized before this change, since
>> tab-bar-auto-width-faces didn't contain the tab-bar-tab-group-current face.
>
> If the simpler change offers feature parity, that sounds good to me.

Thanks for the patch, I pushed it to master, then ameliorated it
to keep backwards-compatibility for users customized these faces,
but by default using your predicate on symbols.

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Mon, 19 Aug 2024 18:49:27 -0700

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

> close 71883 31.0.50
> thanks
>
>>>> +(defun tab-bar-auto-width-predicate-default (item)
>>>> +  "Accepts tab ITEM and returns non-nil for tabs and tab groups."
>>>> +  (string-match-p
>>>> +   ;; (rx bos (or "current-tab" "current-group" "tab-" "group-"))
>>>> +   "\\`\\(?:current-\\(?:group\\|tab\\)\\|\\(?:group\\|tab\\)-\\)"
>>>> +   (symbol-name (nth 0 item))))
>>>
>>> In this part please remove the current group from the default implementation,
>>> because it looks too ugly, and it was not resized before this change, since
>>> tab-bar-auto-width-faces didn't contain the tab-bar-tab-group-current face.
>>
>> If the simpler change offers feature parity, that sounds good to me.
>
> Thanks for the patch, I pushed it to master, then ameliorated it
> to keep backwards-compatibility for users customized these faces,
> but by default using your predicate on symbols.

Thank you!  How would users have customized tab-bar-auto-width-faces
since it was not a defcustom?

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

From: Juri Linkov <juri <at> linkov.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Tue, 20 Aug 2024 09:40:38 +0300

>>>>> +(defun tab-bar-auto-width-predicate-default (item)
>>>>> +  "Accepts tab ITEM and returns non-nil for tabs and tab groups."
>>>>> +  (string-match-p
>>>>> +   ;; (rx bos (or "current-tab" "current-group" "tab-" "group-"))
>>>>> +   "\\`\\(?:current-\\(?:group\\|tab\\)\\|\\(?:group\\|tab\\)-\\)"
>>>>> +   (symbol-name (nth 0 item))))
>>>>
>>>> In this part please remove the current group from the default implementation,
>>>> because it looks too ugly, and it was not resized before this change, since
>>>> tab-bar-auto-width-faces didn't contain the tab-bar-tab-group-current face.
>>>
>>> If the simpler change offers feature parity, that sounds good to me.
>>
>> Thanks for the patch, I pushed it to master, then ameliorated it
>> to keep backwards-compatibility for users customized these faces,
>> but by default using your predicate on symbols.
>
> Thank you!  How would users have customized tab-bar-auto-width-faces
> since it was not a defcustom?

I meant that customized it without using the Customization UI.
Maybe a better word would be "configured", e.g. with 'setopt'
('setopt' supports non-customizable plain variables as
'setq' does, unlike 'set-variable' that refuses to change them).

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Juri Linkov <juri <at> linkov.net>
Cc: adam <at> alphapapa.net, 71883 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 shipmints <at> gmail.com
Subject: Re: bug#71883: [PATCH] Fix tab-bar-auto-width with customized
 tab-bar-tab-face-function
Date: Tue, 20 Aug 2024 00:11:33 -0700

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

>>>>>> +(defun tab-bar-auto-width-predicate-default (item)
>>>>>> +  "Accepts tab ITEM and returns non-nil for tabs and tab groups."
>>>>>> +  (string-match-p
>>>>>> +   ;; (rx bos (or "current-tab" "current-group" "tab-" "group-"))
>>>>>> +   "\\`\\(?:current-\\(?:group\\|tab\\)\\|\\(?:group\\|tab\\)-\\)"
>>>>>> +   (symbol-name (nth 0 item))))
>>>>>
>>>>> In this part please remove the current group from the default implementation,
>>>>> because it looks too ugly, and it was not resized before this change, since
>>>>> tab-bar-auto-width-faces didn't contain the tab-bar-tab-group-current face.
>>>>
>>>> If the simpler change offers feature parity, that sounds good to me.
>>>
>>> Thanks for the patch, I pushed it to master, then ameliorated it
>>> to keep backwards-compatibility for users customized these faces,
>>> but by default using your predicate on symbols.
>>
>> Thank you!  How would users have customized tab-bar-auto-width-faces
>> since it was not a defcustom?
>
> I meant that customized it without using the Customization UI.
> Maybe a better word would be "configured", e.g. with 'setopt'
> ('setopt' supports non-customizable plain variables as
> 'setq' does, unlike 'set-variable' that refuses to change them).

I see.  Thank you!

Previous Next

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