From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] New tab-bar-detach-tab command Date: Wed, 06 Oct 2021 19:38:30 +0300 Organization: LINKOV.NET Message-ID: <87a6jmyx0x.fsf@mail.linkov.net> 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> <87a6jovt2e.fsf@alphapapa.net> <87ee8z5swg.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18427"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (x86_64-pc-linux-gnu) Cc: emacs-devel To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 06 18:49:04 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 1mYA6J-0004g9-FX for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Oct 2021 18:49:03 +0200 Original-Received: from localhost ([::1]:53264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYA6H-0003Fa-D3 for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Oct 2021 12:49:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mY9xH-0001Sp-Lb for emacs-devel@gnu.org; Wed, 06 Oct 2021 12:39:47 -0400 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:42199) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mY9xE-0001YD-AZ for emacs-devel@gnu.org; Wed, 06 Oct 2021 12:39:43 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 41E5140009; Wed, 6 Oct 2021 16:39:35 +0000 (UTC) In-Reply-To: (Adam Porter's message of "Wed, 6 Oct 2021 06:23:59 -0500") Received-SPF: pass client-ip=217.70.183.194; envelope-from=juri@linkov.net; helo=relay2-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:276443 Archived-At: >> 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.