Re: [PATCH] Enable persistent naming for tabs

[Robert Cochran]

Juri Linkov <address@hidden> writes:

>>> Another is if I open a new tab, and I want to be prompted to name the
>>> tab automatically depending on the buffers that exist at the time of
>>> creation - I have a tendency to segregate all of my Magit buffers for
>>> a repository into a single tab, and I usually rename the tab so that
>>> no matter what Magit sub-buffer I'm on, the tab still has a consistent
>>> name. I can see myself doing similar for other 'task-oriented' sets of
>>> windows and buffers such as gdb, mpd, etc.
>>
>> This looks like calling after the tab is created, so maybe a name like
>>
>>   tab-bar-post-new-tab-functions (tab)
>
> I just realized we already have tab-bar-new-tab-choice.
> Does it serve the same purpose?

I don't think so. The function is supposed to return a buffer that is
used as the starting buffer for the tab. That precludes doing any sort
of manipulation of windows, buffers, and tab names. The function doesn't
have lexical access to the tab variable in any way, either.

[ From the other message ]

>> I believe it better to be a hook personally, though admittedly that kind
>> of depends on how exactly you want to use the functionality. A hook
>> allows for several interested parties to be able to act on a tab
>> create/close instead of just one. This allows better for dynamically
>> adding or removing situationally dependent behavior. For example, maybe
>> I want to kill some/all of the buffers in the tab when I close it, but
>> only under certain circumstances, like if it's a tab containing non-file
>> 'work' buffers like those of Magit or mpd.
>
>Maybe we need to add the prefix 'pre-' to indicate that the hook
>is called before the command is executed, with a name e.g.:
>
>  tab-bar-pre-close-tab-functions (tab)

That name sounds fine by me, perhaps though 'hook' instead of
'functions'. And this is kind of going off into the weeds for a little
bit, but maybe we can have an additional argument that indicates whether
or not it's the last tab? I know that seems to overlap a little bit with
last-tab-choice, but my goal is to try and work in as much mechanism as
possible so that the user has plenty of freedom to have things behave
exactly as they want. Seems to be in the spirit of Emacs. :)

We could also use the return value to see if we should actually close
the tab or not (ie if *any* of the tabs return a particular value, nil
for the sake of argument, then the tab closing function will bail out
early and not close the tab)? I could see this second thing being useful
for programmatically 'protecting' a tab.

>This might require an additional utility function to get all buffers
>from the tab (it could collect buffers by traversing readable window-state),
>with a name:
>
>  tab-bar-tab-buffers (tab)
>
>Such function is also needed for checking if a buffer exists in a tab
>to prevent killing a buffer in the current tab with C-x k
>when such buffer is still shown in some other tab.

Having such a function could prove useful, yes. I'm not sure we should
prevent killing a buffer if it's visible in another tab though. There's
nothing stopping you from killing a buffer visible in another frame or
another window, at least by default.

>> Another is if I open a new tab, and I want to be prompted to name the
>> tab automatically depending on the buffers that exist at the time of
>> creation - I have a tendency to segregate all of my Magit buffers for
>> a repository into a single tab, and I usually rename the tab so that
>> no matter what Magit sub-buffer I'm on, the tab still has a consistent
>> name. I can see myself doing similar for other 'task-oriented' sets of
>> windows and buffers such as gdb, mpd, etc.
>
>This looks like calling after the tab is created, so maybe a name like
>
>  tab-bar-post-new-tab-functions (tab)

This name also sounds fine, with the same comment about possibly naming
with 'hook' instead of 'functions'.

Thanks,
-- 
~Robert Cochran

GPG Fingerprint - BD0C 5F8B 381C 64F0 F3CE  E7B9 EC9A 872C 41B2 77C2