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 23:01:49 -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="25721"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Ihor Radchenko , Emacs developers To: Psionic K Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 29 05:02: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 1ozrpZ-0006Pw-R3 for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Nov 2022 05:02:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozroj-0002PI-1m; Mon, 28 Nov 2022 23:01: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 1ozroh-0002P8-F7 for emacs-devel@gnu.org; Mon, 28 Nov 2022 23:01:55 -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 1ozrof-00013Q-Hi for emacs-devel@gnu.org; Mon, 28 Nov 2022 23:01:55 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F16E44420FD; Mon, 28 Nov 2022 23:01:51 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 42CBD440B1A; Mon, 28 Nov 2022 23:01:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1669694510; bh=xdKtodFDkySLD13HcvCVY/xBLR6pQwFLZwpqfkiif0I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=EcSzyxbkOlubNyBzZ+EX3yHBOeP3kvUWN8BQTZotvTg3e2NQEc6DiJhiAlU7m+8Eu ublH217eFmFDdfkSk70suRImhf9AnG/fc7vN+mK7bjrsYG1qeZ2Cav9+RA9c75GiWu 3JqAj62RTyoD/Gs0MwplVlfvVASgju2ZDshZSQ4GLHXn9i6djHinFkEY17KVgySZJ4 64NC9a6RlM8Qm2IGh7P9lKYWPhwRdnGMphfnYvQerAHwmUO6F58u5fZAYqp123BA3b MV8AuuAHZJHIZ7z4OW/EgaL2HTfGNbFHlLpIQ5RI35hcuavNo6NxFZEoShKLRjsz6y IQuQdROHGXAtA== Original-Received: from pastel (unknown [104.247.241.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1586D120346; Mon, 28 Nov 2022 23:01:50 -0500 (EST) In-Reply-To: (Psionic K.'s message of "Mon, 28 Nov 2022 20:38:47 -0600") 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:300698 Archived-At: >> 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-INFO will be of the form: > ((concept command) (concept command) ...)) ; package provide > ((concept (concept concept concept)) (concept concept)) ; overload > remappings, perhaps user or package provided or both > ((concept binding) (concept binding)) ; user or emulation mode etc provided I'm afraid I don't know what this means. Can you try and make it more concrete with an example? Note that in the text I wrote, SOME-INFO was supposed to be a piece of information specific to the command FOO. I get the impression that your SOME-INFO includes info for several commands. Maybe we'll have to do that, but I was hoping we could avoid it. > In the beginning, before packages provide their half, the user will provide > it, likely through a package. This is analogous to evil collection. I don't want SOME-INFO to explicitly say what should happen for `evil-mode`, vanilla Emacs mode, `god-mode`, `boon-mode`, `ergoemacs-mode`, modalka, ... This is the mess we already have. Instead SOME-INFO should give just enough data to those modes such that they can wisely (and predictably) choose a binding for that command. >> 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... > > This places too much emphasis on package authors. I hope with my above explanation you can agree that it also gives a lot of power to the keybinding styles. And of course, ultimately the end-user can override any of those decisions (this is Emacs we're talking about, after all). > As stated above, I believe it's the job of modal systems to > decide how to consume the package-defined half of SOME-INFO. IIUC we violently agree. I personally don't yet have a clear idea of what SOME-INFO may look like. I suspect it could include some letters (used as hints to help the keybinding-style choose keys) plus a set of "features" maybe (like forward/up/down/backward for direction, or add/remove, or char/word/symbol/sexp/buffer for granularity/subject). It should likely include also some notion of scope (global, buffer-local, local to a region, specific to some particular set of major mode, only meaningful when the region is active, ...). Stefan