From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Delegating user-reserved key binding space definition to users Date: Mon, 28 Nov 2022 13:15:26 -0500 Message-ID: References: <57b69c22e167d429d21bb969feb22887@webmail.orcon.net.nz> <877czikyfa.fsf@localhost> <87o7sthrwx.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17371"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Psionic K , Emacs developers To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 28 19:16:34 2022 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 1ozigE-0004F8-85 for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Nov 2022 19:16:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozifd-0000rL-Ld; Mon, 28 Nov 2022 13:15:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozifO-0000oa-Jj for emacs-devel@gnu.org; Mon, 28 Nov 2022 13:15:43 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozifI-0005X6-F0 for emacs-devel@gnu.org; Mon, 28 Nov 2022 13:15:38 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A9E024410ED; Mon, 28 Nov 2022 13:15:34 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 961AB4410D6; Mon, 28 Nov 2022 13:15:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1669659328; bh=OeZUHwKLHjcxWIHNGbJhP2oG+Lpe4YSow9vJDKJknfI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hfog6doqBZHUzsBqF4x/6B2H1YXKcTRL0PQ+N0TN5HBBjdzcGtQdzC3eKppriATDW vq+MioqdwqonNmdZDwpKOPRRW9TdvBqOx7g6ML5set/w1hDH0SSALHPyJqBOXfYFFs crbz2lnbT0ATd3pQ/J8z4PxMWCmuAJcKR1D7UJE+tUVldpU5kcnBxxl+kyEMDA5Jt9 P6w/7zCksnLYfGwvd6taqDzMr41a6ZpStwFelzeUl4gHLKC4USkrzJ40jA5xKZHrzR 7v+BIXNGobfLtoHcHx0sB4h5LzSrq3xiy+gUAzW+w5gR0ZIJZ7pp23mjHh1i7cKEOz 39RWezwecUb4g== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 468CD12097A; Mon, 28 Nov 2022 13:15:28 -0500 (EST) In-Reply-To: <87o7sthrwx.fsf@localhost> (Ihor Radchenko's message of "Sun, 27 Nov 2022 05:45:18 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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.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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300677 Archived-At: >>> I suggest introducing a notion of "generalized" commands. Such commands >>> will represent common actions executed by users (like move to >>> next/previous element). Major and minor modes can then define specific >>> implementation of the actions. >> >> I think it's a non-starter because it requires foresight: only those >> commands defined with this mechanism will be extensible. I agree that >> an additional level of indirection is probably necessary, but I suspect >> it needs to be placed elsewhere. > > Auto-remapping will need some kind of grouping for commands one way or > another. There is no way we can do it auto-magically. Developer or users > should decide. Agreed. But it should apply to all bindings. > Currently, the commands in major mods are bound to specific key > bindings. The bindings are chosen either arbitrarily, according to major > mode author preferences, or according to semi-established default key > binding scheme (like C-f/C-M-f/C-n/C-v/etc). Either way, trying to > re-bind commands in multiple major modes is not easy. Yup. I fully agree that it's a real problem. I'd welcome a solution to it. Even an "unrealistic" one would be good. Currently, I don't even know what a good solution could look like. To me a solution should allow packages to declare that command FOO should be bound to some key based on SOME-INFO, such that it will be bound to one key in "normal Emacs mode", and to another in `evil-mode` and to yet another in `god-mode`, etc... Some SOME-INFO needs to provide not a specific key, but some information from which we can compute the "natural key" that fits the keybinding style that the user selected. Then there are also the issues of overloading several operations on a single key (like TAB). So far we've solved this along the lines you suggest (a "generalized command", such as `indent-for-tab-command`), and maybe that's good enough for this, tho it prevents changing this overloading according to the keybinding style. [ BTW, another way to look at it is not "how can we compute which key to bind FOO to" but rather "how can we compute which command to run when KEY is hit". IOW, we could make keymaps more dynamic such that when you hit KEY, Emacs passes that to a "procedural keymap" which will *compute* (rather than lookup) which command to run, according to the current keybinding style. Not sure it would be better: I just mention it as one of the many things that we may want to consider in order to find a good solution to the problem. ] >> [ FWIW, you can get similar results with the current setup using >> command remapping. ] > You are absolutely right: when a major mode command is related to > built-in command in command map. Just to be clear: I don't think command remapping solves the problem at hand. It can sometimes be used for that, but not in general. > However, some major modes introduce new concepts. For example, think > about paredit-forward-slurp-sexp, which can be an equivalent of Org's > heading promotion or moving word at point forward in sentences. How > could you remap to group these 3 very different yet similar (for some > users) commands together? Great example, indeed, thanks. In this context, I'd like the package to be able to explain that this command is about a "sexp"-granularity operation and about "forward"-direction operation, so that the keybinding style may automatically find a natural/consistent key (or set of keys) to use for it depending on whether the current keybinding style uses f/b, or j/k, or left/right, or ... for forward/backward operations. Stefan