Re: Fix width tabs

[Juri Linkov <juri@linkov.net>]

>     "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?