From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: [PATCH] New tab-bar-detach-tab command Date: Thu, 07 Oct 2021 10:43:25 +0300 Message-ID: <83k0ip1dr6.fsf@gnu.org> References: <87h7e4ikkz.fsf@alphapapa.net> <87pmsrrh7y.fsf@mail.linkov.net> <875yujizgi.fsf@alphapapa.net> <87o88bb21y.fsf@mail.linkov.net> <871r57i2cz.fsf@alphapapa.net> <87k0iu6n6x.fsf@mail.linkov.net> <87lf388zo5.fsf@mail.linkov.net> <87r1d0woq1.fsf@alphapapa.net> <878rz8aruo.fsf@mail.linkov.net> <875yub5sry.fsf@mail.linkov.net> <87v92ase7i.fsf_-_@mail.linkov.net> <87czohnvux.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3089"; mail-complaints-to="usenet@ciao.gmane.io" Cc: adam@alphapapa.net, drew.adams@oracle.com, emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 07 09:44:39 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYO51-0000cv-Nu for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Oct 2021 09:44:39 +0200 Original-Received: from localhost ([::1]:59144 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYO4z-0005Gl-Nz for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Oct 2021 03:44:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYO42-0004TC-MN for emacs-devel@gnu.org; Thu, 07 Oct 2021 03:43:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55588) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYO41-0004F6-5A; Thu, 07 Oct 2021 03:43:37 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1026 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYO3u-0000Ju-62; Thu, 07 Oct 2021 03:43:30 -0400 In-Reply-To: <87czohnvux.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 07 Oct 2021 10:29:27 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:276486 Archived-At: > From: Juri Linkov > Date: Thu, 07 Oct 2021 10:29:27 +0300 > 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'. 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.