unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [PATCH] New tab-bar-detach-tab command
@ 2021-09-28 19:09 Adam Porter
  2021-09-29  1:05 ` Matt Beshara
  2021-09-29  7:09 ` Juri Linkov
  0 siblings, 2 replies; 33+ messages in thread
From: Adam Porter @ 2021-09-28 19:09 UTC (permalink / raw)
  To: emacs-devel

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


^ permalink raw reply related	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-09-28 19:09 [PATCH] New tab-bar-detach-tab command Adam Porter
@ 2021-09-29  1:05 ` Matt Beshara
  2021-09-29  7:11   ` Juri Linkov
  2021-09-29  7:43   ` Adam Porter
  2021-09-29  7:09 ` Juri Linkov
  1 sibling, 2 replies; 33+ messages in thread
From: Matt Beshara @ 2021-09-29  1:05 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-09-28 19:09 [PATCH] New tab-bar-detach-tab command Adam Porter
  2021-09-29  1:05 ` Matt Beshara
@ 2021-09-29  7:09 ` Juri Linkov
  2021-09-29  7:59   ` Adam Porter
  1 sibling, 1 reply; 33+ messages in thread
From: Juri Linkov @ 2021-09-29  7:09 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-09-29  1:05 ` Matt Beshara
@ 2021-09-29  7:11   ` Juri Linkov
  2021-09-29  7:43   ` Adam Porter
  1 sibling, 0 replies; 33+ messages in thread
From: Juri Linkov @ 2021-09-29  7:11 UTC (permalink / raw)
  To: Matt Beshara; +Cc: Adam Porter, emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-09-29  1:05 ` Matt Beshara
  2021-09-29  7:11   ` Juri Linkov
@ 2021-09-29  7:43   ` Adam Porter
  1 sibling, 0 replies; 33+ messages in thread
From: Adam Porter @ 2021-09-29  7:43 UTC (permalink / raw)
  To: emacs-devel

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.




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-09-29  7:09 ` Juri Linkov
@ 2021-09-29  7:59   ` Adam Porter
  2021-09-29 19:43     ` Juri Linkov
  0 siblings, 1 reply; 33+ messages in thread
From: Adam Porter @ 2021-09-29  7:59 UTC (permalink / raw)
  To: emacs-devel

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


^ permalink raw reply related	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-09-29  7:59   ` Adam Porter
@ 2021-09-29 19:43     ` Juri Linkov
  2021-09-29 19:54       ` Adam Porter
  0 siblings, 1 reply; 33+ messages in thread
From: Juri Linkov @ 2021-09-29 19:43 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-09-29 19:43     ` Juri Linkov
@ 2021-09-29 19:54       ` Adam Porter
  2021-10-03 17:19         ` Juri Linkov
  0 siblings, 1 reply; 33+ messages in thread
From: Adam Porter @ 2021-09-29 19:54 UTC (permalink / raw)
  To: emacs-devel

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.




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-09-29 19:54       ` Adam Porter
@ 2021-10-03 17:19         ` Juri Linkov
  2021-10-04 10:34           ` Adam Porter
  0 siblings, 1 reply; 33+ messages in thread
From: Juri Linkov @ 2021-10-03 17:19 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-03 17:19         ` Juri Linkov
@ 2021-10-04 10:34           ` Adam Porter
  2021-10-04 17:33             ` Juri Linkov
  0 siblings, 1 reply; 33+ messages in thread
From: Adam Porter @ 2021-10-04 10:34 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-04 10:34           ` Adam Porter
@ 2021-10-04 17:33             ` Juri Linkov
  2021-10-04 19:53               ` Adam Porter
  2021-10-05 15:15               ` [External] : " Drew Adams
  0 siblings, 2 replies; 33+ messages in thread
From: Juri Linkov @ 2021-10-04 17:33 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-04 17:33             ` Juri Linkov
@ 2021-10-04 19:53               ` Adam Porter
  2021-10-05  6:49                 ` Juri Linkov
  2021-10-05 16:35                 ` Juri Linkov
  2021-10-05 15:15               ` [External] : " Drew Adams
  1 sibling, 2 replies; 33+ messages in thread
From: Adam Porter @ 2021-10-04 19:53 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-04 19:53               ` Adam Porter
@ 2021-10-05  6:49                 ` Juri Linkov
  2021-10-05  7:17                   ` Adam Porter
  2021-10-05 15:18                   ` Drew Adams
  2021-10-05 16:35                 ` Juri Linkov
  1 sibling, 2 replies; 33+ messages in thread
From: Juri Linkov @ 2021-10-05  6:49 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-05  6:49                 ` Juri Linkov
@ 2021-10-05  7:17                   ` Adam Porter
  2021-10-05 15:27                     ` [External] : " Drew Adams
  2021-10-05 16:38                     ` Juri Linkov
  2021-10-05 15:18                   ` Drew Adams
  1 sibling, 2 replies; 33+ messages in thread
From: Adam Porter @ 2021-10-05  7:17 UTC (permalink / raw)
  To: emacs-devel

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.




^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-04 17:33             ` Juri Linkov
  2021-10-04 19:53               ` Adam Porter
@ 2021-10-05 15:15               ` Drew Adams
  1 sibling, 0 replies; 33+ messages in thread
From: Drew Adams @ 2021-10-05 15:15 UTC (permalink / raw)
  To: Juri Linkov, Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-05  6:49                 ` Juri Linkov
  2021-10-05  7:17                   ` Adam Porter
@ 2021-10-05 15:18                   ` Drew Adams
  2021-10-05 16:40                     ` Juri Linkov
  1 sibling, 1 reply; 33+ messages in thread
From: Drew Adams @ 2021-10-05 15:18 UTC (permalink / raw)
  To: Juri Linkov, Adam Porter; +Cc: emacs-devel@gnu.org

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




^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-05  7:17                   ` Adam Porter
@ 2021-10-05 15:27                     ` Drew Adams
  2021-10-05 16:38                     ` Juri Linkov
  1 sibling, 0 replies; 33+ messages in thread
From: Drew Adams @ 2021-10-05 15:27 UTC (permalink / raw)
  To: Adam Porter, emacs-devel@gnu.org

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-04 19:53               ` Adam Porter
  2021-10-05  6:49                 ` Juri Linkov
@ 2021-10-05 16:35                 ` Juri Linkov
  1 sibling, 0 replies; 33+ messages in thread
From: Juri Linkov @ 2021-10-05 16:35 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

> (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))))



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-05  7:17                   ` Adam Porter
  2021-10-05 15:27                     ` [External] : " Drew Adams
@ 2021-10-05 16:38                     ` Juri Linkov
  2021-10-06 11:23                       ` Adam Porter
  1 sibling, 1 reply; 33+ messages in thread
From: Juri Linkov @ 2021-10-05 16:38 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-05 15:18                   ` Drew Adams
@ 2021-10-05 16:40                     ` Juri Linkov
  2021-10-05 17:27                       ` Drew Adams
  0 siblings, 1 reply; 33+ messages in thread
From: Juri Linkov @ 2021-10-05 16:40 UTC (permalink / raw)
  To: Drew Adams; +Cc: Adam Porter, emacs-devel@gnu.org

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-05 16:40                     ` Juri Linkov
@ 2021-10-05 17:27                       ` Drew Adams
  2021-10-06 16:39                         ` Juri Linkov
  0 siblings, 1 reply; 33+ messages in thread
From: Drew Adams @ 2021-10-05 17:27 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Adam Porter, emacs-devel@gnu.org

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-05 16:38                     ` Juri Linkov
@ 2021-10-06 11:23                       ` Adam Porter
  2021-10-06 16:38                         ` Juri Linkov
  0 siblings, 1 reply; 33+ messages in thread
From: Adam Porter @ 2021-10-06 11:23 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-06 11:23                       ` Adam Porter
@ 2021-10-06 16:38                         ` Juri Linkov
  2021-10-07 18:02                           ` Juri Linkov
  0 siblings, 1 reply; 33+ messages in thread
From: Juri Linkov @ 2021-10-06 16:38 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-05 17:27                       ` Drew Adams
@ 2021-10-06 16:39                         ` Juri Linkov
  2021-10-06 20:20                           ` [External] : " Drew Adams
  0 siblings, 1 reply; 33+ messages in thread
From: Juri Linkov @ 2021-10-06 16:39 UTC (permalink / raw)
  To: Drew Adams; +Cc: Adam Porter, emacs-devel@gnu.org

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-06 16:39                         ` Juri Linkov
@ 2021-10-06 20:20                           ` Drew Adams
  2021-10-07  7:29                             ` Juri Linkov
  0 siblings, 1 reply; 33+ messages in thread
From: Drew Adams @ 2021-10-06 20:20 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Adam Porter, emacs-devel@gnu.org

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




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-06 20:20                           ` [External] : " Drew Adams
@ 2021-10-07  7:29                             ` Juri Linkov
  2021-10-07  7:43                               ` Eli Zaretskii
  2021-10-07 15:56                               ` Drew Adams
  0 siblings, 2 replies; 33+ messages in thread
From: Juri Linkov @ 2021-10-07  7:29 UTC (permalink / raw)
  To: Drew Adams; +Cc: Adam Porter, 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'.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-07  7:29                             ` Juri Linkov
@ 2021-10-07  7:43                               ` Eli Zaretskii
  2021-10-07 17:58                                 ` Juri Linkov
  2021-10-07 15:56                               ` Drew Adams
  1 sibling, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2021-10-07  7:43 UTC (permalink / raw)
  To: Juri Linkov; +Cc: adam, drew.adams, emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-07  7:29                             ` Juri Linkov
  2021-10-07  7:43                               ` Eli Zaretskii
@ 2021-10-07 15:56                               ` Drew Adams
  1 sibling, 0 replies; 33+ messages in thread
From: Drew Adams @ 2021-10-07 15:56 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Adam Porter, emacs-devel@gnu.org

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-07  7:43                               ` Eli Zaretskii
@ 2021-10-07 17:58                                 ` Juri Linkov
  2021-10-07 18:19                                   ` Drew Adams
  2021-10-07 18:28                                   ` Eli Zaretskii
  0 siblings, 2 replies; 33+ messages in thread
From: Juri Linkov @ 2021-10-07 17:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: adam, drew.adams, emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [PATCH] New tab-bar-detach-tab command
  2021-10-06 16:38                         ` Juri Linkov
@ 2021-10-07 18:02                           ` Juri Linkov
  2021-10-07 18:23                             ` [External] : " Drew Adams
  0 siblings, 1 reply; 33+ messages in thread
From: Juri Linkov @ 2021-10-07 18:02 UTC (permalink / raw)
  To: Adam Porter; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-07 17:58                                 ` Juri Linkov
@ 2021-10-07 18:19                                   ` Drew Adams
  2021-10-07 18:28                                   ` Eli Zaretskii
  1 sibling, 0 replies; 33+ messages in thread
From: Drew Adams @ 2021-10-07 18:19 UTC (permalink / raw)
  To: Juri Linkov, Eli Zaretskii; +Cc: adam@alphapapa.net, emacs-devel@gnu.org

> 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. ;-)]



^ permalink raw reply	[flat|nested] 33+ messages in thread

* RE: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-07 18:02                           ` Juri Linkov
@ 2021-10-07 18:23                             ` Drew Adams
  0 siblings, 0 replies; 33+ messages in thread
From: Drew Adams @ 2021-10-07 18:23 UTC (permalink / raw)
  To: Juri Linkov, Adam Porter; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: [External] : Re: [PATCH] New tab-bar-detach-tab command
  2021-10-07 17:58                                 ` Juri Linkov
  2021-10-07 18:19                                   ` Drew Adams
@ 2021-10-07 18:28                                   ` Eli Zaretskii
  1 sibling, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2021-10-07 18:28 UTC (permalink / raw)
  To: Juri Linkov; +Cc: adam, drew.adams, emacs-devel

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



^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2021-10-07 18:28 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-09-28 19:09 [PATCH] New tab-bar-detach-tab command Adam Porter
2021-09-29  1:05 ` Matt Beshara
2021-09-29  7:11   ` Juri Linkov
2021-09-29  7:43   ` Adam Porter
2021-09-29  7:09 ` Juri Linkov
2021-09-29  7:59   ` Adam Porter
2021-09-29 19:43     ` Juri Linkov
2021-09-29 19:54       ` Adam Porter
2021-10-03 17:19         ` Juri Linkov
2021-10-04 10:34           ` Adam Porter
2021-10-04 17:33             ` Juri Linkov
2021-10-04 19:53               ` Adam Porter
2021-10-05  6:49                 ` Juri Linkov
2021-10-05  7:17                   ` Adam Porter
2021-10-05 15:27                     ` [External] : " Drew Adams
2021-10-05 16:38                     ` Juri Linkov
2021-10-06 11:23                       ` Adam Porter
2021-10-06 16:38                         ` Juri Linkov
2021-10-07 18:02                           ` Juri Linkov
2021-10-07 18:23                             ` [External] : " Drew Adams
2021-10-05 15:18                   ` Drew Adams
2021-10-05 16:40                     ` Juri Linkov
2021-10-05 17:27                       ` Drew Adams
2021-10-06 16:39                         ` Juri Linkov
2021-10-06 20:20                           ` [External] : " Drew Adams
2021-10-07  7:29                             ` Juri Linkov
2021-10-07  7:43                               ` Eli Zaretskii
2021-10-07 17:58                                 ` Juri Linkov
2021-10-07 18:19                                   ` Drew Adams
2021-10-07 18:28                                   ` Eli Zaretskii
2021-10-07 15:56                               ` Drew Adams
2021-10-05 16:35                 ` Juri Linkov
2021-10-05 15:15               ` [External] : " Drew Adams

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