From: Juri Linkov <juri@linkov.net>
To: Robert Cochran <robert-emacs@cochranmail.com>
Cc: emacs-devel@gnu.org, "T.V Raman" <raman@google.com>
Subject: Re: [PATCH] Enable persistent naming for tabs
Date: Wed, 23 Oct 2019 23:41:18 +0300 [thread overview]
Message-ID: <87ftjjfb4h.fsf@mail.linkov.net> (raw)
In-Reply-To: <87eez3xwi1.fsf@cochranmail.com> (Robert Cochran's message of "Wed, 23 Oct 2019 09:22:14 -0700")
>>> 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).
next prev parent reply other threads:[~2019-10-23 20:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 1:03 [PATCH] Enable persistent naming for tabs Robert Cochran
2019-10-10 21:43 ` Juri Linkov
[not found] ` <87ftjz6v4d.fsf@cochranmail.com>
2019-10-13 19:53 ` Juri Linkov
2019-10-15 21:45 ` Juri Linkov
2019-10-20 16:17 ` Juri Linkov
2019-10-20 23:54 ` T.V Raman
2019-10-21 21:34 ` Juri Linkov
2019-10-23 16:22 ` Robert Cochran
2019-10-23 20:41 ` Juri Linkov [this message]
2019-10-25 15:47 ` Robert Cochran
2019-10-25 16:01 ` Robert Cochran
2019-11-03 22:08 ` Robert Cochran
2019-11-03 22:37 ` Juri Linkov
2019-10-26 21:46 ` Juri Linkov
2019-10-30 18:35 ` Robert Cochran
2019-10-30 21:52 ` Juri Linkov
2019-10-30 23:05 ` Juri Linkov
2019-10-31 1:50 ` Robert Cochran
2019-10-31 21:17 ` Juri Linkov
2019-10-27 23:10 ` Juri Linkov
-- strict thread matches above, loose matches on Subject: below --
2019-10-08 22:26 Robert Cochran
2019-10-09 16:02 ` Eli Zaretskii
2019-10-09 22:58 ` Juri Linkov
2019-10-23 20:53 ` Kalman Reti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ftjjfb4h.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=emacs-devel@gnu.org \
--cc=raman@google.com \
--cc=robert-emacs@cochranmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).