Re: [PATCH] Enable persistent naming for tabs

[Juri Linkov]

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

Manipulation of windows and buffers is possible in a function customized
for tab-bar-new-tab-choice.  Such function could return (current-buffer)
or any other non-buffer value to avoid switch-to-buffer.

> and tab names. The function doesn't have lexical access to the tab
> variable in any way, either.

Modification of tab names is not possible with tab-bar-new-tab-choice indeed.
OTOH, naming the tab according to buffers in it is also possible by
customizing tab-bar-tab-name-function.  However, I'm not sure about
prompting for a new name in it.  So maybe a new hook is needed after all.

>>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'.

I like 'hook' more too because it is shorter than 'functions',
but I'm not sure about the current naming convention such as
(info "(elisp) Tips for Defining")

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

Right, let's add all additional information.

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

Protected tabs is a useful feature in some web browsers/addons.
Also there are locked tabs that are more like dedicated windows
e.g. https://www.tabmixplus.org/support/viewpage.php?t=3&p=frozen_tabs

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

No by default, of course.  Only as an option.