Re: [BUG] Tab commands selecting by name

[Juri Linkov]

>>> Currently, some interactive functions offer tabs by name
>>> (tab-bar-switch-to-tab and tab-bar-close-tab-by-name, at least): They
>>> directly use `(tab-bar-tabs)' to get the names to choose from.  However,
>>> the current tab's name in the return value is *not* up-to-date if it has
>>> changed since the last time the tab has been visited (eg, showing a
>>> different buffer in one window when using the -all-windows name
>>> function).
>>
>> Does this problem really exists?  The current tab name gets updated
>> in tab-bar-make-keymap-1 very often, it's called by the display engine
>> on every window configuration change.  So when you type
>> M-x tab-bar-close-tab-by-name, the current tab name is already
>> up-to-date.
>>
>> Please provide a test case that reproduces this problem.
>
> I forgot to mention a crucial ingredient, because it's so natural for
> me: I have NOT turned on tab-bar-mode --- I do not want to see tabs,
> just to use persistent window configs.  In that case, I think, the
> keymap you are talking about is not in play.  So I am just using the
> commands themselves, via actual keys.
>
> But I don't really understand why the current-tab update is best placed
> in that helper function, anyway, presumably to save some updating?

I tried to avoid using window-configuration-change-hook
and indeed the current implementation uses no hooks at all.

But it seems now we still need to use window-configuration-change-hook
to update the current tab name on every window configuration change.
Or at least to use this hook when tab-bar-mode is disabled.

Or there is an alternative - to update the current tab name
explicitly in every command that uses tab names, and even in
their interactive spec that reads a tab name.