bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Claudio Grondi]

To: bug-gnu-emacs@gnu.org
Subject: 29.0.60; Tabs are not showing the right names of the buffers

--text follows this line--

I have switched in between from gtk to lucid observing the mentioned issue.

See 
https://emacs.stackexchange.com/questions/76593/bug-or-feature-click-on-tab-does-not-give-the-buffer-with-the-shown-buffer-name

This should be easy to reproduce, right?

Can you reproduce it?



In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
  version 1.16.0, Xaw3d scroll bars) of 2023-03-30 built on OoO
Repository revision: 4508a024e81834cfb01c6f7984182e1a6cbb91ea
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Linux Mint 21

Configured using:
  'configure --with-x-toolkit=lucid --with-imagemagick'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2 XPM
LUCID ZLIB

Important settings:
   value of $LC_MONETARY: C.UTF-8
   value of $LC_NUMERIC: C.UTF-8
   value of $LC_TIME: C.UTF-8
   value of $LANG: C.UTF-8
   value of $XMODIFIERS: @im=none
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   shell-dirtrack-mode: t
   delete-selection-mode: t
   save-place-mode: t
   display-time-mode: t
   cua-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   tab-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   column-number-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
/home/neo/.emacs.d/elpa/svg-1.1/svg hides 
/usr/local/share/emacs/29.0.60/lisp/svg
/home/neo/.emacs.d/elpa/cl-lib-0.7.1/cl-lib hides 
/usr/local/share/emacs/29.0.60/lisp/emacs-lisp/cl-lib

Features:
(shadow sort mail-extr emacsbug message yank-media puny rfc822 mml
mml-sec epa derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils find-func ffap
descr-text cus-edit wid-edit battery thingatpt cus-start ido
find-desktop cua-rect rect tramp-archive tramp-gvfs tramp-cache
time-stamp zeroconf dbus xml tramp tramp-loaddefs trampver
tramp-integration tramp-compat parse-time iso8601 ls-lisp format-spec
mule-util display-line-numbers sh-script smie executable files-x shell
pcomplete cl-print ielm pp shortdoc text-property-search help-fns
radix-tree python rx project pcase treesit comint ansi-osc ring
ansi-color dired-aux dired dired-loaddefs tab-line time-date nlinum
linum finder-inf cl-extra help-mode icons delsel saveplace time desktop
frameset cua-base cus-load moe-theme-autoloads system-packages-autoloads
rainbow-mode-autoloads paredit-autoloads info orderless-autoloads
mines-autoloads luwak-autoloads tiny-autoloads which-key-autoloads
edit-indirect-autoloads shell-command+-autoloads dired-du-autoloads
svg-autoloads svg-lib-autoloads smooth-scroll-autoloads
treeview-autoloads ascii-art-to-unicode-autoloads vlf-autoloads
smartparens-autoloads grip-mode-autoloads wgrep-autoloads
good-scroll-autoloads sublimity-autoloads nlinum-autoloads
minimap-autoloads relint-autoloads xr-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 311408 42936)
  (symbols 48 17954 0)
  (strings 32 85419 3768)
  (string-bytes 1 2223226)
  (vectors 16 31835)
  (vector-slots 8 401609 16274)
  (floats 8 180 376)
  (intervals 56 5171 4520)
  (buffers 984 22))

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Eli Zaretskii]

> Date: Fri, 31 Mar 2023 23:06:02 +0200
> From: Claudio Grondi <claudio.grondi@freenet.de>
> 
> I have switched in between from gtk to lucid observing the mentioned issue.
> 
> See 
> https://emacs.stackexchange.com/questions/76593/bug-or-feature-click-on-tab-does-not-give-the-buffer-with-the-shown-buffer-name

Please always report bugs with all the details included in the
report.  Please do NOT just cite a report posted elsewhere, but
include all the details here.  We want our bug tracker to have all the
information, and do not want to depend on some other site, which may
or may not keep this information for the years to come.

> This should be easy to reproduce, right?

I don't know, because you didn't show the steps for reproducing the
problem, neither here nor on SE.  The description on SE starts in the
middle of a situation without telling how to get to that situation
starting from "emacs -Q".  Can you describe those steps, please?

> Can you reproduce it?

Not if I try to do so naïvely.  Here's what I tried:

  emacs -Q
  M-x tab-bar-mode RET
  click on the "+" to add a new tab
  C-x C-f ~/.emacs RET

Now I have two tabs: one showing "*scratch*", the other showing
".emacs".  Clicking on a tab causes Emacs to display the buffer whose
name is on the tab I click.

Does this mean the problem is not reproduced here?

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Claudio Grondi]

Below the steps required to reproduce the bug:

1. ~ $ emacs -Q
2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
3. 1x click on rightmost * in the Tab Bar to create a new Tab (gives 2x 
*scratch* Tabs)
4. With the rightmost (second) Tab open ~/.emacs (gives 1x *scratch* and 
1x .emacs Tabs)
5. 2x click on rightmost * in the Tab Bar to create twp new Tabs (gives 
1x *scratch* and 3x .emacs Tabs)
6. with rightmost Tab active kill the .emacs buffer [C-x k] (the Tabs 
label turns  to *scratch the other two Tabs labeled .emacs keep their 
labels, so there are 1x *scratch*, 2x .emacs, 1x *scratch* Tabs)
7. *click the second Tab labeled* .emacs' (result: the label of the Tab 
turns to *Messages*. the Tab Bar shows *scratch* *Messages* .emacs 
*scratch* )

The bug: the third Tab still keeps its  .emacs  label, the click on the 
second Tab labeled  .emacs  did not show the .emacs file, but the buffer 
*Messages*.

See also  https://emacs.stackexchange.com/a/76601/40171


On 4/1/23 07:37, Eli Zaretskii wrote:
>> Date: Fri, 31 Mar 2023 23:06:02 +0200
>> From: Claudio Grondi <claudio.grondi@freenet.de>
>>
>> I have switched in between from gtk to lucid observing the mentioned issue.
>>
>> See
>> https://emacs.stackexchange.com/questions/76593/bug-or-feature-click-on-tab-does-not-give-the-buffer-with-the-shown-buffer-name
> Please always report bugs with all the details included in the
> report.  Please do NOT just cite a report posted elsewhere, but
> include all the details here.  We want our bug tracker to have all the
> information, and do not want to depend on some other site, which may
> or may not keep this information for the years to come.
>
>> This should be easy to reproduce, right?
> I don't know, because you didn't show the steps for reproducing the
> problem, neither here nor on SE.  The description on SE starts in the
> middle of a situation without telling how to get to that situation
> starting from "emacs -Q".  Can you describe those steps, please?
>
>> Can you reproduce it?
> Not if I try to do so naïvely.  Here's what I tried:
>
>    emacs -Q
>    M-x tab-bar-mode RET
>    click on the "+" to add a new tab
>    C-x C-f ~/.emacs RET
>
> Now I have two tabs: one showing "*scratch*", the other showing
> ".emacs".  Clicking on a tab causes Emacs to display the buffer whose
> name is on the tab I click.
>
> Does this mean the problem is not reproduced here?

No, you haven't created the situation shown in the images with 3x .emacs 
Tabs.

You ask probably only to force me to provide a textual description as I 
assume you know exactly that what you described can't show the buggy 
behavior.

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Claudio Grondi <claudio.grondi@freenet.de> writes:

> Below the steps required to reproduce the bug:
>
> 1. ~ $ emacs -Q
> 2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
> 3. 1x click on rightmost * in the Tab Bar to create a new Tab (gives 2x
> *scratch* Tabs)
> 4. With the rightmost (second) Tab open ~/.emacs (gives 1x *scratch* and 1x
> .emacs Tabs)
> 5. 2x click on rightmost * in the Tab Bar to create twp new Tabs (gives 1x
> *scratch* and 3x .emacs Tabs)
> 6. with rightmost Tab active kill the .emacs buffer [C-x k] (the Tabs label
> turns  to *scratch the other two Tabs labeled .emacs keep their labels, so there
> are 1x *scratch*, 2x .emacs, 1x *scratch* Tabs)
> 7. *click the second Tab labeled* .emacs' (result: the label of the Tab turns to
> *Messages*. the Tab Bar shows *scratch* *Messages* .emacs *scratch* )
>
> The bug: the third Tab still keeps its  .emacs  label, the click on the second
> Tab labeled  .emacs  did not show the .emacs file, but the buffer *Messages*.

Can reproduce in 30 (db7e95531ac36ae842787b6c5f2859d0642c78cc) and 28.2
(tagged) -- so even if this is a regression, it would not be a recent
one.

Essentially, the reported bug can be summarized as: the tab names on a
tab bar do not respond to situations where a buffer has been deleted.

In addition, I noticed that this behavior extends to renaming a buffer
as well (tried it in 30, not in 28.2).  The reproducer is to replace (6)
above with the following, and observe that the other tabs do not update
their names until you click on them.

    C-x x r hello RET

-- 
Best,


RY

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Eli Zaretskii]

> Date: Sat, 1 Apr 2023 13:19:51 +0200
> Cc: 62575@debbugs.gnu.org
> From: Claudio Grondi <claudio.grondi@freenet.de>
> 
> Below the steps required to reproduce the bug:
> 
> 1. ~ $ emacs -Q
> 2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
> 3. 1x click on rightmost * in the Tab Bar to create a new Tab (gives 2x 
> *scratch* Tabs)
> 4. With the rightmost (second) Tab open ~/.emacs (gives 1x *scratch* and 
> 1x .emacs Tabs)
> 5. 2x click on rightmost * in the Tab Bar to create twp new Tabs (gives 
> 1x *scratch* and 3x .emacs Tabs)
> 6. with rightmost Tab active kill the .emacs buffer [C-x k] (the Tabs 
> label turns  to *scratch the other two Tabs labeled .emacs keep their 
> labels, so there are 1x *scratch*, 2x .emacs, 1x *scratch* Tabs)
> 7. *click the second Tab labeled* .emacs' (result: the label of the Tab 
> turns to *Messages*. the Tab Bar shows *scratch* *Messages* .emacs 
> *scratch* )
> 
> The bug: the third Tab still keeps its  .emacs  label, the click on the 
> second Tab labeled  .emacs  did not show the .emacs file, but the buffer 
> *Messages*.

Thanks.  Now I see the problem and can work on fixing it.

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Claudio Grondi]

Along with this I have also noticed following problem:

1. ~ $ emacs -Q
2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
3. resize the Emacs window to a small one, but large enough to show some Tab labels
3. 1x click on rightmost * in the Tab Bar to create a new Tab

The bug: No new Tab will be created and the minibuf and *Messages* show:

   split-window: Window #<window 3 on *Messages*> too small for splitting

Is it worth a new bug number?


On 4/1/23 13:38, Ruijie Yu wrote:

> Claudio Grondi <claudio.grondi@freenet.de> writes:
>
>> Below the steps required to reproduce the bug:
>>
>> 1. ~ $ emacs -Q
>> 2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
>> 3. 1x click on rightmost * in the Tab Bar to create a new Tab (gives 2x
>> *scratch* Tabs)
>> 4. With the rightmost (second) Tab open ~/.emacs (gives 1x *scratch* and 1x
>> .emacs Tabs)
>> 5. 2x click on rightmost * in the Tab Bar to create twp new Tabs (gives 1x
>> *scratch* and 3x .emacs Tabs)
>> 6. with rightmost Tab active kill the .emacs buffer [C-x k] (the Tabs label
>> turns  to *scratch the other two Tabs labeled .emacs keep their labels, so there
>> are 1x *scratch*, 2x .emacs, 1x *scratch* Tabs)
>> 7. *click the second Tab labeled* .emacs' (result: the label of the Tab turns to
>> *Messages*. the Tab Bar shows *scratch* *Messages* .emacs *scratch* )
>>
>> The bug: the third Tab still keeps its  .emacs  label, the click on the second
>> Tab labeled  .emacs  did not show the .emacs file, but the buffer *Messages*.
> Can reproduce in 30 (db7e95531ac36ae842787b6c5f2859d0642c78cc) and 28.2
> (tagged) -- so even if this is a regression, it would not be a recent
> one.
>
> Essentially, the reported bug can be summarized as: the tab names on a
> tab bar do not respond to situations where a buffer has been deleted.
>
> In addition, I noticed that this behavior extends to renaming a buffer
> as well (tried it in 30, not in 28.2).  The reproducer is to replace (6)
> above with the following, and observe that the other tabs do not update
> their names until you click on them.
>
>      C-x x r hello RET
>

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Eli Zaretskii]

> Date: Sat, 1 Apr 2023 14:28:14 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 62575@debbugs.gnu.org
> From: Claudio Grondi <claudio.grondi@freenet.de>
> 
> 
> Along with this I have also noticed following problem:
> 
> 1. ~ $ emacs -Q
> 2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
> 3. resize the Emacs window to a small one, but large enough to show some Tab labels
> 3. 1x click on rightmost * in the Tab Bar to create a new Tab
> 
> The bug: No new Tab will be created and the minibuf and *Messages* show:
> 
>    split-window: Window #<window 3 on *Messages*> too small for splitting
> 
> Is it worth a new bug number?

Yes, please.

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Eli Zaretskii]

> Date: Sat, 1 Apr 2023 13:19:51 +0200
> Cc: 62575@debbugs.gnu.org
> From: Claudio Grondi <claudio.grondi@freenet.de>
> 
> Below the steps required to reproduce the bug:
> 
> 1. ~ $ emacs -Q
> 2. Menu -> Options -> Show/Hide -> Tab Bar (gives Tab *scratch*)
> 3. 1x click on rightmost * in the Tab Bar to create a new Tab (gives 2x 
> *scratch* Tabs)
> 4. With the rightmost (second) Tab open ~/.emacs (gives 1x *scratch* and 
> 1x .emacs Tabs)
> 5. 2x click on rightmost * in the Tab Bar to create twp new Tabs (gives 
> 1x *scratch* and 3x .emacs Tabs)
> 6. with rightmost Tab active kill the .emacs buffer [C-x k] (the Tabs 
> label turns  to *scratch the other two Tabs labeled .emacs keep their 
> labels, so there are 1x *scratch*, 2x .emacs, 1x *scratch* Tabs)
> 7. *click the second Tab labeled* .emacs' (result: the label of the Tab 
> turns to *Messages*. the Tab Bar shows *scratch* *Messages* .emacs 
> *scratch* )
> 
> The bug: the third Tab still keeps its  .emacs  label, the click on the 
> second Tab labeled  .emacs  did not show the .emacs file, but the buffer 
> *Messages*.

After looking at the code, I'm not sure this is a bug.  The tab names
are just labels, although they are conveniently set to the name of the
buffer in the window to be selected when the tab is current.  But
otherwise they are just labels.  When you click on the tab, its name
is updated to reflect the buffer shown in the selected window, so I
think Emacs is behaving correctly, although it might be a bit
unexpected.

Juri, am I right?  If not, where is the code that's supposed to update
the labels when some buffers or windows are deleted or renamed?

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Juri Linkov]

>> The bug: the third Tab still keeps its  .emacs  label, the click on the 
>> second Tab labeled  .emacs  did not show the .emacs file, but the buffer 
>> *Messages*.
>
> After looking at the code, I'm not sure this is a bug.  The tab names
> are just labels, although they are conveniently set to the name of the
> buffer in the window to be selected when the tab is current.  But
> otherwise they are just labels.  When you click on the tab, its name
> is updated to reflect the buffer shown in the selected window, so I
> think Emacs is behaving correctly, although it might be a bit
> unexpected.
>
> Juri, am I right?  If not, where is the code that's supposed to update
> the labels when some buffers or windows are deleted or renamed?

Right, tab names are just labels, or by another analogy are "bookmarks".
It was a design decision to keep labels even after a buffer is killed,
so the users know what buffer was displayed in the tab created to
display that buffer.

What we could do is to help to create additional code that could be
used to update tab names according to user wishes.

But the problem is that there are too many ways to do this,
so the implementation logic is too fuzzy and not well defined.
Here are some considerations that could be took into account:

1. First there is no need to update tabs with names set explicitly
   by 'tab-rename' (C-x t r).

2. Also no need to update a tab name when non-current buffers
   are killed on a window configuration saved to the tab,
   in case when tab-bar-tab-name-function is unchanged from
   its default value tab-bar-tab-name-current.  However,
   when it's customized to tab-bar-tab-name-all, then
   killing any buffer on the window configuration can change
   the tab name.  There are other values that may or may not
   change the tab name after the buffer is killed.

3. It seems the reported wish was to rename the tab
   after the buffer was killed.  But I imagine some users
   instead might prefer to automatically close all tabs that
   displayed the killed buffer.  This also makes sense.

4. As noted by Ruijie, the code should react not only
   to killing a buffer, but also to renaming a buffer.
   This means that instead of using kill-buffer-hook,
   it should rely on buffer-list-update-hook, but
   the problem is that buffer-list-update-hook is
   not called with a buffer name, so need to develop
   much more complicated code.

I invite Claudio and anyone to try the code I wrote
for bug#52019 and bug#60096 as a staring point.
Then after fulfilling the expectations, it could be
later added to tab-bar.el as an option:

;; Visit affected tabs to update their names:
(add-hook 'kill-buffer-hook
          (lambda ()
            (let ((tabs (reverse
                         (mapcar (lambda (tab) (1+ (alist-get 'index tab)))
                                 (tab-bar-get-buffer-tab nil t nil t)))))
              (run-with-timer
               0 nil
               (lambda (tabs) (dolist (tab tabs) (tab-bar-select-tab tab)))
               tabs))))

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Claudio Grondi]

 From what I understand reading Juris response the core of the problem 
and reason for the issue is lack of unambiguous concept of what a Tab 
Bar is and what the Tabs in the Tab Bar represent.

On one side the Tab Bar is considered as an aid helping to switch view 
to another buffer by clicking on a Tab, on the other side what is 
actually shown after clicking a Tab Bar is not a visualization of a 
buffer but visualization of what is sometimes called "root window", 
sometimes "window configuration", sometimes "window" and sometimes a 
"frame" (it is the messing around with concepts what makes it so hard to 
know what is right and what is wrong).

To my current state of knowledge the Tabs in the Tab Bar represent in 
the context of Emacs what in context of an OS Desktop is called 
Workspace. The only difference of an Emacs Tab to a Workspace is that 
the Emacs Tab does not allow empty space not filled with a window 
showing visualization of some elisp object called a buffer.

It is on one side a mess to call the file saving Emacs state 
.emacs.desktop suggesting that it is a desktop saved and not a 'frame' 
or a 'set of window configurations', on the other side in my eyes 
already the right wording for saving the state of all of the Workspaces 
called Tabs in a Tab Bar.

My suggestion in this context would be not to work on a patch or on 
adding one more option, but to fix the problem with lack of an 
unambiguous concepts for 'frame', 'window', 'root window', 'window 
configuration', 'tab in tab-bar' first. I am aware that doing this would 
require to rewrite almost the entire Emacs documentation - but it 
appears in my eyes worth it considering the future benefits of a clear 
structure and well defined vocabulary to use while speaking about Emacs.

Anyway: if you click a button labeled "OK" you expect that the result of 
it would be confirmation and not a change of a button label to "Cancel". 
If you click a Menu item labeled "Open File" you expect that it will 
result in a process of opening a file and not in changing the label 
"Open File" to "Close File" or another one. Generally you expect by 
clicking on a button or a Tab or elsewhere that it would result in what 
is stated as text labeling it.

How much of overall confusion is needed in order to not be able to see 
such an obvious fact? Considering keeping a label on a button which text 
does not represent the action which will be triggered by clicking it a 
"design decision" worth to be preserved appears in my eyes just insane. 
How does it come you don't see it the same way I do???

Am ** I ** insane expecting that clicking a button labeled "show me 
buffer X" will show me buffer X???

---

By the way:

I have placed the below provided code into my Emacs initialization file 
and the issue is gone. On killing the buffer the labels on Tabs in the 
Tab Bar are updated. Thanks :) .

What still remains is the issue with renaming a buffer, enforcing my 
believe that fixing the problem with lack of a well unambiguous 
concept/definition of what a buffer, a tab-bar, a window, a tab, etc. 
actually represent will fix this and all similar issues just as a 
side-effect.


On 4/2/23 08:48, Juri Linkov wrote:
>>> The bug: the third Tab still keeps its  .emacs  label, the click on the
>>> second Tab labeled  .emacs  did not show the .emacs file, but the buffer
>>> *Messages*.
>> After looking at the code, I'm not sure this is a bug.  The tab names
>> are just labels, although they are conveniently set to the name of the
>> buffer in the window to be selected when the tab is current.  But
>> otherwise they are just labels.  When you click on the tab, its name
>> is updated to reflect the buffer shown in the selected window, so I
>> think Emacs is behaving correctly, although it might be a bit
>> unexpected.
>>
>> Juri, am I right?  If not, where is the code that's supposed to update
>> the labels when some buffers or windows are deleted or renamed?
> Right, tab names are just labels, or by another analogy are "bookmarks".
> It was a design decision to keep labels even after a buffer is killed,
> so the users know what buffer was displayed in the tab created to
> display that buffer.
>
> What we could do is to help to create additional code that could be
> used to update tab names according to user wishes.
>
> But the problem is that there are too many ways to do this,
> so the implementation logic is too fuzzy and not well defined.
> Here are some considerations that could be took into account:
>
> 1. First there is no need to update tabs with names set explicitly
>     by 'tab-rename' (C-x t r).
>
> 2. Also no need to update a tab name when non-current buffers
>     are killed on a window configuration saved to the tab,
>     in case when tab-bar-tab-name-function is unchanged from
>     its default value tab-bar-tab-name-current.  However,
>     when it's customized to tab-bar-tab-name-all, then
>     killing any buffer on the window configuration can change
>     the tab name.  There are other values that may or may not
>     change the tab name after the buffer is killed.
>
> 3. It seems the reported wish was to rename the tab
>     after the buffer was killed.  But I imagine some users
>     instead might prefer to automatically close all tabs that
>     displayed the killed buffer.  This also makes sense.
>
> 4. As noted by Ruijie, the code should react not only
>     to killing a buffer, but also to renaming a buffer.
>     This means that instead of using kill-buffer-hook,
>     it should rely on buffer-list-update-hook, but
>     the problem is that buffer-list-update-hook is
>     not called with a buffer name, so need to develop
>     much more complicated code.
>
> I invite Claudio and anyone to try the code I wrote
> for bug#52019 and bug#60096 as a staring point.
> Then after fulfilling the expectations, it could be
> later added to tab-bar.el as an option:
>
> ;; Visit affected tabs to update their names:
> (add-hook 'kill-buffer-hook
>            (lambda ()
>              (let ((tabs (reverse
>                           (mapcar (lambda (tab) (1+ (alist-get 'index tab)))
>                                   (tab-bar-get-buffer-tab nil t nil t)))))
>                (run-with-timer
>                 0 nil
>                 (lambda (tabs) (dolist (tab tabs) (tab-bar-select-tab tab)))
>                 tabs))))

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Juri Linkov]

> Am ** I ** insane expecting that clicking a button labeled "show me buffer
> X" will show me buffer X???

Then maybe you need to use the tab-line.  Clicking on a tab with
a buffer name in global-tab-line-mode will always show you that buffer.

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Claudio Grondi]

OK ... I have tried it out, but the tab-line seems also to have its 
problems. Here how to reproduce what I mean should not happen:

1. emacs -Q

2. switch to visible tab-line.

3. create a help buffer, visit the *Messages* buffer and then:

4. type M-x TAB TAB to create a list of completions.

5. Use the modeline of the window showing *scratch*, *Messages*, ...  to 
show the buffer *Completions*

6. Use the modeline to get back to one of the other buffers

The "bug" is that clicking on the now visible tab *Completions* in the 
tab-line will show the *Completions* buffer, but there will be no 
tab-line anymore there to click to get back to the other buffers.

Is it a bug of a tab-line or a feature?

 From my perspective just only weird and not consistent behavior.


On 4/2/23 18:29, Juri Linkov wrote:
>> Am ** I ** insane expecting that clicking a button labeled "show me buffer
>> X" will show me buffer X???
> Then maybe you need to use the tab-line.  Clicking on a tab with
> a buffer name in global-tab-line-mode will always show you that buffer.

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Juri Linkov]

> The "bug" is that clicking on the now visible tab *Completions* in the
> tab-line will show the *Completions* buffer, but there will be no tab-line
> anymore there to click to get back to the other buffers.
>
> Is it a bug of a tab-line or a feature?

It's a feature.  You can customize 'tab-line-exclude-modes'
and remove 'completion-list-mode' from its default value.

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Claudio Grondi]

I have now in my .emacs:

(custom-set-variables
   '(tab-line-exclude-modes nil)

but this haven't changed the behavior. The tab-line is still 
disappearing when viewing *xxx* buffers.

What am I still missing?


On 4/3/23 08:30, Juri Linkov wrote:
>> The "bug" is that clicking on the now visible tab *Completions* in the
>> tab-line will show the *Completions* buffer, but there will be no tab-line
>> anymore there to click to get back to the other buffers.
>>
>> Is it a bug of a tab-line or a feature?
> It's a feature.  You can customize 'tab-line-exclude-modes'
> and remove 'completion-list-mode' from its default value.

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Juri Linkov]

> I have now in my .emacs:
>
> (custom-set-variables
>   '(tab-line-exclude-modes nil)
>
> but this haven't changed the behavior. The tab-line is still disappearing
> when viewing *xxx* buffers.
>
> What am I still missing?

Probably this is because you enabled buffer-local 'tab-line-mode'
instead of 'global-tab-line-mode'.

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Claudio Grondi]

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


On 4/3/23 18:11, Juri Linkov wrote:
>> I have now in my .emacs:
>>
>> (custom-set-variables
>>    '(tab-line-exclude-modes nil)
>>
>> but this haven't changed the behavior. The tab-line is still disappearing
>> when viewing *xxx* buffers.
>>
>> What am I still missing?
> Probably this is because you enabled buffer-local 'tab-line-mode'
> instead of 'global-tab-line-mode'.

OK, I have put

(setq global-tab-line-mode t)

into my initialization file. But this didn't help either.

Do I understand it right that the tab-line-mode is NOT as I am expecting 
and maybe erroneously assuming a property/switch of a window, but a 
property/switch of a single buffer viewed in the window??? Or is it just 
only a symbol value which might, but not must be respected while running 
rendering of the graphics of the area between the toolbar and the 
minibuffer?

And if in the buffer the local tab-line-mode is for some weird reason 
switched-off the window showing that buffer does not show the tab-line???

Coupled with not taking seriously the state of the switch shown in the 
Options -> Show/Hide -> Window Tab Line (it's just a switch showing some 
not valid switch state, like a label on a tab-bar just showing some 
non-existing buffer name as label is also considered OK and not a bug), 
this above will explain all the weird behavior I experience.

What I am wondering about is, how does it come that I am bumping in all 
these problems? Because I am trying to understand how it works and 
testing all the possible edge cases? Making around 150 windows shown in 
a "root window" sometimes called "frame" sometimes "window 
configuration" and experiencing then weird behavior on reload from the 
.desktop file, where most of the tab-lines are lost and the window sizes 
are not as before exiting and saving the .desktop file? Without being 
able to discover any clear rule or some reproducible pattern in what I 
can observe?

It seems to be not possible to create a perfectly adjusted pattern of 
100 and more windows and then store it to a .desktop file being sure 
they will be recreated on next start as seen on the screen. OK - somehow 
is it maybe misusing of an text editor for creating patterns of 
rectangles, but if the underlying programming would work the right way 
it should be possible to use it also for the unique experience of typing 
at 100 and more places on the screen at the same time.

Attached a desktop file with many, many windows which were originally 
perfectly distributed giving a nice regular pattern. The work of 
positioning the windows was not worth the effort - the restored pattern 
is all, but not as created.


[-- Attachment #2: emacs.desktop.tar.bz2 --]
[-- Type: application/x-bzip, Size: 3816 bytes --]

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Juri Linkov]

>> Probably this is because you enabled buffer-local 'tab-line-mode'
>> instead of 'global-tab-line-mode'.
>
> OK, I have put
>
> (setq global-tab-line-mode t)
>
> into my initialization file. But this didn't help either.

Actually, in your initialization file it should be used
as a command: (global-tab-line-mode 1) or you can customize it
as a variable: (custom-set-variables '(global-tab-line-mode t))

> What I am wondering about is, how does it come that I am bumping in all
> these problems?

To avoid all these problems, I recommend you to read the manual
that explains the details.  Here are some relevant nodes:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Tab-Line.html
https://www.gnu.org/software/emacs/manual/html_node/emacs/Tab-Bars.html

bug#62575: 29.0.60; Tabs are not showing the right names of the buffers

[Juri Linkov]

close 62575 30.0.50
thanks

>>> Probably this is because you enabled buffer-local 'tab-line-mode'
>>> instead of 'global-tab-line-mode'.
>>
>> OK, I have put
>>
>> (setq global-tab-line-mode t)
>>
>> into my initialization file. But this didn't help either.
>
> Actually, in your initialization file it should be used
> as a command: (global-tab-line-mode 1) or you can customize it
> as a variable: (custom-set-variables '(global-tab-line-mode t))

Some problems from this request were already addressed, so it's time to
close it.  You can open a new if you have more ideas.