GNU bug report logs - #78953
31.0.50; tab-bar-format-align-right alignment breaks if field widths change

Previous Next

To reply to this bug, email your comments to 78953 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; tab-bar-format-align-right alignment breaks if field
 widths change
Date: Fri, 04 Jul 2025 08:39:24 +0200

When fields in `tab-bar-format' after `tab-bar-format-align-right'
change their width between two calls, then the alignment breaks - the
right aligned tab field jumps around. Example configuration which uses a
`global-mode-string' with a random width:

(setq tab-bar-format
  '( tab-bar-format-tabs
     tab-bar-format-align-right
     tab-bar-format-global))

(setq global-mode-string
      '("|" (:eval (make-string (random 10) ?#)) "|"))

(run-at-time 1 1 #'force-mode-line-update t)

A more realistic configuration with a timer (and a variable pitch face)
also shows the problem. A possible solution could be to handle
`tab-bar-format-align-right' in `tab-bar-format-list', such that the
functions in the `tab-bar-format' list after
`tab-bar-format-align-right' are not called twice, such that the
computed field width matches the displayed field.

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-06-20
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)

Configured using:
 'configure --prefix=$HOME/.local/share/emacs
 --without-compress-install --with-tree-sitter --with-native-compilation
 --with-dbus --without-selinux --without-threads --disable-gc-mark-trace
 --without-gsettings --without-gpm --with-cairo --with-cairo-xcb
 --with-xinput2 --with-x-toolkit=gtk3 --without-toolkit-scroll-bars'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 TIFF TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Fri, 04 Jul 2025 09:52:58 +0300

> When fields in `tab-bar-format' after `tab-bar-format-align-right'
> change their width between two calls, then the alignment breaks - the
> right aligned tab field jumps around. Example configuration which uses a
> `global-mode-string' with a random width:
>
> (setq tab-bar-format
>   '( tab-bar-format-tabs
>      tab-bar-format-align-right
>      tab-bar-format-global))
>
> (setq global-mode-string
>       '("|" (:eval (make-string (random 10) ?#)) "|"))
>
> (run-at-time 1 1 #'force-mode-line-update t)

Thanks, I confirm the problem.

> A more realistic configuration with a timer (and a variable pitch face)
> also shows the problem. A possible solution could be to handle
> `tab-bar-format-align-right' in `tab-bar-format-list', such that the
> functions in the `tab-bar-format' list after
> `tab-bar-format-align-right' are not called twice, such that the
> computed field width matches the displayed field.

So need to update :align-to in tab-bar-format-list.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Fri, 04 Jul 2025 09:21:38 +0200

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

>> When fields in `tab-bar-format' after `tab-bar-format-align-right'
>> change their width between two calls, then the alignment breaks - the
>> right aligned tab field jumps around. Example configuration which uses a
>> `global-mode-string' with a random width:
>>
>> (setq tab-bar-format
>>   '( tab-bar-format-tabs
>>      tab-bar-format-align-right
>>      tab-bar-format-global))
>>
>> (setq global-mode-string
>>       '("|" (:eval (make-string (random 10) ?#)) "|"))
>>
>> (run-at-time 1 1 #'force-mode-line-update t)
>
> Thanks, I confirm the problem.

Thanks for checking.

>> A more realistic configuration with a timer (and a variable pitch face)
>> also shows the problem. A possible solution could be to handle
>> `tab-bar-format-align-right' in `tab-bar-format-list', such that the
>> functions in the `tab-bar-format' list after
>> `tab-bar-format-align-right' are not called twice, such that the
>> computed field width matches the displayed field.
>
> So need to update :align-to in tab-bar-format-list.

Yes, exactly.

Also another problem I've observed is that `string-pixel-width' is slow,
which is a problem with frequent updates/redisplays, for example when
scrolling a lot with `pixel-scroll-precision-mode'.

I suggest to update `:align-to' in `tab-bar-format-list' and also cache
the computed width and the formatted tab bar string. Then the cached
string can be compared with `equal-including-properties` and only if the
string changes, the pixel width needs to be recomputed.

Daniel

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Wed, 09 Jul 2025 09:32:39 +0300

close 78953 31.0.50
thanks

>>> A more realistic configuration with a timer (and a variable pitch face)
>>> also shows the problem. A possible solution could be to handle
>>> `tab-bar-format-align-right' in `tab-bar-format-list', such that the
>>> functions in the `tab-bar-format' list after
>>> `tab-bar-format-align-right' are not called twice, such that the
>>> computed field width matches the displayed field.

Now `tab-bar-format-list' and `tab-bar-format-align-right' are fixed
to not call `tab-bar-format-global' twice.

> Also another problem I've observed is that `string-pixel-width' is slow,
> which is a problem with frequent updates/redisplays, for example when
> scrolling a lot with `pixel-scroll-precision-mode'.
>
> I suggest to update `:align-to' in `tab-bar-format-list' and also cache
> the computed width and the formatted tab bar string. Then the cached
> string can be compared with `equal-including-properties` and only if the
> string changes, the pixel width needs to be recomputed.

Now the formatted tab bar string is cached as well.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Wed, 09 Jul 2025 09:14:59 +0200

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

> close 78953 31.0.50
> thanks
>
>>>> A more realistic configuration with a timer (and a variable pitch face)
>>>> also shows the problem. A possible solution could be to handle
>>>> `tab-bar-format-align-right' in `tab-bar-format-list', such that the
>>>> functions in the `tab-bar-format' list after
>>>> `tab-bar-format-align-right' are not called twice, such that the
>>>> computed field width matches the displayed field.
>
> Now `tab-bar-format-list' and `tab-bar-format-align-right' are fixed
> to not call `tab-bar-format-global' twice.
>
>> Also another problem I've observed is that `string-pixel-width' is slow,
>> which is a problem with frequent updates/redisplays, for example when
>> scrolling a lot with `pixel-scroll-precision-mode'.
>>
>> I suggest to update `:align-to' in `tab-bar-format-list' and also cache
>> the computed width and the formatted tab bar string. Then the cached
>> string can be compared with `equal-including-properties` and only if the
>> string changes, the pixel width needs to be recomputed.
>
> Now the formatted tab bar string is cached as well.

Thanks. I think the code should be simplified - in fact it is
problematic like this since it will leak memory, if the string changes,
for example for a timer which counts up, where the same string will only
needed for a short while. A hash table is not needed to memoize a single
pair. It suffices to only store the current string to optimize
redisplay. You could store the string in the car of a cons, and the
width in the cdr.

Daniel

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 09:41:34 +0300

>>>>> A more realistic configuration with a timer (and a variable pitch face)
>>>>> also shows the problem. A possible solution could be to handle
>>>>> `tab-bar-format-align-right' in `tab-bar-format-list', such that the
>>>>> functions in the `tab-bar-format' list after
>>>>> `tab-bar-format-align-right' are not called twice, such that the
>>>>> computed field width matches the displayed field.
>>
>> Now `tab-bar-format-list' and `tab-bar-format-align-right' are fixed
>> to not call `tab-bar-format-global' twice.
>>
>>> Also another problem I've observed is that `string-pixel-width' is slow,
>>> which is a problem with frequent updates/redisplays, for example when
>>> scrolling a lot with `pixel-scroll-precision-mode'.
>>>
>>> I suggest to update `:align-to' in `tab-bar-format-list' and also cache
>>> the computed width and the formatted tab bar string. Then the cached
>>> string can be compared with `equal-including-properties` and only if the
>>> string changes, the pixel width needs to be recomputed.
>>
>> Now the formatted tab bar string is cached as well.
>
> Thanks. I think the code should be simplified - in fact it is
> problematic like this since it will leak memory, if the string changes,
> for example for a timer which counts up, where the same string will only
> needed for a short while. A hash table is not needed to memoize a single
> pair. It suffices to only store the current string to optimize
> redisplay. You could store the string in the car of a cons, and the
> width in the cdr.

So you meant caching only the last string?  This is implemented now as well.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 09:53:04 +0200

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

>> Thanks. I think the code should be simplified - in fact it is
>> problematic like this since it will leak memory, if the string changes,
>> for example for a timer which counts up, where the same string will only
>> needed for a short while. A hash table is not needed to memoize a single
>> pair. It suffices to only store the current string to optimize
>> redisplay. You could store the string in the car of a cons, and the
>> width in the cdr.
>
> So you meant caching only the last string?  This is implemented now as well.

Yes, this is exactly what I meant. I will test it soon. Thanks again!

Daniel

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 15:04:12 +0200

Hello Juri,

Daniel Mendler <mail <at> daniel-mendler.de> writes:
> Juri Linkov <juri <at> linkov.net> writes:
>>> Thanks. I think the code should be simplified - in fact it is
>>> problematic like this since it will leak memory, if the string changes,
>>> for example for a timer which counts up, where the same string will only
>>> needed for a short while. A hash table is not needed to memoize a single
>>> pair. It suffices to only store the current string to optimize
>>> redisplay. You could store the string in the car of a cons, and the
>>> width in the cdr.
>>
>> So you meant caching only the last string?  This is implemented now as well.
>
> Yes, this is exactly what I meant. I will test it soon. Thanks again!

I have tested your patches and they work well. No flicker or jumping and
no negative performance impact due. Excellent work - also on the tab-bar
in general! I really appreciate the addition of this feature to Emacs.
It is particularly handy with EXWM where I can use it as system status
bar.

Since we are talking about the tab bar already I have another question -
sometimes (rarely) my tab bar gets too long and then it wraps around,
which I find undesirable. I would prefer if the content were truncated.
I suspect this is harder to address, e.g., via an option
tab-bar-truncate/tab-line-truncate? In any case, this is a rare edge
case in my usage.

Thanks.

> Daniel

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 09:16:46 -0400

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

On Thu, Jul 10, 2025 at 9:05 AM Daniel Mendler via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:

> Hello Juri,
>
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
> > Juri Linkov <juri <at> linkov.net> writes:
> >>> Thanks. I think the code should be simplified - in fact it is
> >>> problematic like this since it will leak memory, if the string changes,
> >>> for example for a timer which counts up, where the same string will
> only
> >>> needed for a short while. A hash table is not needed to memoize a
> single
> >>> pair. It suffices to only store the current string to optimize
> >>> redisplay. You could store the string in the car of a cons, and the
> >>> width in the cdr.
> >>
> >> So you meant caching only the last string?  This is implemented now as
> well.
> >
> > Yes, this is exactly what I meant. I will test it soon. Thanks again!
>
> I have tested your patches and they work well. No flicker or jumping and
> no negative performance impact due. Excellent work - also on the tab-bar
> in general! I really appreciate the addition of this feature to Emacs.
> It is particularly handy with EXWM where I can use it as system status
> bar.
>
> Since we are talking about the tab bar already I have another question -
> sometimes (rarely) my tab bar gets too long and then it wraps around,
> which I find undesirable. I would prefer if the content were truncated.
> I suspect this is harder to address, e.g., via an option
> tab-bar-truncate/tab-line-truncate? In any case, this is a rare edge
> case in my usage.
>

What if, instead, each tab's content would shrink to fit?  This is closer
to how web browsers fit tabs.  There are browser extensions that offer
multiple lines or scroll left/right, but I find those more annoying since I
can't see them all.  One can always hover over each tab to see what its
title is.  In my configuration, my help text lists the buffers (and it's
helpful to use the mouse-face support we added earlier in the year).

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

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 78953 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 15:23:45 +0200

Stéphane Marks <shipmints <at> gmail.com> writes:

> What if, instead, each tab's content would shrink to fit? This is
> closer to how web browsers fit tabs. There are browser extensions that
> offer multiple lines or scroll left/right, but I find those more
> annoying since I can't see them all.

Yes, this would be great, as long as each tab bar field would shrink,
not only the tabs themselves at the very left. For me the overflow
happens not only because I have too many tabs but because my system bar
gets too long.

However I suspect that such shrinking behavior is harder to implement
nicely, in contrast to simple truncation.

Daniel

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 09:30:11 -0400

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

On Thu, Jul 10, 2025 at 9:23 AM Daniel Mendler <mail <at> daniel-mendler.de>
wrote:

> Stéphane Marks <shipmints <at> gmail.com> writes:
>
> > What if, instead, each tab's content would shrink to fit? This is
> > closer to how web browsers fit tabs. There are browser extensions that
> > offer multiple lines or scroll left/right, but I find those more
> > annoying since I can't see them all.
>
> Yes, this would be great, as long as each tab bar field would shrink,
> not only the tabs themselves at the very left. For me the overflow
> happens not only because I have too many tabs but because my system bar
> gets too long.
>
> However I suspect that such shrinking behavior is harder to implement
> nicely, in contrast to simple truncation.
>

Reading through tab-bar for a feature I don't use, but maybe I should, is
`tab-bar-auto-width` and its controls `tab-bar-auto-width-max` and
`tab-bar-auto-width-min` so perhaps this feature already exists.

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

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 78953 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 15:34:52 +0200

Stéphane Marks <shipmints <at> gmail.com> writes:

> On Thu, Jul 10, 2025 at 9:23 AM Daniel Mendler <mail <at> daniel-mendler.de>
> wrote:
>
>> Stéphane Marks <shipmints <at> gmail.com> writes:
>>
>> > What if, instead, each tab's content would shrink to fit? This is
>> > closer to how web browsers fit tabs. There are browser extensions that
>> > offer multiple lines or scroll left/right, but I find those more
>> > annoying since I can't see them all.
>>
>> Yes, this would be great, as long as each tab bar field would shrink,
>> not only the tabs themselves at the very left. For me the overflow
>> happens not only because I have too many tabs but because my system bar
>> gets too long.
>>
>> However I suspect that such shrinking behavior is harder to implement
>> nicely, in contrast to simple truncation.
>>
>
> Reading through tab-bar for a feature I don't use, but maybe I should, is
> `tab-bar-auto-width` and its controls `tab-bar-auto-width-max` and
> `tab-bar-auto-width-min` so perhaps this feature already exists.

I see. This is exactly the feature which does not help for my use case,
since it only resizes the tabs and not all the other tab fields, which I
would like to truncate.

I would like to see an option `tab-bar-truncate' or `tab-line-truncate'
which simply prevent line wrapping, similar to the buffer variable
`truncate-lines'.

Daniel

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 09:39:43 -0400

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

On Thu, Jul 10, 2025 at 9:34 AM Daniel Mendler <mail <at> daniel-mendler.de>
wrote:

> Stéphane Marks <shipmints <at> gmail.com> writes:
>
> > On Thu, Jul 10, 2025 at 9:23 AM Daniel Mendler <mail <at> daniel-mendler.de>
> > wrote:
> >
> >> Stéphane Marks <shipmints <at> gmail.com> writes:
> >>
> >> > What if, instead, each tab's content would shrink to fit? This is
> >> > closer to how web browsers fit tabs. There are browser extensions that
> >> > offer multiple lines or scroll left/right, but I find those more
> >> > annoying since I can't see them all.
> >>
> >> Yes, this would be great, as long as each tab bar field would shrink,
> >> not only the tabs themselves at the very left. For me the overflow
> >> happens not only because I have too many tabs but because my system bar
> >> gets too long.
> >>
> >> However I suspect that such shrinking behavior is harder to implement
> >> nicely, in contrast to simple truncation.
> >>
> >
> > Reading through tab-bar for a feature I don't use, but maybe I should, is
> > `tab-bar-auto-width` and its controls `tab-bar-auto-width-max` and
> > `tab-bar-auto-width-min` so perhaps this feature already exists.
>
> I see. This is exactly the feature which does not help for my use case,
> since it only resizes the tabs and not all the other tab fields, which I
> would like to truncate.
>
> I would like to see an option `tab-bar-truncate' or `tab-line-truncate'
> which simply prevent line wrapping, similar to the buffer variable
> `truncate-lines'.
>

Perhaps customizing `tab-bar-auto-width-faces` and/or
`tab-bar-auto-width-functions` would allow relaxing field limits to your
taste.

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

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 78953 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 15:49:14 +0200

Stéphane Marks <shipmints <at> gmail.com> writes:

> On Thu, Jul 10, 2025 at 9:34 AM Daniel Mendler <mail <at> daniel-mendler.de>
> wrote:
>
>> Stéphane Marks <shipmints <at> gmail.com> writes:
>>
>> > On Thu, Jul 10, 2025 at 9:23 AM Daniel Mendler <mail <at> daniel-mendler.de>
>> > wrote:
>> >
>> >> Stéphane Marks <shipmints <at> gmail.com> writes:
>> >>
>> >> > What if, instead, each tab's content would shrink to fit? This is
>> >> > closer to how web browsers fit tabs. There are browser extensions that
>> >> > offer multiple lines or scroll left/right, but I find those more
>> >> > annoying since I can't see them all.
>> >>
>> >> Yes, this would be great, as long as each tab bar field would shrink,
>> >> not only the tabs themselves at the very left. For me the overflow
>> >> happens not only because I have too many tabs but because my system bar
>> >> gets too long.
>> >>
>> >> However I suspect that such shrinking behavior is harder to implement
>> >> nicely, in contrast to simple truncation.
>> >>
>> >
>> > Reading through tab-bar for a feature I don't use, but maybe I should, is
>> > `tab-bar-auto-width` and its controls `tab-bar-auto-width-max` and
>> > `tab-bar-auto-width-min` so perhaps this feature already exists.
>>
>> I see. This is exactly the feature which does not help for my use case,
>> since it only resizes the tabs and not all the other tab fields, which I
>> would like to truncate.
>>
>> I would like to see an option `tab-bar-truncate' or `tab-line-truncate'
>> which simply prevent line wrapping, similar to the buffer variable
>> `truncate-lines'.
>>
>
> Perhaps customizing `tab-bar-auto-width-faces` and/or
> `tab-bar-auto-width-functions` would allow relaxing field limits to your
> taste.

This looks interesting. But I just naively tried the following and Emacs
hangs up as result.

(setq tab-bar-auto-width t
      tab-bar-auto-width-functions (list #'always))

But the auto width setting leads to growing fields and this is not what
I want. I don't want that the tab fields grow. I want them to shrink
only in case of overflow. So maybe `tab-bar-auto-width` could be
extended to handle the values nil, t, or `no-grow'? And also another
auto width function could be added which handles non-tab fields too.

Daniel

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 10:16:33 -0400

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

On Thu, Jul 10, 2025 at 9:49 AM Daniel Mendler <mail <at> daniel-mendler.de>
wrote:

> Stéphane Marks <shipmints <at> gmail.com> writes:
>
> > On Thu, Jul 10, 2025 at 9:34 AM Daniel Mendler <mail <at> daniel-mendler.de>
> > wrote:
> >
> >> Stéphane Marks <shipmints <at> gmail.com> writes:
> >>
> >> > On Thu, Jul 10, 2025 at 9:23 AM Daniel Mendler <
> mail <at> daniel-mendler.de>
> >> > wrote:
> >> >
> >> >> Stéphane Marks <shipmints <at> gmail.com> writes:
> >> >>
> >> >> > What if, instead, each tab's content would shrink to fit? This is
> >> >> > closer to how web browsers fit tabs. There are browser extensions
> that
> >> >> > offer multiple lines or scroll left/right, but I find those more
> >> >> > annoying since I can't see them all.
> >> >>
> >> >> Yes, this would be great, as long as each tab bar field would shrink,
> >> >> not only the tabs themselves at the very left. For me the overflow
> >> >> happens not only because I have too many tabs but because my system
> bar
> >> >> gets too long.
> >> >>
> >> >> However I suspect that such shrinking behavior is harder to implement
> >> >> nicely, in contrast to simple truncation.
> >> >>
> >> >
> >> > Reading through tab-bar for a feature I don't use, but maybe I
> should, is
> >> > `tab-bar-auto-width` and its controls `tab-bar-auto-width-max` and
> >> > `tab-bar-auto-width-min` so perhaps this feature already exists.
> >>
> >> I see. This is exactly the feature which does not help for my use case,
> >> since it only resizes the tabs and not all the other tab fields, which I
> >> would like to truncate.
> >>
> >> I would like to see an option `tab-bar-truncate' or `tab-line-truncate'
> >> which simply prevent line wrapping, similar to the buffer variable
> >> `truncate-lines'.
> >>
> >
> > Perhaps customizing `tab-bar-auto-width-faces` and/or
> > `tab-bar-auto-width-functions` would allow relaxing field limits to your
> > taste.
>
> This looks interesting. But I just naively tried the following and Emacs
> hangs up as result.
>
> (setq tab-bar-auto-width t
>       tab-bar-auto-width-functions (list #'always))
>
> But the auto width setting leads to growing fields and this is not what
> I want. I don't want that the tab fields grow. I want them to shrink
> only in case of overflow. So maybe `tab-bar-auto-width` could be
> extended to handle the values nil, t, or `no-grow'? And also another
> auto width function could be added which handles non-tab fields too.
>

Seems sensible.  Not sure on the hang.  I'll leave that to Juri...

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

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org,
 Stéphane Marks <shipmints <at> gmail.com>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 21:24:50 +0300

> This looks interesting. But I just naively tried the following and Emacs
> hangs up as result.
>
> (setq tab-bar-auto-width t
>       tab-bar-auto-width-functions (list #'always))

This is a new bug report.

> But the auto width setting leads to growing fields and this is not what
> I want. I don't want that the tab fields grow. I want them to shrink
> only in case of overflow. So maybe `tab-bar-auto-width` could be
> extended to handle the values nil, t, or `no-grow'? And also another
> auto width function could be added which handles non-tab fields too.

This is a new feature request.  However, I doubt if it would be possible
to find a reasonable algorithm.  The current algorithm makes all tabs
equal size.  But with different sizes it's not clear what tabs to truncate.

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 21:20:16 +0300

> Since we are talking about the tab bar already I have another question -
> sometimes (rarely) my tab bar gets too long and then it wraps around,

It wraps around because the tab-bar is multi-line:
the number of tab-bar lines is defined by the frame parameter
'tab-bar-lines'.  So you can use more lines for text that
doesn't fit on the first line.

> which I find undesirable.

Is this when you set tab-bar-auto-width to nil?
Or the global string is too long?

> I would prefer if the content were truncated.

Can you truncate the global string inside :eval, e.g.

(setq global-mode-string
      '("|" (:eval (truncate-string-to-width (make-string 100 ?#) 10)) "|"))

> I suspect this is harder to address,

The wrapping is hard to disable.  So it's easier to truncate
the overly long strings.

> e.g., via an option tab-bar-truncate/tab-line-truncate? In any case,
> this is a rare edge case in my usage.

There are truncation options only for tab names, not for the global string.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 22:02:45 +0200

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

>> Since we are talking about the tab bar already I have another question -
>> sometimes (rarely) my tab bar gets too long and then it wraps around,
>
> It wraps around because the tab-bar is multi-line:
> the number of tab-bar lines is defined by the frame parameter
> 'tab-bar-lines'.  So you can use more lines for text that
> doesn't fit on the first line.

I would like to fix tab-bar-lines to be 1.

>> which I find undesirable.
>
> Is this when you set tab-bar-auto-width to nil?
> Or the global string is too long?

I set tab-bar-auto-width=nil in my config. Then the wrap around happens
if there are too many elements in the tab-bar-format list.

>> I would prefer if the content were truncated.
>
> Can you truncate the global string inside :eval, e.g.
>
> (setq global-mode-string
>       '("|" (:eval (truncate-string-to-width (make-string 100 ?#) 10)) "|"))

Of course, but this does not help if I have many elements in the
tab-bar-format list which I cannot truncate together with such a simple
expression.

>> I suspect this is harder to address,
>
> The wrapping is hard to disable.  So it's easier to truncate
> the overly long strings.

In my use case truncating the many overly long strings is not easy - I
would have to compute how much I have to take away from each element.
But I understand that disabling the overall wrap around is more
difficult since it has to be implement on a deeper level of the display
engine.

>> e.g., via an option tab-bar-truncate/tab-line-truncate? In any case,
>> this is a rare edge case in my usage.
>
> There are truncation options only for tab names, not for the global string.

Yes, therefore I proposed that such options could be added.

Daniel

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 78953 <at> debbugs.gnu.org,
 Stéphane Marks <shipmints <at> gmail.com>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Thu, 10 Jul 2025 22:06:45 +0200

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

>> This looks interesting. But I just naively tried the following and Emacs
>> hangs up as result.
>>
>> (setq tab-bar-auto-width t
>>       tab-bar-auto-width-functions (list #'always))
>
> This is a new bug report.
>
>> But the auto width setting leads to growing fields and this is not what
>> I want. I don't want that the tab fields grow. I want them to shrink
>> only in case of overflow. So maybe `tab-bar-auto-width` could be
>> extended to handle the values nil, t, or `no-grow'? And also another
>> auto width function could be added which handles non-tab fields too.
>
> This is a new feature request.  However, I doubt if it would be possible
> to find a reasonable algorithm.  The current algorithm makes all tabs
> equal size.  But with different sizes it's not clear what tabs to truncate.

Yes, I agree. Therefore I thought that it might be easiest to simply
disable the wrap around of the tab bar altogether. For my purpose with a
global status bar it would work well enough if the status bar overflows
and becomes partially hidden. Such an overflow is only a rare event. But
in the case of such an event, it is better if the tab bar stays on a
single line to avoid the jumpiness caused by the toggling from one to
two tab bar lines and back to one.

Daniel

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Fri, 11 Jul 2025 19:11:21 +0300

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

> But I understand that disabling the overall wrap around is more
> difficult since it has to be implement on a deeper level of the
> display engine.

Indeed, the required change is on a deeper level of the display engine,
but it's quite simple like in the attached patch.  I wonder is it
appropriate to reuse the existing option 'auto-resize-tab-bars'
whose new value 'truncate' will force tab-bar truncation:

[auto-resize-tab-bars-truncate.patch (text/x-diff, inline)]

diff --git a/src/xdisp.c b/src/xdisp.c
index 15a88f0868a..b3520be234f 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -14739,11 +14739,19 @@ tab_bar_height (struct frame *f, int *n_rows, bool pixelwise)
   it.paragraph_embedding = L2R;
 
   clear_glyph_row (temp_row);
-  while (!ITERATOR_AT_END_P (&it))
+  if (EQ (Vauto_resize_tab_bars, Qtruncate))
     {
       it.glyph_row = temp_row;
       display_tab_bar_line (&it, -1);
     }
+  else
+    {
+      while (!ITERATOR_AT_END_P (&it))
+	{
+	  it.glyph_row = temp_row;
+	  display_tab_bar_line (&it, -1);
+	}
+    }
   clear_glyph_row (temp_row);
 
   /* f->n_tab_bar_rows == 0 means "unknown"; -1 means no tab-bar.  */
@@ -37810,6 +37818,7 @@ syms_of_xdisp (void)
   DEFSYM (Qinhibit_menubar_update, "inhibit-menubar-update");
 
   DEFSYM (Qgrow_only, "grow-only");
+  DEFSYM (Qtruncate, "truncate");
   DEFSYM (Qinhibit_eval_during_redisplay, "inhibit-eval-during-redisplay");
   DEFSYM (Qposition, "position");
   DEFSYM (Qbuffer_position, "buffer-position");
@@ -38173,7 +38182,9 @@ syms_of_xdisp (void)
 that is needed to make all tab-bar items visible.
 If value is `grow-only', the tab-bar's height is only increased
 automatically; to decrease the tab-bar height, use \\[recenter],
-after setting `recenter-redisplay' to the value of t.  */);
+after setting `recenter-redisplay' to the value of t.
+If value is `truncate', the tab-bar is truncated, and only
+the first line of a long tab-bar is displayed.  */);
   Vauto_resize_tab_bars = Qt;
 
   DEFVAR_BOOL ("auto-raise-tab-bar-buttons", auto_raise_tab_bar_buttons_p,

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org,
 Stéphane Marks <shipmints <at> gmail.com>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Fri, 11 Jul 2025 19:13:04 +0300

>>> This looks interesting. But I just naively tried the following and Emacs
>>> hangs up as result.
>>>
>>> (setq tab-bar-auto-width t
>>>       tab-bar-auto-width-functions (list #'always))
>>
>> This is a new bug report.

Actually, 'tab-bar-auto-width-functions' is intended to return non-nil
only on tab items, not on separators or global strings.  This is
described in its docstring.  There is an example in
'tab-bar-auto-width-predicate-default' that uses
(string-match-p "\\`\\(?:current-tab\\|\\(?:group\\|tab\\)-\\)"
(symbol-name (nth 0 item))) to match tabs only.

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Fri, 11 Jul 2025 12:18:22 -0400

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

On Fri, Jul 11, 2025 at 12:14 PM Juri Linkov <juri <at> linkov.net> wrote:

> > But I understand that disabling the overall wrap around is more
> > difficult since it has to be implement on a deeper level of the
> > display engine.
>
> Indeed, the required change is on a deeper level of the display engine,
> but it's quite simple like in the attached patch.  I wonder is it
> appropriate to reuse the existing option 'auto-resize-tab-bars'
> whose new value 'truncate' will force tab-bar truncation:
>

I'd think maybe it should insert an ellipsis, or some other indicator, that
truncation has been done.

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

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Fri, 11 Jul 2025 18:36:00 +0200

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

>> But I understand that disabling the overall wrap around is more
>> difficult since it has to be implement on a deeper level of the
>> display engine.
>
> Indeed, the required change is on a deeper level of the display engine,
> but it's quite simple like in the attached patch.  I wonder is it
> appropriate to reuse the existing option 'auto-resize-tab-bars'
> whose new value 'truncate' will force tab-bar truncation:

Indeed, the patch seems simple enough. I am unsure about reusing the
option. If I understand correctly `auto-resize-tab-bars' is about
resizing the height according to the face? I think we want to control
both things separately, truncation and resizing of the height. Therefore
I would rather add another option `truncate-tab-bars'. What do you
think?

Daniel

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 78953 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Fri, 11 Jul 2025 18:43:12 +0200

Stéphane Marks <shipmints <at> gmail.com> writes:

> On Fri, Jul 11, 2025 at 12:14 PM Juri Linkov <juri <at> linkov.net> wrote:
>
>> > But I understand that disabling the overall wrap around is more
>> > difficult since it has to be implement on a deeper level of the
>> > display engine.
>>
>> Indeed, the required change is on a deeper level of the display engine,
>> but it's quite simple like in the attached patch.  I wonder is it
>> appropriate to reuse the existing option 'auto-resize-tab-bars'
>> whose new value 'truncate' will force tab-bar truncation:
>>
>
> I'd think maybe it should insert an ellipsis, or some other indicator, that
> truncation has been done.

I would not really need such an indication, but why not. For me it is
mainly important that I can prevent jumping behavior - this affects
multiple display parts of Emacs. I also don't like if the echo area
resizes, and I configured it such that it stays at height 1. For
vertical completion the minibuffer necessarily has to resize, but the
window jumpiness because of cursor visibility still hurts. There are
projects like https://github.com/neeasade/stillness-mode.el which try to
prevent this, but these are hacks which makes me worry about robustness.

Daniel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 78953 <at> debbugs.gnu.org, mail <at> daniel-mendler.de, juri <at> linkov.net
Subject: Re: bug#78953: 31.0.50;
 tab-bar-format-align-right alignment breaks if field widths change
Date: Fri, 11 Jul 2025 22:03:36 +0300

> Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 78953 <at> debbugs.gnu.org
> From: Stéphane Marks <shipmints <at> gmail.com>
> Date: Fri, 11 Jul 2025 12:18:22 -0400
> 
> On Fri, Jul 11, 2025 at 12:14 PM Juri Linkov <juri <at> linkov.net> wrote:
> 
>  > But I understand that disabling the overall wrap around is more
>  > difficult since it has to be implement on a deeper level of the
>  > display engine.
> 
>  Indeed, the required change is on a deeper level of the display engine,
>  but it's quite simple like in the attached patch.  I wonder is it
>  appropriate to reuse the existing option 'auto-resize-tab-bars'
>  whose new value 'truncate' will force tab-bar truncation:
> 
> I'd think maybe it should insert an ellipsis, or some other indicator, that truncation has been done.

No, we don't produce any such indications in special screen lines,
like mode line. menu bar, etc.  So I don't see why we would need that
here.

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78953 <at> debbugs.gnu.org, mail <at> daniel-mendler.de, juri <at> linkov.net
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Fri, 11 Jul 2025 17:03:06 -0400

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

On Fri, Jul 11, 2025 at 3:03 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 78953 <at> debbugs.gnu.org
> > From: Stéphane Marks <shipmints <at> gmail.com>
> > Date: Fri, 11 Jul 2025 12:18:22 -0400
> >
> > On Fri, Jul 11, 2025 at 12:14 PM Juri Linkov <juri <at> linkov.net> wrote:
> >
> >  > But I understand that disabling the overall wrap around is more
> >  > difficult since it has to be implement on a deeper level of the
> >  > display engine.
> >
> >  Indeed, the required change is on a deeper level of the display engine,
> >  but it's quite simple like in the attached patch.  I wonder is it
> >  appropriate to reuse the existing option 'auto-resize-tab-bars'
> >  whose new value 'truncate' will force tab-bar truncation:
> >
> > I'd think maybe it should insert an ellipsis, or some other indicator,
> that truncation has been done.
>
> No, we don't produce any such indications in special screen lines,
> like mode line. menu bar, etc.  So I don't see why we would need that
> here.
>

I suppose since the user would enable this explicitly, and if the
documentation says it truncates without saying that an indicator is shown,
users get what they ask for.  I'd thought it would be nice as a visual
courtesy akin to truncate-line indicators.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 78953 <at> debbugs.gnu.org, mail <at> daniel-mendler.de, juri <at> linkov.net
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Sat, 12 Jul 2025 09:14:49 +0300

> From: Stéphane Marks <shipmints <at> gmail.com>
> Date: Fri, 11 Jul 2025 17:03:06 -0400
> Cc: juri <at> linkov.net, mail <at> daniel-mendler.de, 78953 <at> debbugs.gnu.org
> 
>  No, we don't produce any such indications in special screen lines,
>  like mode line. menu bar, etc.  So I don't see why we would need that
>  here.
> 
> I suppose since the user would enable this explicitly, and if the documentation says it truncates without
> saying that an indicator is shown, users get what they ask for.  I'd thought it would be nice as a visual
> courtesy akin to truncate-line indicators.

truncate-lines indicators are shown only for buffer text, and even
then only in the text-area, not in the margins.  Don't forget that the
indicator itself needs space to show it, so it uses up the screen
estate that is at premium in the cases of mode line, tab line etc.

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Sun, 13 Jul 2025 09:52:10 +0300

> Indeed, the patch seems simple enough. I am unsure about reusing the
> option. If I understand correctly `auto-resize-tab-bars' is about
> resizing the height according to the face? I think we want to control
> both things separately, truncation and resizing of the height. Therefore
> I would rather add another option `truncate-tab-bars'. What do you
> think?

The name `auto-resize-tab-bars' was created for compatibility
with the `auto-resize-tool-bars'.  But for new variables better
to use the prefix `tab-bar-'.  Then the name would be `tab-bar-truncate'.

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Sun, 13 Jul 2025 20:12:17 +0300

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

>> Indeed, the patch seems simple enough. I am unsure about reusing the
>> option. If I understand correctly `auto-resize-tab-bars' is about
>> resizing the height according to the face? I think we want to control
>> both things separately, truncation and resizing of the height. Therefore
>> I would rather add another option `truncate-tab-bars'. What do you
>> think?
>
> The name `auto-resize-tab-bars' was created for compatibility
> with the `auto-resize-tool-bars'.  But for new variables better
> to use the prefix `tab-bar-'.  Then the name would be `tab-bar-truncate'.

Ok, I will push the patch with the new name:

[tab-bar-truncate.patch (text/x-diff, inline)]

diff --git a/src/xdisp.c b/src/xdisp.c
index 15a88f0868a..992d162f2e3 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -14739,11 +14739,19 @@ tab_bar_height (struct frame *f, int *n_rows, bool pixelwise)
   it.paragraph_embedding = L2R;
 
   clear_glyph_row (temp_row);
-  while (!ITERATOR_AT_END_P (&it))
+  if (tab_bar_truncate)
     {
       it.glyph_row = temp_row;
       display_tab_bar_line (&it, -1);
     }
+  else
+    {
+      while (!ITERATOR_AT_END_P (&it))
+	{
+	  it.glyph_row = temp_row;
+	  display_tab_bar_line (&it, -1);
+	}
+    }
   clear_glyph_row (temp_row);
 
   /* f->n_tab_bar_rows == 0 means "unknown"; -1 means no tab-bar.  */
@@ -38209,6 +38217,10 @@ syms_of_xdisp (void)
   DEFSYM (Qmake_window_start_visible, "make-window-start-visible");
   Fmake_variable_buffer_local (Qmake_window_start_visible);
 
+  DEFVAR_BOOL ("tab-bar-truncate", tab_bar_truncate,
+    doc: /* Non-nil means truncate tab-bar and show only one line.  */);
+  tab_bar_truncate = false;
+
   DEFSYM (Qclose_tab, "close-tab");
   DEFVAR_LISP ("tab-bar-border", Vtab_bar_border,
     doc: /* Border below tab-bar in pixels.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Sun, 13 Jul 2025 20:15:07 +0200

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

>>> Indeed, the patch seems simple enough. I am unsure about reusing the
>>> option. If I understand correctly `auto-resize-tab-bars' is about
>>> resizing the height according to the face? I think we want to control
>>> both things separately, truncation and resizing of the height. Therefore
>>> I would rather add another option `truncate-tab-bars'. What do you
>>> think?
>>
>> The name `auto-resize-tab-bars' was created for compatibility
>> with the `auto-resize-tool-bars'.  But for new variables better
>> to use the prefix `tab-bar-'.  Then the name would be `tab-bar-truncate'.
>
> Ok, I will push the patch with the new name:

Thanks, this looks good.

Daniel

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

From: Juri Linkov <juri <at> linkov.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 78953 <at> debbugs.gnu.org
Subject: Re: bug#78953: 31.0.50; tab-bar-format-align-right alignment breaks
 if field widths change
Date: Mon, 14 Jul 2025 09:46:31 +0300

>>> The name `auto-resize-tab-bars' was created for compatibility
>>> with the `auto-resize-tool-bars'.  But for new variables better
>>> to use the prefix `tab-bar-'.  Then the name would be `tab-bar-truncate'.
>>
>> Ok, I will push the patch with the new name:
>
> Thanks, this looks good.

So now pushed.  Thanks for good suggestions.

Previous Next

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