Fix width tabs

Fix width tabs

[Matthias Meulien]

When a tab has multiple windows, its name is updated depending on
current buffer name.  Switching window (C-x o) results in the tab being
renamed.

But buffer names of a given tab have heterogeneous lengths (*Help*,
*Summary Listes/emacs-devel*, etc.). Thus the tab bar layout may change
a lot while switching window, which is annoying: Visually, the tab bar
can occupy two lines then one, etc.

I'd like to configure all tabs to have the same width, whatever the
length of the name of the current buffer of a particular tab is. That
width could be the frame width divided by the number of tabs.

But I've not found a way to do that with current options. Is it already
possible?

My understanding is that it's the default behavior in other applications
like Firefox. Is there good reason to have different default?
-- 
Matthias

Re: Fix width tabs

[Juri Linkov]

> When a tab has multiple windows, its name is updated depending on
> current buffer name.  Switching window (C-x o) results in the tab being
> renamed.

This problem doesn't exist when tab-bar-tab-name-function
shows all window buffers with tab-bar-tab-name-all.
So a possible solution is to enable this by default.

> But buffer names of a given tab have heterogeneous lengths (*Help*,
> *Summary Listes/emacs-devel*, etc.). Thus the tab bar layout may change
> a lot while switching window, which is annoying: Visually, the tab bar
> can occupy two lines then one, etc.
>
> I'd like to configure all tabs to have the same width, whatever the
> length of the name of the current buffer of a particular tab is. That
> width could be the frame width divided by the number of tabs.
>
> But I've not found a way to do that with current options. Is it already
> possible?

Yes, it's possible to do by writing a new function for
tab-bar-tab-name-function.  There was a similar function
for fixed tab widths in tab-line.el, but after discussions
it was removed because it wasted too much screen space
with empty spaces used to adjust for fixed widths.

> My understanding is that it's the default behavior in other applications
> like Firefox. Is there good reason to have different default?

The good reason is to have the more compact tab bar.
If you want, you could try experimenting by writing a function
for tab-bar-tab-name-function with padding every tab name
by proportional amount of space.

Re: Fix width tabs

[Matthias Meulien]

Juri Linkov <juri@linkov.net> writes:

>> When a tab has multiple windows, its name is updated depending on
>> current buffer name.  Switching window (C-x o) results in the tab being
>> renamed.
>
> This problem doesn't exist when tab-bar-tab-name-function
> shows all window buffers with tab-bar-tab-name-all.
> So a possible solution is to enable this by default.

Thanks I didn't knew tab-bar-tab-name-all. Unfortunately visiting a new
window expands the tab name and thus there's the same problem.

> (...)
>> But I've not found a way to do that with current options. Is it
>> already possible?
>
> Yes, it's possible to do by writing a new function for
> tab-bar-tab-name-function.  There was a similar function
> for fixed tab widths in tab-line.el, but after discussions
> it was removed because it wasted too much screen space
> with empty spaces used to adjust for fixed widths.

I don't understand how it could waste more space than the
tab-bar-tab-name-all function you mentionned.

>> My understanding is that it's the default behavior in other applications
>> like Firefox. Is there good reason to have different default?
>
> The good reason is to have the more compact tab bar.
> If you want, you could try experimenting by writing a function
> for tab-bar-tab-name-function with padding every tab name
> by proportional amount of space.

I'll try this. Thanks a lot!
-- 
Matthias

Re: Fix width tabs

[Juri Linkov]

>> If you want, you could try experimenting by writing a function
>> for tab-bar-tab-name-function with padding every tab name
>> by proportional amount of space.
>
> I'll try this. Thanks a lot!

If you need the fixed width also for tabs with explicit names,
then a better option would be write a formatting function for
tab-bar-tab-name-format-function.

Re: Fix width tabs

[Juri Linkov]

>>> If you want, you could try experimenting by writing a function
>>> for tab-bar-tab-name-function with padding every tab name
>>> by proportional amount of space.
>>
>> I'll try this. Thanks a lot!
>
> If you need the fixed width also for tabs with explicit names,
> then a better option would be write a formatting function for
> tab-bar-tab-name-format-function.

OTOH, I can't imagine how you could implement a formatting function
without requiring two-pass tabs generation that is highly inefficient:
after the first pass you get the number of tabs, groups of tabs,
and their names.  Then on the second pass you can pad names
with required amount of space proportional to the total number of tabs.

So a more efficient implementation would be to modify the strings
that represent the tab names in the result of tab-bar-format-list
(e.g. by using advice-add for experimentation).  But a drawback is
that then you need to rely on the details of implementation of the
internal data structure.

Re: Fix width tabs

[Matthias Meulien]

Juri Linkov <juri@linkov.net> writes:

>>>> If you want, you could try experimenting by writing a function
>>>> for tab-bar-tab-name-function with padding every tab name
>>>> by proportional amount of space.
>>>
>>> I'll try this. Thanks a lot!
>>
>> If you need the fixed width also for tabs with explicit names,
>> then a better option would be write a formatting function for
>> tab-bar-tab-name-format-function.

I tried the following (not trying to dynamically compute the tabs width
to start with and disabling support for close buttons):

(defun my-tab-bar-tab-name-format (tab i)
  (propertize
   (truncate-string-to-width
    (format
     (concat "%-" (number-to-string tab-bar-tab-name-truncated-max) "s")
     (alist-get 'name tab))
    tab-bar-tab-name-truncated-max 0 ?m t)
   'face (funcall tab-bar-tab-face-function tab)))

(setq tab-bar-tab-name-format-function 'my-tab-bar-tab-name-format)

Unfortunately it doesn't play well with variable pitch font, and the
display property "min-width" isn't honored in tab-bar. I guess my naive
approach won't be sufficient...

> OTOH, I can't imagine how you could implement a formatting function
> without requiring two-pass tabs generation that is highly inefficient:
> after the first pass you get the number of tabs, groups of tabs,
> and their names.  Then on the second pass you can pad names
> with required amount of space proportional to the total number of tabs.
>
> So a more efficient implementation would be to modify the strings
> that represent the tab names in the result of tab-bar-format-list
> (e.g. by using advice-add for experimentation).  But a drawback is
> that then you need to rely on the details of implementation of the
> internal data structure.

I understand.
-- 
Matthias

Re: Fix width tabs

[Juri Linkov]

> I tried the following (not trying to dynamically compute the tabs width
> to start with and disabling support for close buttons):
>
> (defun my-tab-bar-tab-name-format (tab i)
>   (propertize
>    (truncate-string-to-width
>     (format
>      (concat "%-" (number-to-string tab-bar-tab-name-truncated-max) "s")
>      (alist-get 'name tab))
>     tab-bar-tab-name-truncated-max 0 ?m t)
>    'face (funcall tab-bar-tab-face-function tab)))
>
> (setq tab-bar-tab-name-format-function 'my-tab-bar-tab-name-format)
>
> Unfortunately it doesn't play well with variable pitch font, and the
> display property "min-width" isn't honored in tab-bar. I guess my naive
> approach won't be sufficient...

I don't remember if we already have pixel-level space padding for
variable pitch fonts.  Probably not, because variable pitch fonts
can't be used on the mode-line where the problem is that the
coding-system indicator can't take the fixed amount of space.
One of the threads where this was recently discussed:
https://lists.gnu.org/archive/html/emacs-devel/2021-06/msg00343.html

Re: Fix width tabs

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

> OTOH, I can't imagine how you could implement a formatting function
> without requiring two-pass tabs generation that is highly inefficient:
> after the first pass you get the number of tabs, groups of tabs,
> and their names.  Then on the second pass you can pad names
> with required amount of space proportional to the total number of tabs.
>
> So a more efficient implementation would be to modify the strings
> that represent the tab names in the result of tab-bar-format-list
> (e.g. by using advice-add for experimentation).  But a drawback is
> that then you need to rely on the details of implementation of the
> internal data structure.

I still see no other way to implement pixel-based filling/justifying
of tab names.  So here is a prototype to try that later will be adapted
to tab-bar.el.  It seems that's all we can do for nicer-looking tabs.
At least, it resizes tabs like in web browsers.  And the default value
of tab-bar-tab-width-max is the same as in Firefox.


[-- Attachment #2: tab-bar-tab-width-max.el --]
[-- Type: application/emacs-lisp, Size: 2543 bytes --]

Re: Fix width tabs

[Matthias Meulien]

Juri Linkov <juri@linkov.net> writes:

> (...)  I still see no other way to implement pixel-based
> filling/justifying of tab names.  So here is a prototype to try that
> later will be adapted to tab-bar.el.  It seems that's all we can do
> for nicer-looking tabs.  At least, it resizes tabs like in web
> browsers.  And the default value of tab-bar-tab-width-max is the same
> as in Firefox.

Thank you!  I installed your code, and at first sight it works quite
well and the resulting tab bar looks good.

Firefox choose to change the foreground color on tabs end to make names
easier to read.  I guess it isn't supported by Emacs. So I use to set
tab-bar-tab-name-function to tab-bar-tab-name-truncated and
tab-bar-tab-name-ellipsis to t.  It helps distinguish the separation
between tab names.  Is it expected for the truncation to not applying
anymore with the code you sent?
-- 
Matthias

Re: Fix width tabs

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

> Firefox choose to change the foreground color on tabs end to make names
> easier to read.  I guess it isn't supported by Emacs. So I use to set
> tab-bar-tab-name-function to tab-bar-tab-name-truncated and
> tab-bar-tab-name-ellipsis to t.  It helps distinguish the separation
> between tab names.  Is it expected for the truncation to not applying
> anymore with the code you sent?

Unfortunately, an ellipsis takes too much screen space.
When "…" is not displayable, then "..." will take 3 chars
from every tab name, and even "…" with variable-pitch fonts
takes almost the same space as "..." with monospaced fonts.

But using a faded foreground color like in Firefox is
the right thing to do.  After adding this to the end:

          (add-face-text-property (- (length (nth 2 item)) 3)
                                  (length (nth 2 item))
                                  'shadow nil (nth 2 item))

produces such nice look where tab names are fading to the right:


[-- Attachment #2: tab-fade.png --]
[-- Type: image/png, Size: 15064 bytes --]

Re: Fix width tabs

[Juri Linkov]

>> Firefox choose to change the foreground color on tabs end to make names
>> easier to read.  I guess it isn't supported by Emacs. So I use to set
>> tab-bar-tab-name-function to tab-bar-tab-name-truncated and
>> tab-bar-tab-name-ellipsis to t.  It helps distinguish the separation
>> between tab names.  Is it expected for the truncation to not applying
>> anymore with the code you sent?
>
> But using a faded foreground color like in Firefox is
> the right thing to do.  After adding this to the end
> produces such nice look where tab names are fading to the right:

This feature is pushed now enabled by default.

Re: Fix width tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Fri, 04 Nov 2022 09:48:58 +0200
> 
> >> Firefox choose to change the foreground color on tabs end to make names
> >> easier to read.  I guess it isn't supported by Emacs. So I use to set
> >> tab-bar-tab-name-function to tab-bar-tab-name-truncated and
> >> tab-bar-tab-name-ellipsis to t.  It helps distinguish the separation
> >> between tab names.  Is it expected for the truncation to not applying
> >> anymore with the code you sent?
> >
> > But using a faded foreground color like in Firefox is
> > the right thing to do.  After adding this to the end
> > produces such nice look where tab names are fading to the right:
> 
> This feature is pushed now enabled by default.

Thanks.  However, I have problems with the documentation of this
feature:

  (defcustom tab-bar-fixed-width t
    "Automatically resize tabs on the tab bar to the fixed width.
  This variable is intended to solve two problems.  When switching buffers
  on the current tab, the tab changes its name to buffer names of
  various lengths, thus resizing the tab and shifting the tab positions
  on the tab bar.  But with the fixed width, the size of the tab name
  doesn't change when the tab name changes, thus keeping the fixed
  tab bar layout.  The second problem solved by this variable is to prevent
  wrapping the long tab bar to the second line, thus keeping the height of
  the tab bar always fixed to one line.

  The maximum tab width is defined by the variable `tab-bar-fixed-width-max'."

This begs the question: what is the fixed width to which the tabs are
resized? if it's "fixed", then the value is known in advance, right?
Moreover, if the tab sizes are fixed, why does the doc string say
"automatically resize"? "resizing" is the antithesis of "fixed width".
Can you explain in plain words what this option does, when it is
non-nil?  (There's a hint to that in the doc string of
tab-bar-fixed-width-max, but that's not the right place for this
information.)  Also, what does it do when it's nil?

The style of the doc string is also problematic: we shouldn't describe
in a doc string of user option what problems it solves.  Instead, we
should tell what is the behavior for each valid value of the option;
the judgment of what is a "problem" and what isn't is left to the
user, because the needs of users may differ, and what is a "problem"
for some is a "solution" to others.  That's why we have user options
to begin with.

The NEWS entry is also problematic, basically for the same reason.

We should fix this.

Re: Fix width tabs

[Juri Linkov]

>     "Automatically resize tabs on the tab bar to the fixed width.
>   This variable is intended to solve two problems.  When switching buffers
>   on the current tab, the tab changes its name to buffer names of
>   various lengths, thus resizing the tab and shifting the tab positions
>   on the tab bar.  But with the fixed width, the size of the tab name
>   doesn't change when the tab name changes, thus keeping the fixed
>   tab bar layout.  The second problem solved by this variable is to prevent
>   wrapping the long tab bar to the second line, thus keeping the height of
>   the tab bar always fixed to one line.
>
>   The maximum tab width is defined by the variable `tab-bar-fixed-width-max'."
>
> This begs the question: what is the fixed width to which the tabs are
> resized? if it's "fixed", then the value is known in advance, right?
> Moreover, if the tab sizes are fixed, why does the doc string say
> "automatically resize"? "resizing" is the antithesis of "fixed width".

Maybe a better name would be `tab-bar-auto-resize'?
But this name will be confused with the existing
`auto-resize-tab-bars' that resizes the tab-bar's height,
not width.

> Can you explain in plain words what this option does, when it is
> non-nil?  (There's a hint to that in the doc string of
> tab-bar-fixed-width-max, but that's not the right place for this
> information.)  Also, what does it do when it's nil?

When tab-bar-fixed-width is non-nil, tabs are distributed evenly
across the tab-bar.  When also tab-bar-fixed-width-max is a number,
then tab names are truncated to the defined width.

In any case, short tab names are filled with spaces.
Currently there is no option to avoid filling with spaces.
Maybe tab-bar-fixed-width could also support a new value
'shrink-only' for this.

> The style of the doc string is also problematic: we shouldn't describe
> in a doc string of user option what problems it solves.  Instead, we
> should tell what is the behavior for each valid value of the option;
> the judgment of what is a "problem" and what isn't is left to the
> user, because the needs of users may differ, and what is a "problem"
> for some is a "solution" to others.  That's why we have user options
> to begin with.
>
> The NEWS entry is also problematic, basically for the same reason.

Maybe the description of problems should be moved from the doc string
to NEWS?

Re: Fix width tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: orontee@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 05 Nov 2022 19:12:54 +0200
> 
> > This begs the question: what is the fixed width to which the tabs are
> > resized? if it's "fixed", then the value is known in advance, right?
> > Moreover, if the tab sizes are fixed, why does the doc string say
> > "automatically resize"? "resizing" is the antithesis of "fixed width".
> 
> Maybe a better name would be `tab-bar-auto-resize'?
> But this name will be confused with the existing
> `auto-resize-tab-bars' that resizes the tab-bar's height,
> not width.

We can think about a good name for the variable when we have a good
understanding of the behavior it changes.

> > Can you explain in plain words what this option does, when it is
> > non-nil?  (There's a hint to that in the doc string of
> > tab-bar-fixed-width-max, but that's not the right place for this
> > information.)  Also, what does it do when it's nil?
> 
> When tab-bar-fixed-width is non-nil, tabs are distributed evenly
> across the tab-bar.  When also tab-bar-fixed-width-max is a number,
> then tab names are truncated to the defined width.
> 
> In any case, short tab names are filled with spaces.
> Currently there is no option to avoid filling with spaces.
> Maybe tab-bar-fixed-width could also support a new value
> 'shrink-only' for this.

Ok, and what happens when tab-bar-fixed-width is nil?

> > The style of the doc string is also problematic: we shouldn't describe
> > in a doc string of user option what problems it solves.  Instead, we
> > should tell what is the behavior for each valid value of the option;
> > the judgment of what is a "problem" and what isn't is left to the
> > user, because the needs of users may differ, and what is a "problem"
> > for some is a "solution" to others.  That's why we have user options
> > to begin with.
> >
> > The NEWS entry is also problematic, basically for the same reason.
> 
> Maybe the description of problems should be moved from the doc string
> to NEWS?

No, I don't think so.  I believe if we explain the behavior with both
nil and non-nil values, users will understand what it does for them in
various situations, and we won't need to qualify anything as a
"problem".

Thanks.

Re: Fix width tabs

[Juri Linkov]

>> When tab-bar-fixed-width is non-nil, tabs are distributed evenly
>> across the tab-bar.  When also tab-bar-fixed-width-max is a number,
>> then tab names are truncated to the defined width.
>
> Ok, and what happens when tab-bar-fixed-width is nil?

When tab-bar-fixed-width is nil, then the tabs have the same widths
as the text of the tab names.

When tab-bar-fixed-width is non-nil, the available tab-bar space
is divided by the number of tabs to get the average tab width.
When its value is bigger than tab-bar-fixed-width-max, then
it's decreased to tab-bar-fixed-width-max.  Then tabs whose names
are shorter than the average tab width, are filled with whitespace.
And longer tab names are truncated to the average tab width.

Re: Fix width tabs

[tomas]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

On Sat, Nov 05, 2022 at 07:12:54PM +0200, Juri Linkov wrote:

[...]

> When tab-bar-fixed-width is non-nil, tabs are distributed evenly
> across the tab-bar [...]

That sounds more like "uniform width" to me, if I understood right?

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Fix width tabs

[Juri Linkov]

>> When tab-bar-fixed-width is non-nil, tabs are distributed evenly
>> across the tab-bar [...]
>
> That sounds more like "uniform width" to me, if I understood right?

  From WordNet (r) 3.0 (2006) [wn]:
  uniform
      4: evenly spaced; "at regular (or uniform) intervals"

So looks like the right word.

Re: Fix width tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: orontee@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 05 Nov 2022 19:12:54 +0200
> 
> >     "Automatically resize tabs on the tab bar to the fixed width.
> >   This variable is intended to solve two problems.  When switching buffers
> >   on the current tab, the tab changes its name to buffer names of
> >   various lengths, thus resizing the tab and shifting the tab positions
> >   on the tab bar.  But with the fixed width, the size of the tab name
> >   doesn't change when the tab name changes, thus keeping the fixed
> >   tab bar layout.  The second problem solved by this variable is to prevent
> >   wrapping the long tab bar to the second line, thus keeping the height of
> >   the tab bar always fixed to one line.
> >
> >   The maximum tab width is defined by the variable `tab-bar-fixed-width-max'."
> >
> > This begs the question: what is the fixed width to which the tabs are
> > resized? if it's "fixed", then the value is known in advance, right?
> > Moreover, if the tab sizes are fixed, why does the doc string say
> > "automatically resize"? "resizing" is the antithesis of "fixed width".
> 
> Maybe a better name would be `tab-bar-auto-resize'?
> But this name will be confused with the existing
> `auto-resize-tab-bars' that resizes the tab-bar's height,
> not width.

I suggest the name tab-bar-auto-width.  With the following doc string:

    Automatically resize width of tabs on tab bar to fill available tab-bar space.
  When non-nil, the widths of the tabs on the tab bar are automatically
  resized so that their width is evenly distributed across the tab bar.
  This keeps the widths of the tabs independent of the length of the
  buffer names shown on each tab; the tab widths change only when tabs
  are added or deleted, or when the frame's dimensions change.  This
  also avoids as much as possible wrapping a long tab bar to a second
  tab-bar line.

  The automatic resizing of tabs takes place as long as tabs are no
  wider than allowed by the value of `tab-bar-fixed-width-max', and at
  least as wide as specified by the value of `tab-bar-fixed-width-min'.

  When this variable is nil, the width of each tab is determined by the
  length of the tab's name."

OK?