Re: [BUG] Tab commands selecting by name

[Ingo Lohmar <ingo.lohmar@posteo.net>]

On Sun, Oct 13 2019 01:05 (+0300), Juri Linkov wrote:

>> 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 get 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 use this replacement for `tab-bar-tabs' instead:
>>
>> (defun my/tab-bar-updated ()
>>   (let ((tabs (tab-bar-tabs)))
>>     (mapcar
>>      (lambda (tab)
>>        (if (eq (car tab) 'current-tab)
>>            (tab-bar--current-tab)       ;or (tab-bar--tab) for full info
>>          tab))
>>      tabs)))
>>
>> Obviously, this could be merged with other functions to a more elegant
>> form, maybe even into tab-tar-tabs itself.
>
> I guess you're overriding it using tab-bar-tabs-function?

Yes.