From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Delegating user-reserved key binding space definition to users Date: Sun, 27 Nov 2022 05:45:18 +0000 Message-ID: <87o7sthrwx.fsf@localhost> References: <57b69c22e167d429d21bb969feb22887@webmail.orcon.net.nz> <877czikyfa.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="5467"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Psionic K , Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 27 06:45:50 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 1ozAUA-0001CX-DY for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Nov 2022 06:45:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozATE-00059o-VT; Sun, 27 Nov 2022 00:44:52 -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 1ozATB-00059P-KD for emacs-devel@gnu.org; Sun, 27 Nov 2022 00:44:50 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozAT9-0006a4-FP for emacs-devel@gnu.org; Sun, 27 Nov 2022 00:44:49 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 15184240026 for ; Sun, 27 Nov 2022 06:44:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1669527885; bh=jpiHyDuhMDKf6sADhnTTuu1dt56gjQJTip3q3qlsOIg=; h=From:To:Cc:Subject:Date:From; b=YmBITlyofFvGz8weoSpFeBxqUSJOFojn9NgB6LyuI0PDd5JWK7Npyul6JpFfFRf5w li9s3v+VqFvBEysX3CqXUjfroBbWp63P3T5oQgtojP9E28ChzJPgD/2x6ekMpIBxaq tXhRh3W8GZC4pUmBbnVxSvR8+FoUKfxx/A37CWbFCT71y9JRpnAN2AC0ppUsMzLRXA SmavWhA4cjgQElZyTFiW/3qmoBt0IIAXUh8UyeKRGe+E62jJuN6IGWht/53MQ/7Xac w4VETx9fJIjhXh9m2/XF0eR56YR9UenAlyxWiFvNOP2kOKMTgKmc2mQKFcqbymuv0P VkhlzBsm2ck0Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NKcxR3xPQz6tmc; Sun, 27 Nov 2022 06:44:43 +0100 (CET) In-Reply-To: Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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:300608 Archived-At: Stefan Monnier writes: >> 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. 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. Note that a number of commands like `comment-forward' already expect major modes to fit into an established, pre-defined framework by tweaking the `comment-forward' customization according to the major mode. This also requires a foresight. My suggestion is somewhat similar to the existing practices of major mode writing where the author is required to configure comment handling, paragraph handling, sentence rules, imenu, etc. However, what I suggest is more flexible as it does not require Emacs core developers to provide extensive configuration mechanism for, say, `next-line' individually; `previous-line' individually, ... Instead, it will be sufficient to declare generalized command and then rely on major modes to hook in. Users should be able to do it easily too. > [ 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. 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? I imagine that users can define a generalized command "move right" themselves, give it a default binding in overriding global map, and then make `paredit-forward-slurp-sexp', `org-promote', and `transpose-words' be selected when running "move right" depending on the active major mode. You cannot achieve this by simple remapping, AFAIK. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at