[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BUG] Tab commands selecting by name
From: |
Ingo Lohmar |
Subject: |
Re: [BUG] Tab commands selecting by name |
Date: |
Sun, 13 Oct 2019 07:46:12 +0200 |
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.