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: Delegating user-reserved key binding space definition to users Date: Tue, 29 Nov 2022 15:03:38 +0200 Message-ID: <83fse1nc9h.fsf@gnu.org> References: <57b69c22e167d429d21bb969feb22887@webmail.orcon.net.nz> <877czikyfa.fsf@localhost> <87o7sthrwx.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2877"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, yantar92@posteo.net, emacs-devel@gnu.org To: Psionic K Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 29 14:04:09 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 1p00HP-0000Sa-T7 for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Nov 2022 14:04:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p00Go-0003am-61; Tue, 29 Nov 2022 08:03:31 -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 1p00GR-0003QL-OT for emacs-devel@gnu.org; Tue, 29 Nov 2022 08:03:18 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p00GQ-00087s-Vq; Tue, 29 Nov 2022 08:03:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ih9oKYkTaL0MpzhwhDlKvQNEkFaDWkDH1GkWY1cGjHU=; b=Wcc3IpRWcjYL +NthztrLl85Gr90RoawdBLLDp2R40/3iUvNWL2CgG0SopjU/6oYGBUPg3A0L0sT3PamWJDfvQgbZV 7GU84nOBIgtVKr962EjoW3vX/0ISZVZBA587rZ6qiEuifbPIiKbnyCBRbr/TCaahquUbXoxdfj2FA sbUp6HuuxAv8qDfjwpxic9F+xrD/WecU5JovHkvkbKpw7OhU+dogJGoCePYumPKB4gRB/KOiqG7Mw TSzmZbp1NZTTfH95oJyCOnQJv78kA/0tCD0/HWo88Rzg9TbdAHBm/aE0j/YiE8r2/nYvWl/s6Uged Ljgk6OeXWrAXBRLBIwVV0w==; Original-Received: from [87.69.77.57] (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 1p00GQ-000596-G5; Tue, 29 Nov 2022 08:03:06 -0500 In-Reply-To: (message from Psionic K on Mon, 28 Nov 2022 23:22:24 -0600) 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:300710 Archived-At: > From: Psionic K > Date: Mon, 28 Nov 2022 23:22:24 -0600 > Cc: Ihor Radchenko , > Emacs developers > > ;; The user will specify concept / abstract commands -> key sequences > (setq-custom concept-sequences '((user-next ?\M-n) (user-prev ?\M-p))) > ;; The package will specify concepts / abstract commands -> concrete commands > ;; So, something like a magit section mode intended to be derived from, the package author writes: > (setq-local concept-commands '((user-next #'magit-section-next) (user-prev #'magit-section-prev))) > ;; And then the package tells the implementation to consume the declarations, which might occur after the > mode hook to let the user intervene > (emacs-function-setup-concept-keymap) > > `emacs-function-setup-concept-keymap' would be an implementation that ties the user's declaration of > sequence -> concept mappings together with the package's concept -> command mappings. The result is > that the local map should contain some command remap shadows corresponding to what the user and the > package declared. > > I neglected overloading in my example, but basically a user might be okay with several concepts being able > to map to one key and the package might be okay with mapping the same command to one of several > concepts. > > IMO these declarations one-to-many declarations should only be used with two specific conventions: > > 1 Package authors specify a list of increasingly more generic concepts, ending with `user-generic' which > would just mean "any key that the user has bestowed upon packages by default.". An example of more > abstract definitions would be a declaration like (#'magit-section-next (user-next user-navigation)). The > implementation could try to map to user-next and if that's not available, use an available sequence from > user-navigation. > 2 The user's convention for one-to-many mappings is different. They might want to map a generic concept > onto several key sequences in order, so they might declare something like '(user-navigation (?\M-p ?\M-n > ?\M-f ?\M-b)). If a package declares a user-next, user-prev, and two more user-navigation commands, > the implementation will give them all keymap elements. > > > I get the impression that your > > SOME-INFO includes info for several commands. > > Yes. The reason commands should not handle this declaration is because the implementation would have > to discover the commands, and this would be fragile if the user starts replacing commands or wants to > specify commands that the package has no idea about. > > I'm also preoccupied with automating the user-driven re-mapping of commands to key sequences when > those commands express an extremely similar idea, such as "next". I see this as a prerequisite for what I > think you want. I don't think I agree with what I think you want, and this could be messing with my > interpretation, but it is a prerequisite still. > > We have lots of convention, lots of similarity in mode keymaps, but we it's ad-hoc, and we just need to make > it official so that the conventions are useful and user's can change one declaration to move, for example, > C-g. I think this discussion started from the wrong starting point, and that's why the common understanding is difficult and misunderstandings abundant: there's no reason to believe you and Stefan (and myself, and others who read this) have the same goals and the same issues in mind. The basic problem here is that we don't have a clear commonly-shared idea of what we want to support with these features. My suggestion is to start from clarifying these requirements. A good method of understanding requirements is to describe typical use-cases and their variations, as you probably know. With that in mind, would you or someone else please describe such use-cases? Specifically: . what does the user specify? . what should happen with key bindings to various commands as result of the user specifications? For instance, with your example: > ;; The user will specify concept / abstract commands -> key sequences > (setq-custom concept-sequences '((user-next ?\M-n) (user-prev ?\M-p))) > ;; The package will specify concepts / abstract commands -> concrete commands > ;; So, something like a magit section mode intended to be derived from, the package author writes: > (setq-local concept-commands '((user-next #'magit-section-next) (user-prev #'magit-section-prev))) > ;; And then the package tells the implementation to consume the declarations, which might occur after the > mode hook to let the user intervene > (emacs-function-setup-concept-keymap) I have no idea what will be the binding of magit-section-next. And, since you only gave a single command as an example, I have no idea how is what you propose better than just saying (local-set-key ?\M-n #'magit-section-next) I understand what Stefan says about "letters" (probably meaning that 'n' should be used in "next-FOO" commands and 'p' in "prev-FOO"), but I don't understand what you are saying, because you didn't tell enough about your eventual goal, in practical terms.