From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.devel Subject: Re: [External] : New key binding syntax Date: Fri, 19 Nov 2021 13:48:46 +0100 Message-ID: <2769797.b7ZiAu7f2a@galex-713.eu> References: <20211004081724.6281.11798@vcs0.savannah.gnu.org> <3597544.hBxPqSa7jC@galex-713.eu> <83pmqwuxih.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1552"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, rms@gnu.org, drew.adams@oracle.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 19 13:59:44 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 1mo3UW-00009R-1J for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 13:59:44 +0100 Original-Received: from localhost ([::1]:42764 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mo3UU-0006Vm-V3 for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 07:59:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41494) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo3K9-0000IF-F2 for emacs-devel@gnu.org; Fri, 19 Nov 2021 07:49:01 -0500 Original-Received: from [2a00:5884:8305::1] (port=37642 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo3K7-0005FP-84; Fri, 19 Nov 2021 07:49:01 -0500 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1mo3Jv-0002s5-N2; Fri, 19 Nov 2021 13:48:47 +0100 In-Reply-To: <83pmqwuxih.fsf@gnu.org> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:5884:8305::1 (failed) Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:279749 Archived-At: Le vendredi 19 novembre 2021, 13:43:02 CET Eli Zaretskii a =C3=A9crit : > > From: Alexandre Garreau > > Cc: emacs-devel@gnu.org, rms@gnu.org, stefankangas@gmail.com, > > drew.adams@oracle.com Date: Fri, 19 Nov 2021 12:33:32 +0100 > >=20 > > > > Why? everybody does that now and that=E2=80=99s strictly more recog= nizable > > > > for > > > > most of people (especially newcomers) nowadays > > >=20 > > > Does that mean you want us to go through all our manuals and the > > > tutorial, and change C-x and C-M-y into Ctrl+x and Ctrl+Alt+y? And > > > then change all the key-binding APIs to accept the above notation as > > > well? Because if we don't do that, there will be two very different > > > ways of specifying key sequences, and that will confuse newcomers > > > even > > > more. > >=20 > > Yes, and as I said it would be even more nice to have a special > > syntax/ > > command in texinfo to specify keysequences, so they can be > > programmatically all be changed very easily, in case the user rebinds > > them, so not only emacs=E2=80=99 C-h is updated, but the info manual as= well > > (and that could be useful as well for any software whose keys can and > > commonly are rebound) >=20 > Well, you certainly expect others to do a lot of work here. I don=E2=80=99t expect anything from anyone. That=E2=80=99s a lot of work,= and volunteers=20 cannot be considered responsible for keeping the status quo because that=20 involves (gratis) work (+ maintainance goes before the rest, and it=E2=80= =99s=20 already voluntary work). What you already do of course is already amazing :) Anyway initially I was just suggesting to merely *allow* for a + to=20 replace a -, for the future, given what=E2=80=99s possible, and what=E2=80= =99s done out=20 there.