[PATCH] New tab-bar-detach-tab command

[PATCH] New tab-bar-detach-tab command

[Adam Porter]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

Hi Juri, et al,

I found myself wanting to move a tab-bar tab to a new frame displaying
only that tab (like a web browser's "detach tab" command), and I
couldn't find a command to do that, so I wrote this simple one.  It
seems to work and ought to be useful, I think.

It might be worth binding it to something like "C-x t D" as well,
assuming the command is worth merging.  :)

Thanks,
Adam

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: New tab-bar-detach-tab command --]
[-- Type: text/x-diff, Size: 1067 bytes --]

From 0ffce5391c70445c8d311eb205cd566cc5f7b174 Mon Sep 17 00:00:00 2001
From: Adam Porter <adam@alphapapa.net>
Date: Tue, 28 Sep 2021 14:03:01 -0500
Subject: [PATCH] * lisp/tab-bar.el: (tab-bar-detach-tab) New command

(tab-bar-detach-tab): New command.
---
 lisp/tab-bar.el | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index abf0e81..d6a5edc 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1201,6 +1201,16 @@ tab-bar-move-tab-to-frame
       (tab-bar-tabs-set to-tabs to-frame)
       (force-mode-line-update t))))
 
+(defun tab-bar-detach-tab (tab)
+  "Detach TAB to a new frame.
+Interactively, detach current tab."
+  (interactive (list (tab-bar--current-tab-find)))
+  (let* ((tab-name (alist-get 'name (tab-bar--current-tab-find)))
+         (new-frame (make-frame `((name . ,tab-name)))))
+    (tab-bar-move-tab-to-frame nil nil nil new-frame nil)
+    (with-selected-frame new-frame
+      (tab-close 1))))
+
 \f
 (defcustom tab-bar-new-tab-to 'right
   "Defines where to create a new tab.
-- 
2.7.4

Re: [PATCH] New tab-bar-detach-tab command

[Matt Beshara]

Hi Adam (and others),
I missed this functionality from web browsers as well, but the 
implementation you posted doesn’t work on my setup.  The new tab 
it creates in a new frame only contains one of the multiple 
windows I had open in the original tab, and it gives me the 
message “tab-close: Attempt to delete the sole tab in a frame”. 
Below I’ve pasted another implementation I’ve been using for a 
little while which I get better results with.

#+BEGIN_SRC emacs-lisp
(defun tab-bar-move-tab-to-new-frame ()
  (interactive)
  (let* ((from-frame (selected-frame))
         (from-tabs (funcall tab-bar-tabs-function from-frame))
         (from-index (1+ (tab-bar--current-tab-index from-tabs)))
         (new-frame (make-frame)))
    (tab-bar-move-tab-to-frame nil from-frame from-index new-frame 
    1)
    (select-frame new-frame)
    (tab-bar-close-tab)))
#+END_SRC

I hope you find this useful,
Matt


Adam Porter <adam@alphapapa.net> writes:

> Hi Juri, et al,
>
> I found myself wanting to move a tab-bar tab to a new frame 
> displaying
> only that tab (like a web browser's "detach tab" command), and I
> couldn't find a command to do that, so I wrote this simple one. 
> It
> seems to work and ought to be useful, I think.
>
> It might be worth binding it to something like "C-x t D" as 
> well,
> assuming the command is worth merging.  :)
>
> Thanks,
> Adam
>
> [2. New tab-bar-detach-tab command --- text/x-diff; 
> 0001-lisp-tab-bar.el-tab-bar-detach-tab-New-command.patch]...

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

> I found myself wanting to move a tab-bar tab to a new frame displaying
> only that tab (like a web browser's "detach tab" command), and I
> couldn't find a command to do that, so I wrote this simple one.  It
> seems to work and ought to be useful, I think.

Thanks.  The command 'tab-bar-move-tab-to-frame' was intended
to do exactly this.  If it doesn't, then it would be better
to fix it, for example, by improving its 'interactive' spec, etc.
Then you can add an alias 'tab-bar-detach-tab' to it.

> It might be worth binding it to something like "C-x t D" as well,
> assuming the command is worth merging.  :)

Currently I'm developing a command that will detach a window
to a new tab, i.e. it will delete the selected window
from the current tab after moving it to the new tab.
And I'd like to add a keybinding to it with the same mnemonics "D" :-)

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

> I missed this functionality from web browsers as well, but the
> implementation you posted doesn’t work on my setup.  The new tab
> it creates in a new frame only contains one of the multiple
> windows I had open in the original tab, and it gives me the
> message “tab-close: Attempt to delete the sole tab in a frame”.
> Below I’ve pasted another implementation I’ve been using for a
> little while which I get better results with.

Thanks, this will be fixed in tab-bar-move-tab-to-frame
to delete the tab in the correct frame.

Re: [PATCH] New tab-bar-detach-tab command

[Adam Porter]

Matt Beshara <m@mfa.pw> writes:

> Hi Adam (and others),
> I missed this functionality from web browsers as well, but the 
> implementation you posted doesn’t work on my setup.  The new tab 
> it creates in a new frame only contains one of the multiple 
> windows I had open in the original tab, and it gives me the 
> message “tab-close: Attempt to delete the sole tab in a frame”. 
> Below I’ve pasted another implementation I’ve been using for a 
> little while which I get better results with.
>
> #+BEGIN_SRC emacs-lisp
> (defun tab-bar-move-tab-to-new-frame ()
>   (interactive)
>   (let* ((from-frame (selected-frame))
>          (from-tabs (funcall tab-bar-tabs-function from-frame))
>          (from-index (1+ (tab-bar--current-tab-index from-tabs)))
>          (new-frame (make-frame)))
>     (tab-bar-move-tab-to-frame nil from-frame from-index new-frame 
>     1)
>     (select-frame new-frame)
>     (tab-bar-close-tab)))
> #+END_SRC

Hi Matt,

Thanks, I should have noticed that.  I've updated my patch, which I'll
post in reply to Juri's message.

Re: [PATCH] New tab-bar-detach-tab command

[Adam Porter]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

Hi Juri,

Juri Linkov <juri@linkov.net> writes:

> Thanks.  The command 'tab-bar-move-tab-to-frame' was intended
> to do exactly this.  If it doesn't, then it would be better
> to fix it, for example, by improving its 'interactive' spec, etc.
> Then you can add an alias 'tab-bar-detach-tab' to it.

Looking at that command, I'm not sure how to change its interactive spec
to move a tab to a new frame without changing the command's documented
behavior.  But using it to do the work of moving a tab to a new frame
created by another command is straightforward and easy for me to
understand.  :)

I've attached a new patch for your consideration.  It seems to work
correctly (correcting the issue Matt noted), and it also adds the new
command to the tab bar context menu.  If you'd still prefer to change
'tab-bar-move-tab-to-frame' to accomodate this functionality, I'm not
sure what you have in mind.

>> It might be worth binding it to something like "C-x t D" as well,
>> assuming the command is worth merging.  :)
>
> Currently I'm developing a command that will detach a window
> to a new tab, i.e. it will delete the selected window
> from the current tab after moving it to the new tab.
> And I'd like to add a keybinding to it with the same mnemonics "D" :-)

Hm, what if the new window-detaching command were on "C-x t d", and the
new tab-detaching command were on "C-x t D"?  Of course, "C-x t d" is
currently bound to 'dired-other-tab', but it seems like that should be
covered by 'other-tab-prefix', i.e. "C-x t t C-x d".

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: New patch --]
[-- Type: text/x-diff, Size: 1831 bytes --]

From 9deb82def15669d7cd520ec33caf345af0e4ce79 Mon Sep 17 00:00:00 2001
From: Adam Porter <adam@alphapapa.net>
Date: Tue, 28 Sep 2021 14:03:01 -0500
Subject: [PATCH] * lisp/tab-bar.el: (tab-bar-detach-tab) New command

(tab-bar-detach-tab): New command.
(tab-bar-mouse-context-menu): Add menu entry.

With thanks to Matt Beshara <m@mfa.pw> for his feedback.
---
 lisp/tab-bar.el | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index abf0e81..44b89c8 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -307,6 +307,11 @@ tab-bar-mouse-context-menu
                       :help "Undo closing the tab"))))
 
      (t
+      (define-key-after menu [detach-tab]
+        `(menu-item "Detach" (lambda () (interactive)
+                               (tab-bar-detach-tab
+                                ,tab-number))
+                    :help "Detach the tab to new frame"))
       (define-key-after menu [duplicate-tab]
         `(menu-item "Duplicate" (lambda () (interactive)
                                   (tab-bar-duplicate-tab
@@ -1201,6 +1206,17 @@ tab-bar-move-tab-to-frame
       (tab-bar-tabs-set to-tabs to-frame)
       (force-mode-line-update t))))
 
+(defun tab-bar-detach-tab (&optional from-number)
+  "Detach tab number FROM-NUMBER to a new frame.
+Interactively or without argument, detach current tab."
+  (interactive (list (tab-bar--current-tab-index)))
+  (let* ((tab (nth (or from-number 1) (funcall tab-bar-tabs-function)))
+         (tab-name (alist-get 'name tab))
+         (new-frame (make-frame `((name . ,tab-name)))))
+    (tab-bar-move-tab-to-frame nil nil from-number new-frame nil)
+    (with-selected-frame new-frame
+      (tab-bar-close-tab))))
+
 \f
 (defcustom tab-bar-new-tab-to 'right
   "Defines where to create a new tab.
-- 
2.7.4

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

> Looking at that command, I'm not sure how to change its interactive spec
> to move a tab to a new frame without changing the command's documented
> behavior.  But using it to do the work of moving a tab to a new frame
> created by another command is straightforward and easy for me to
> understand.  :)

You are right, the existing command can't be changed to make a new frame.

> I've attached a new patch for your consideration.  It seems to work
> correctly (correcting the issue Matt noted), and it also adds the new
> command to the tab bar context menu.  If you'd still prefer to change
> 'tab-bar-move-tab-to-frame' to accomodate this functionality, I'm not
> sure what you have in mind.

I confirm that the issue Matt noted is corrected by your patch.
So I pushed your patch (with a small correction of 0/1 indexing).
Thanks to you and to Matt.

Also I fixed another issue noted by Matt:
“tab-close: Attempt to delete the sole tab in a frame”.
This is fixed now to delete the whole frame when its last tab
was moved to another frame.

>>> It might be worth binding it to something like "C-x t D" as well,
>>> assuming the command is worth merging.  :)
>>
>> Currently I'm developing a command that will detach a window
>> to a new tab, i.e. it will delete the selected window
>> from the current tab after moving it to the new tab.
>> And I'd like to add a keybinding to it with the same mnemonics "D" :-)
>
> Hm, what if the new window-detaching command were on "C-x t d", and the
> new tab-detaching command were on "C-x t D"?  Of course, "C-x t d" is
> currently bound to 'dired-other-tab', but it seems like that should be
> covered by 'other-tab-prefix', i.e. "C-x t t C-x d".

'C-x t d' was modeled after 'C-x 5 d' (dired-other-frame),
and since I use 'C-x t d' all the time, I expect that other users
might be accustomed to it as well.  We need to find a new key
or better a key prefix to accommodate more future keys.

Re: [PATCH] New tab-bar-detach-tab command

[Adam Porter]

Juri Linkov <juri@linkov.net> writes:

> I confirm that the issue Matt noted is corrected by your patch.
> So I pushed your patch (with a small correction of 0/1 indexing).
> Thanks to you and to Matt.

Thanks.

> Also I fixed another issue noted by Matt:
> “tab-close: Attempt to delete the sole tab in a frame”.
> This is fixed now to delete the whole frame when its last tab
> was moved to another frame.

Great!

>>>> It might be worth binding it to something like "C-x t D" as well,
>>>> assuming the command is worth merging.  :)
>>>
>>> Currently I'm developing a command that will detach a window
>>> to a new tab, i.e. it will delete the selected window
>>> from the current tab after moving it to the new tab.
>>> And I'd like to add a keybinding to it with the same mnemonics "D" :-)
>>
>> Hm, what if the new window-detaching command were on "C-x t d", and the
>> new tab-detaching command were on "C-x t D"?  Of course, "C-x t d" is
>> currently bound to 'dired-other-tab', but it seems like that should be
>> covered by 'other-tab-prefix', i.e. "C-x t t C-x d".
>
> 'C-x t d' was modeled after 'C-x 5 d' (dired-other-frame),
> and since I use 'C-x t d' all the time, I expect that other users
> might be accustomed to it as well.  We need to find a new key
> or better a key prefix to accommodate more future keys.

Makes sense.  Thanks.

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

>> Also I fixed another issue noted by Matt:
>> “tab-close: Attempt to delete the sole tab in a frame”.
>> This is fixed now to delete the whole frame when its last tab
>> was moved to another frame.

Another small fix was needed to handle the case when the window manager
immediately selects the new frame created by `make-frame'.

>>>> Currently I'm developing a command that will detach a window
>>>> to a new tab, i.e. it will delete the selected window
>>>> from the current tab after moving it to the new tab.
>>>> And I'd like to add a keybinding to it with the same mnemonics "D" :-)
>>>
>>> Hm, what if the new window-detaching command were on "C-x t d", and the
>>> new tab-detaching command were on "C-x t D"?  Of course, "C-x t d" is
>>> currently bound to 'dired-other-tab', but it seems like that should be
>>> covered by 'other-tab-prefix', i.e. "C-x t t C-x d".
>>
>> 'C-x t d' was modeled after 'C-x 5 d' (dired-other-frame),
>> and since I use 'C-x t d' all the time, I expect that other users
>> might be accustomed to it as well.  We need to find a new key
>> or better a key prefix to accommodate more future keys.
>
> Makes sense.  Thanks.

The new window-detaching command is implemented now, but still
no idea where to bind these commands: tab-detaching and window-detaching.

Re: [PATCH] New tab-bar-detach-tab command

[Adam Porter]

Hi Juri,

On Sun, Oct 3, 2021 at 12:21 PM Juri Linkov <juri@linkov.net> wrote:

> Another small fix was needed to handle the case when the window manager
> immediately selects the new frame created by `make-frame'.

Thanks.

> The new window-detaching command is implemented now, but still
> no idea where to bind these commands: tab-detaching and window-detaching.

Other than "C-x t d", which we already discussed, the best idea I can
think of is something like "C-x t -", the minus being somewhat
mnemonic.

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

>> The new window-detaching command is implemented now, but still
>> no idea where to bind these commands: tab-detaching and window-detaching.
>
> Other than "C-x t d", which we already discussed, the best idea I can
> think of is something like "C-x t -", the minus being somewhat
> mnemonic.

Indeed, the key doesn't need to be the first letter of the command name.
For example, since 'C-x t d' was already bound to 'dired-other-tab',
for 'tab-duplicate' I added 'C-x t n' with the mnemonic of "new".

But a month ago a new command 'clone-frame' was added with the
keybinding 'C-x 5 c'.  So now we have two similar commands with
different keys: 'c' - clone frame, and 'n' - duplicate tab.

Or maybe these commands are quite different?  I tried 'clone-frame',
but it neither clones nor duplicates the frame - it creates
a completely new window configuration on the new frame.

Re: [PATCH] New tab-bar-detach-tab command

[Adam Porter]

Juri Linkov <juri@linkov.net> writes:

>>> The new window-detaching command is implemented now, but still
>>> no idea where to bind these commands: tab-detaching and window-detaching.
>>
>> Other than "C-x t d", which we already discussed, the best idea I can
>> think of is something like "C-x t -", the minus being somewhat
>> mnemonic.
>
> Indeed, the key doesn't need to be the first letter of the command name.
> For example, since 'C-x t d' was already bound to 'dired-other-tab',
> for 'tab-duplicate' I added 'C-x t n' with the mnemonic of "new".
>
> But a month ago a new command 'clone-frame' was added with the
> keybinding 'C-x 5 c'.  So now we have two similar commands with
> different keys: 'c' - clone frame, and 'n' - duplicate tab.
>
> Or maybe these commands are quite different?  I tried 'clone-frame',
> but it neither clones nor duplicates the frame - it creates
> a completely new window configuration on the new frame.

I suppose a `tab-clone' command would be more concise than
`tab-duplicate', and it would also fit with other commands like
`clone-buffer' (I don't see any other commands in my Emacs with
"duplicate" in the name).  Then the binding could be "C-x t c".

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

>> Indeed, the key doesn't need to be the first letter of the command name.
>> For example, since 'C-x t d' was already bound to 'dired-other-tab',
>> for 'tab-duplicate' I added 'C-x t n' with the mnemonic of "new".
>>
>> But a month ago a new command 'clone-frame' was added with the
>> keybinding 'C-x 5 c'.  So now we have two similar commands with
>> different keys: 'c' - clone frame, and 'n' - duplicate tab.
>>
>> Or maybe these commands are quite different?  I tried 'clone-frame',
>> but it neither clones nor duplicates the frame - it creates
>> a completely new window configuration on the new frame.
>
> I suppose a `tab-clone' command would be more concise than
> `tab-duplicate', and it would also fit with other commands like
> `clone-buffer' (I don't see any other commands in my Emacs with
> "duplicate" in the name).  Then the binding could be "C-x t c".

The command was named "duplicate" because web browsers
provide the menu item "Duplicate tab".

Also since 'clone-frame' doesn't duplicate the frame,
we could add a new command 'duplicate-frame' as well.

Re: [PATCH] New tab-bar-detach-tab command

[Adam Porter]

Juri Linkov <juri@linkov.net> writes:

>>> Indeed, the key doesn't need to be the first letter of the command name.
>>> For example, since 'C-x t d' was already bound to 'dired-other-tab',
>>> for 'tab-duplicate' I added 'C-x t n' with the mnemonic of "new".
>>>
>>> But a month ago a new command 'clone-frame' was added with the
>>> keybinding 'C-x 5 c'.  So now we have two similar commands with
>>> different keys: 'c' - clone frame, and 'n' - duplicate tab.
>>>
>>> Or maybe these commands are quite different?  I tried 'clone-frame',
>>> but it neither clones nor duplicates the frame - it creates
>>> a completely new window configuration on the new frame.
>>
>> I suppose a `tab-clone' command would be more concise than
>> `tab-duplicate', and it would also fit with other commands like
>> `clone-buffer' (I don't see any other commands in my Emacs with
>> "duplicate" in the name).  Then the binding could be "C-x t c".
>
> The command was named "duplicate" because web browsers
> provide the menu item "Duplicate tab".

Of course, that makes sense.  But since "clone" seems to already be a
term used in Emacs for this sort of thing, maybe we should consider
using it, instead.  For example, `clone-buffer' and `clone-process' both
"Create a twin copy of...".  That the new `clone-frame' command only
"Make[s] a new frame with the same parameters as FRAME" and doesn't
include its window configuration seems like an anomaly (maybe that
should be changed, too, for consistency?).

> Also since 'clone-frame' doesn't duplicate the frame,
> we could add a new command 'duplicate-frame' as well.

Maybe so, but I wonder if it would be better to consistently use "clone"
to mean "Create a twin copy of...", and use "duplicate" to mean
something like what the `clone-frame' command currently does,
i.e. create a copy that shares some attributes but not all.  In that
case, the current `clone-frame' command could be renamed to
`duplicate-frame', and `duplicate-tab' could be renamed to `clone-tab'.

Maybe these details are too subtle to matter, but on the other hand, it
would seem more consistent with existing Emacs jargon if if worked that
way.

RE: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Drew Adams]

> I tried 'clone-frame', but it neither clones nor
> duplicates the frame - it creates a completely
> new window configuration on the new frame.

It does clone the frame.  Depends what one means by
"the frame".

A window config in a frame isn't part of the state
(or definition) of the frame itself.  But sure,
it's debatable what should be expected from a
`clone-frame' command.

I proposed this command for Emacs in bug #34715 a
couple years ago.  It was subsequently discussed in
the emacs-devel thread about bug #34716, in which
you participated, (so you shouldn't be surprised at
what it does).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34715

https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00089.html

Both kinds of "cloning" a frame could be useful:
(1) the `clone-frame' kind, which creates a frame
with the same frame parameters, and (2) what you
suggest, which does that AND reproduces the window
config of the "cloned" frame in its "clone".

I added #1 (`clone-frame') to my code a few years
ago.  I use it often, and I bind it to `C-x 5 2'.

When I want only `make-frame-command' (which has
the vanilla Emacs binding `C-x 5 2'), I just use
a prefix arg with `C-x 5 2' - that's what my
`clone-frame' does.  But I pretty much never want
just the `make-frame-command' behavior.

I suggested that vanilla Emacs give `C-x 5 2' to
`clone-frame', but that didn't happen.  Instead,
yet another default key binding was added/wasted.

I don't know the signature of the `clone-frame'
that was added to Emacs, but perhaps it could use
a prefix arg to provide what you're proposing:
clone the frame (same frame parameters) AND clone
the window config of the frame in the new frame.

RE: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Drew Adams]

> Also since 'clone-frame' doesn't duplicate the frame,
> we could add a new command 'duplicate-frame' as well.

See my other mail today, which responds to this
claim of yours.

Let's not needlessly add commands (and especially
default key bindings!).  Consider adding what you
call `duplicate-frame' behavior via a prefix arg
to `clone-frame'.

RE: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Drew Adams]

>  That the new `clone-frame' command only "Make[s] a
> new frame with the same parameters as FRAME" and doesn't
> include its window configuration seems like an anomaly

It's not an anomaly.  It's by design, as being the
most useful behavior (IMO).

But nothing precludes adding duplication of the
frame's window configuration to `clone-frame'
by way of its prefix arg.

> > Also since 'clone-frame' doesn't duplicate the frame,
> > we could add a new command 'duplicate-frame' as well.
> 
> Maybe so, but I wonder if it would be better to consistently use
> "clone" to mean "Create a twin copy of...", and use "duplicate" to mean
> something like what the `clone-frame' command currently does,
> i.e. create a copy that shares some attributes but not all.

A window config is not a frame attribute.  But
sure, the "clone" of a thing is debatable.

IMO, we shouldn't needlessly add commands, and
especially default key bindings - and what was
suggested there is needless, IMO.

Just add the requested behavior to `clone-frame'
by way of its prefix arg.  With no prefix arg
you clone the frame (new frame with same params).
With a prefix arg you clone it and reproduce its
window config.

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

> (I don't see any other commands in my Emacs with "duplicate" in the name).

Indeed, there are not many commands with "duplicate" in their names.
One example:

  (defun picture-duplicate-line ()
    "Insert a duplicate of the current line, below it."
    (interactive)
    (save-excursion
     (let ((contents
            (buffer-substring
             (progn (beginning-of-line) (point))
             (progn (picture-newline 1) (point)))))
       (forward-line -1)
       (insert contents))))

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

>> The command was named "duplicate" because web browsers
>> provide the menu item "Duplicate tab".
>
> Of course, that makes sense.  But since "clone" seems to already be a
> term used in Emacs for this sort of thing, maybe we should consider
> using it, instead.

Maybe there is no problem when the command name will contain the word
"clone", but its menu item will be like in web browsers:

        `(menu-item "Duplicate" (lambda () (interactive)
            (tab-bar-clone-tab

And wouldn't it be too error-prone when the name 'tab-bar-clone-tab'
will differ only by one letter from another name 'tab-bar-close-tab'?

> For example, `clone-buffer' and `clone-process' both
> "Create a twin copy of...".

'tab-duplicate' is bound to 'C-x t n' and not to 'C-x t c' because
'clone-buffer' is bound to 'C-x x n' and not 'C-x x c'.

Re: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

>> Also since 'clone-frame' doesn't duplicate the frame,
>> we could add a new command 'duplicate-frame' as well.
>
> I don't know the signature of the `clone-frame'
> that was added to Emacs, but perhaps it could use
> a prefix arg to provide what you're proposing:
> clone the frame (same frame parameters) AND clone
> the window config of the frame in the new frame.

Its prefix arg is already used for something useless:

  (defun clone-frame (&optional frame use-default-parameters)
    "Make a new frame with the same parameters as FRAME.
  With a prefix arg (USE-DEFAULT-PARAMETERS), use
  `default-frame-alist' instead.

  FRAME defaults to the selected frame.  The frame is created on the
  same terminal as FRAME.  If the terminal is a text-only terminal then
  also select the new frame."
    (interactive "i\nP")
    (if use-default-parameters
        (make-frame-command)
      (let* ((default-frame-alist (seq-filter
                                   (lambda (elem)
                                     (not (eq (car elem) 'name)))
                                   (frame-parameters frame)))
             (new-frame (make-frame)))
        (unless (display-graphic-p)
          (select-frame new-frame))
        new-frame)))

Why does it use the prefix arg just to call another command
'make-frame-command'?

RE: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Drew Adams]

> > I don't know the signature of the `clone-frame'
> > that was added to Emacs, but perhaps it could use
> > a prefix arg to provide what you're proposing:
> > clone the frame (same frame parameters) AND clone
> > the window config of the frame in the new frame.
> 
> Its prefix arg is already used for something useless:
> 
>   (defun clone-frame (&optional frame use-default-parameters)
>     "Make a new frame with the same parameters as FRAME.
>   With a prefix arg (USE-DEFAULT-PARAMETERS), use
>   `default-frame-alist' instead.
> 
>   FRAME defaults to the selected frame.  The frame is created on the
>   same terminal as FRAME.  If the terminal is a text-only terminal then
>   also select the new frame."
>     (interactive "i\nP")
>     (if use-default-parameters
>         (make-frame-command)
>       (let* ((default-frame-alist (seq-filter
>                                    (lambda (elem)
>                                      (not (eq (car elem) 'name)))
>                                    (frame-parameters frame)))
>              (new-frame (make-frame)))
>         (unless (display-graphic-p)
>           (select-frame new-frame))
>         new-frame)))
> 
> Why does it use the prefix arg just to call another command
> 'make-frame-command'?

That's what I did in my `clone-frame', in order to
have just `C-x 5 2' bound.  IOW, I stole `C-x 5 2'
for `clone-frame', and allowed a prefix arg to
give you `make-frame-command'.  Personally, I
don't use `make-frame-commands', but some who use
my `clone-frame' might.

When I say that `clone-frame's prefix arg could
be used to get the behavior you're requesting
(clone the frame & duplicate its window config),
I mean that the prefix arg could do more than one
thing - there are different kinds of prefix args.
___

We _could_ have a single command, `clone-frame',
with prefix-arg behaviors for `make-frame-command'
(i.e., less than `clone-frame') and window-config
duplication (i.e., more than `clone-frame').  And
we could use one key for all of that: `C-x 5 2'.

That likely won't happen, based on the fact that
my suggestion to give `C-x 5 2' to `clone-frame'
(with `make-frame-command' via prefix arg) was
rejected in favor of Emacs sacrificing yet
another default key binding (why?).
___

What's more: IF we think that a reasonable number
of users might prefer one or the other of those
behaviors as their _default_ (1: make a plain
frame per `default-frame-alist'; 2: make a frame
with the same frame params; 3: make a frame with
the same frame params and the same window config),
THEN we could add a user option that controls that.
Then the prefix arg would let you get the other two
behaviors instead of your chosen default behavior.

That too is the kind of thing I sometimes do, and
the kind of thing vanilla Emacs abhors...

Re: [PATCH] New tab-bar-detach-tab command

[Adam Porter]

On Tue, Oct 5, 2021 at 12:01 PM Juri Linkov <juri@linkov.net> wrote:
>
> >> The command was named "duplicate" because web browsers
> >> provide the menu item "Duplicate tab".
> >
> > Of course, that makes sense.  But since "clone" seems to already be a
> > term used in Emacs for this sort of thing, maybe we should consider
> > using it, instead.
>
> Maybe there is no problem when the command name will contain the word
> "clone", but its menu item will be like in web browsers:
>
>         `(menu-item "Duplicate" (lambda () (interactive)
>             (tab-bar-clone-tab

I'd vote for naming the menu item to match the command, but I don't
feel strongly about it.  Maybe the menu could be seen as a place to
use terms more common in other software, in which case the disparity
would make sense.

> And wouldn't it be too error-prone when the name 'tab-bar-clone-tab'
> will differ only by one letter from another name 'tab-bar-close-tab'?

Seems okay to me.  It's probably not the only case in which two
commands' names differ by a letter.

> > For example, `clone-buffer' and `clone-process' both
> > "Create a twin copy of...".
>
> 'tab-duplicate' is bound to 'C-x t n' and not to 'C-x t c' because
> 'clone-buffer' is bound to 'C-x x n' and not 'C-x x c'.

Hm, "C-x x c" is unbound by default, so I'd vote for moving
`clone-buffer' to it.  :)  But, again, I don't feel strongly about
this, as these aren't commands I use often.

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

>> Maybe there is no problem when the command name will contain the word
>> "clone", but its menu item will be like in web browsers:
>>
>>         `(menu-item "Duplicate" (lambda () (interactive)
>>             (tab-bar-clone-tab
>
> I'd vote for naming the menu item to match the command, but I don't
> feel strongly about it.  Maybe the menu could be seen as a place to
> use terms more common in other software, in which case the disparity
> would make sense.

Another problem is that web browsers have such context menu items:
"Duplicate" and "Move tab to new window", but we have "Detach"
for the latter.  OTOH, "Move tab to new window" is overly long.
So only the help string could use the word "Move" like in browsers.

>> And wouldn't it be too error-prone when the name 'tab-bar-clone-tab'
>> will differ only by one letter from another name 'tab-bar-close-tab'?
>
> Seems okay to me.  It's probably not the only case in which two
> commands' names differ by a letter.

Currently it's easy to complete for M-x with just 'M-x tab-d RET'
since there is no 'tab-detach', only 'tab-duplicate'.
But with 'tab-clone' similar to 'tab-close', even 'M-x tab-clo'
is still not unique.

BTW, maybe an alias 'tab-detach' could be added as well?

>> > For example, `clone-buffer' and `clone-process' both
>> > "Create a twin copy of...".
>>
>> 'tab-duplicate' is bound to 'C-x t n' and not to 'C-x t c' because
>> 'clone-buffer' is bound to 'C-x x n' and not 'C-x x c'.
>
> Hm, "C-x x c" is unbound by default, so I'd vote for moving
> `clone-buffer' to it.  :)  But, again, I don't feel strongly about
> this, as these aren't commands I use often.

I guess 'clone-buffer' was bound to 'C-x x n' globally because
the same 'clone-buffer' is bound to 'M-n' in Info-mode.

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

> When I say that `clone-frame's prefix arg could
> be used to get the behavior you're requesting
> (clone the frame & duplicate its window config),
> I mean that the prefix arg could do more than one
> thing - there are different kinds of prefix args.

Now 'clone-frame' was fixed to clone the window config
and to use the prefix arg.

But I'm not sure if 'clone-frame' should be rebound from
'C-x 5 c' to 'C-x 5 n', like 'clone-buffer' is bound to 'C-x x n',
and 'tab-duplicate' is bound to 'C-x t n'.

RE: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Drew Adams]

> > When I say that `clone-frame's prefix arg could
> > be used to get the behavior you're requesting
> > (clone the frame & duplicate its window config),
> > I mean that the prefix arg could do more than one
> > thing - there are different kinds of prefix args.
> 
> Now 'clone-frame' was fixed to clone the window
> config and to use the prefix arg.
> 
> But I'm not sure if 'clone-frame' should be rebound
> from 'C-x 5 c' to 'C-x 5 n', like 'clone-buffer' is 
> bound to 'C-x x n',and 'tab-duplicate' is bound to
> 'C-x t n'.

(In Info, `clone-buffer' is bound to `M-n', BTW.
And in Emacs prior to 28, at least, it has _no_
global binding.)

IMHO, there's no reason to keep giving `C-x 5 2`
to `make-frame-command`.  All of the following
should be on the same key, distinguished by
default behavior versus different prefix-arg
behaviors:

* `make-frame-command' (or no longer give it any key)
* `clone-frame' - frame parameters
* `clone-frame' - frame parameters and window config

And all of that makes sense on `C-x 5 2', IMO.
The `2' is pretty naturally mnemonic for
duplicating/cloning/splitting.

In any case, I'd like to see only a single key
consumed by these make-a-frame behaviors, not
_both_ `C-x 5 2' and `C-x 5 <something else>'.

Re: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

>> But I'm not sure if 'clone-frame' should be rebound
>> from 'C-x 5 c' to 'C-x 5 n', like 'clone-buffer' is
>> bound to 'C-x x n',and 'tab-duplicate' is bound to
>> 'C-x t n'.
>
> (In Info, `clone-buffer' is bound to `M-n', BTW.
> And in Emacs prior to 28, at least, it has _no_
> global binding.)

(And in web browsers 'C-n' creates a new frame
that clones the frame parameters.)

> * `make-frame-command' (or no longer give it any key)
> * `clone-frame' - frame parameters
> * `clone-frame' - frame parameters and window config
>
> And all of that makes sense on `C-x 5 2', IMO.

But a new prefix arg could be added to `make-frame-command'
without rebinding its key `C-x 5 2'.  Then `make-frame-command'
could call `clone-frame' after typing `C-u C-x 5 2'.

But I wonder how the prefix arg of `C-u C-x 5 2' would be more
discoverable than the new key `C-x 5 c'?  The doc string
of `make-frame-command' could mention both: the prefix arg
that clones the frame, and `clone-frame' bound to `C-x 5 c'.

Re: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 07 Oct 2021 10:29:27 +0300
> Cc: Adam Porter <adam@alphapapa.net>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> >> But I'm not sure if 'clone-frame' should be rebound
> >> from 'C-x 5 c' to 'C-x 5 n', like 'clone-buffer' is
> >> bound to 'C-x x n',and 'tab-duplicate' is bound to
> >> 'C-x t n'.
> >
> > (In Info, `clone-buffer' is bound to `M-n', BTW.
> > And in Emacs prior to 28, at least, it has _no_
> > global binding.)
> 
> (And in web browsers 'C-n' creates a new frame
> that clones the frame parameters.)
> 
> > * `make-frame-command' (or no longer give it any key)
> > * `clone-frame' - frame parameters
> > * `clone-frame' - frame parameters and window config
> >
> > And all of that makes sense on `C-x 5 2', IMO.
> 
> But a new prefix arg could be added to `make-frame-command'
> without rebinding its key `C-x 5 2'.  Then `make-frame-command'
> could call `clone-frame' after typing `C-u C-x 5 2'.
> 
> But I wonder how the prefix arg of `C-u C-x 5 2' would be more
> discoverable than the new key `C-x 5 c'?  The doc string
> of `make-frame-command' could mention both: the prefix arg
> that clones the frame, and `clone-frame' bound to `C-x 5 c'.

Aren't we again giving a key binding to a command without any idea how
popular that command will be?  "Stealing" the prefix arg from "C-x 5 2" 
is even worse, IMO: it's a very old command which we will never
remove, and we might one day introduce some optional behavior for it,
and use C-u for that.  Why prevent that today on account of a command
whose importance is largely unknown (and by default should be
considered of low importance, since otherwise how did we manage
without it until now?).

I say let's remove the "C-x 5 c" binding as long as it isn't too late,
and reconsider the command's binding at a later date, when we know
more about its importance.

RE: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Drew Adams]

> > * `make-frame-command' (or no longer give it any key)
> > * `clone-frame' - frame parameters
> > * `clone-frame' - frame parameters and window config
> >
> > And all of that makes sense on `C-x 5 2', IMO.
> 
> But a new prefix arg could be added to `make-frame-command'
> without rebinding its key `C-x 5 2'.  Then `make-frame-command'
> could call `clone-frame' after typing `C-u C-x 5 2'.

It doesn't matter to me how it's done, as long
as only one key (`C-x 5 2') is sacrificed for
these 3 related behaviors, and as long as we
nevertheless provide separate commands, for
users who do want to bind different behaviors
to different keys.

> But I wonder how the prefix arg of `C-u C-x 5 2' would be more
> discoverable than the new key `C-x 5 c'?  The doc string
> of `make-frame-command' could mention both: the prefix arg
> that clones the frame, and `clone-frame' bound to `C-x 5 c'.

Discoverability is one thing.  I don't see it
as a big problem in what I proposed.  At least
as important, I think, is needlessly wasting
key bindings.

Discoverability is not only about keys; it's
about behaviors, and commands that realize them.

Re: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

> Aren't we again giving a key binding to a command without any idea how
> popular that command will be?  "Stealing" the prefix arg from "C-x 5 2"
> is even worse, IMO: it's a very old command which we will never
> remove, and we might one day introduce some optional behavior for it,
> and use C-u for that.  Why prevent that today on account of a command
> whose importance is largely unknown (and by default should be
> considered of low importance, since otherwise how did we manage
> without it until now?).
>
> I say let's remove the "C-x 5 c" binding as long as it isn't too late,
> and reconsider the command's binding at a later date, when we know
> more about its importance.

A command without a keybinding is like a programmer without a computer.

Re: [PATCH] New tab-bar-detach-tab command

[Juri Linkov]

> BTW, maybe an alias 'tab-detach' could be added as well?

I added two short aliases: 'tab-detach' for detaching a tab to a new frame,
and 'tab-window-detach' for detaching a window to a new tab.

RE: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Drew Adams]

> A command without a keybinding is like a programmer without a computer.

FWIW, I _really_ disagree with that.  Heaven
forbid we should add a key binding for each
command.

Better command completion might help you
change your mind ... or not.

[Actually, Emacs _has_ a keybinding (more
than one) for every command.  It just might
start with `M-x' and be followed by a few
chars. ;-)]

RE: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Drew Adams]

> > BTW, maybe an alias 'tab-detach' could be added as well?
> 
> I added two short aliases: 'tab-detach' for detaching a tab to a new
> frame, and 'tab-window-detach' for detaching a window to a new tab.

Just FYI/reminder: We use "tear-off" for a
window: `tear-off-window' (originally
`mouse-tear-off-window').

Not saying "tear-off" is better than "detach".
Just saying that that's what we have now, for
the analogous tearing-off of a window.

Re: [External] : Re: [PATCH] New tab-bar-detach-tab command

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: drew.adams@oracle.com,  adam@alphapapa.net,  emacs-devel@gnu.org
> Date: Thu, 07 Oct 2021 20:58:05 +0300
> 
> > Aren't we again giving a key binding to a command without any idea how
> > popular that command will be?  "Stealing" the prefix arg from "C-x 5 2"
> > is even worse, IMO: it's a very old command which we will never
> > remove, and we might one day introduce some optional behavior for it,
> > and use C-u for that.  Why prevent that today on account of a command
> > whose importance is largely unknown (and by default should be
> > considered of low importance, since otherwise how did we manage
> > without it until now?).
> >
> > I say let's remove the "C-x 5 c" binding as long as it isn't too late,
> > and reconsider the command's binding at a later date, when we know
> > more about its importance.
> 
> A command without a keybinding is like a programmer without a computer.

So all the commands we have in Emacs that don't have a binding are in
your opinion useless?

We will never have enough reasonably short key sequences to give a
binding to every command, so expressing such extreme views is not
constructive.