[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [External] : Re: [PATCH] New tab-bar-detach-tab command
From: |
Eli Zaretskii |
Subject: |
Re: [External] : Re: [PATCH] New tab-bar-detach-tab command |
Date: |
Thu, 07 Oct 2021 10:43:25 +0300 |
> 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: [PATCH] New tab-bar-detach-tab command, (continued)
- RE: [External] : Re: [PATCH] New tab-bar-detach-tab command, Drew Adams, 2021/10/05
- Re: [External] : Re: [PATCH] New tab-bar-detach-tab command, Juri Linkov, 2021/10/05
- RE: [External] : Re: [PATCH] New tab-bar-detach-tab command, Drew Adams, 2021/10/05
- Re: [PATCH] New tab-bar-detach-tab command, Juri Linkov, 2021/10/06
- RE: [External] : Re: [PATCH] New tab-bar-detach-tab command, Drew Adams, 2021/10/06
- Re: [External] : Re: [PATCH] New tab-bar-detach-tab command, Juri Linkov, 2021/10/07
- Re: [External] : Re: [PATCH] New tab-bar-detach-tab command,
Eli Zaretskii <=
- Re: [External] : Re: [PATCH] New tab-bar-detach-tab command, Juri Linkov, 2021/10/07
- RE: [External] : Re: [PATCH] New tab-bar-detach-tab command, Drew Adams, 2021/10/07
- Re: [External] : Re: [PATCH] New tab-bar-detach-tab command, Eli Zaretskii, 2021/10/07
- RE: [External] : Re: [PATCH] New tab-bar-detach-tab command, Drew Adams, 2021/10/07
- Re: [PATCH] New tab-bar-detach-tab command, Juri Linkov, 2021/10/05
- RE: [External] : Re: [PATCH] New tab-bar-detach-tab command, Drew Adams, 2021/10/05