Re: [PATCH] Enable persistent naming for tabs

[Juri Linkov]

>>> For emacs usage, I'd suggest that 1 tab == the baseline --- 0 tabs
>>> mostly is equivalent to tab-bar not existing.
>>
>> This seems the right thing to do.  So closing the last tab
>> will disable tab-bar-mode.
>
> I personally am not fond of this behavior. That is not what I would
> expect the button to do, personally. If I was a new user that didn't
> know any better, that behavior would be very surprising and confusing, I
> think. Plus that makes it a little too easy for a fiddly laptop trackpad
> or some other not-super-accurate pointing device to drift over the
> 'close' button when I was actually trying to aim for the 'new tab'
> button.
>
> Honestly, it really seems like we have at least 3 different alternatives
> that sound like they could be The Right Thing:
>
> A) Do nothing, as we currently do, but implement a fix to prevent from
> trashing the explicit-name property of the tab (I suggest signalling
> user-error and bailing out early, as previously mentioned).

Both 'C-x 0' and 'C-x 5 0' signal user-error on closing the last
window/frame with:

  Attempt to delete minibuffer or sole ordinary window
  Attempt to delete the sole visible or iconified frame

so the same would make sense for tabs as well.

> B) Close the whole frame, as one usually expects out of a web browser
> these days.

Sometimes this behavior is annoying when the last tab is closed
accidentally.  Some browsers allow to disable such auto-closing,
so after accidentally closing the last tab it's possible to undo
closing (in Emacs tab closing undo is implemented now as well).

> C) Disable tab-bar-mode

While implementing tab closing undo, I added disabling tab-bar-mode
because it was easier to just add this line:

               (or (<= (length tabs) 1) ; closed the last tab

But please remove this from the default behavior because
I noticed that it disables tab-bar on all frames, whereas
it would make more sense to disable tab-bar only on the
selected frame.

> My personal opinion at this point is that we should offer all 3 as
> customize options, as well as provide a 4th option that is 'provide a
> function that takes the tab as an argument, and handle it however you
> want to handle it'. Something like:

I agree.

> #+BEGIN_SRC elisp
> (defcustom tab-bar-close-tab-choice nil
>   "Defines what to show in a new tab.
> If nil, do not close the tab.
> If close-frame, close the entire containing frame, as a web
> browser would do.
> If disable-tab-bar, turn off tab-bar-mode so that tabs no longer
> show in the frame.
> If the value is a function, call that function with the tab to be
> closed as the argument."
>   :type '(choice (const    :tag "Do nothing" nil)
>                  (const    :tag "Close frame" 'close-frame)
>                  (const    :tag "Disable tab-bar-mode" 'disable-tab-bar)
>                  (function :tag "Function"))
>   :group 'tab-bar
>   :version "27.1")
> #+END_SRC
>
> And then we can go from there. If that sounds like a workable solution,
> then I'll provide a patch in the next few days that implements the
> defcustom and all the appropriate behavior.

Please implement this defcustom (with the nil default value) because
we need to improve the current logic of closing the last tab (maybe
the name should be tab-bar-close-last-tab-choice to suggest that
it applies to closing only the last tab, not to every tab close).