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