From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#74140: [PATCH] Add :continue-only directive for repeat maps in bind-keys, use-package Date: Tue, 05 Nov 2024 20:25:24 +0200 Organization: LINKOV.NET Message-ID: <87v7x1edwr.fsf@mail.linkov.net> References: <86plnf9xqm.fsf@mail.linkov.net> <87ldxy953e.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33154"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) Cc: 74140@debbugs.gnu.org To: Paul Nelson Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 05 19:34:21 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1t8ONg-0008Re-N9 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Nov 2024 19:34:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8ONR-0005dA-CR; Tue, 05 Nov 2024 13:34:05 -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 1t8ONP-0005d0-2G for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 13:34:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t8ONO-0007MY-Pd for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 13:34:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=KdCvcWUfVGYCo0c0qSAwBPMrUM5i2+RLtJa3gVx6R0Y=; b=CFGLb13I/PjxFuUPbaZ3xPOpPg7nmtRqkPLWm4LkRw5Akrs1WTXjbrSJBkrsasGsitycBje2h5b3qPzAymUrarxzYTyLm3+C1xTYJcsZRj1ZpSss3hjAXL5k6CxPzuj8ApBkbhQHzM5FQRawUYzRfY882tjjkMnUJ5wqyglYLM5iC+jXsSL6+3tWryBopKAyGI77PbPmx1DMjv0lTc4CnP6u91ls3npUfYsrq3Vl3StoHogmJGAoMGeSFhyLLO6p6g0vqiw2u8MCsSUO0UoILoAvd9nddF48DI76O+96yKVMaxItwtGqrpgEAExLIu84aFDf9Ba6wCN0Yroe3rSxFw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t8ONO-0001JW-K5 for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 13:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Nov 2024 18:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74140-submit@debbugs.gnu.org id=B74140.17308316325032 (code B ref 74140); Tue, 05 Nov 2024 18:34:02 +0000 Original-Received: (at 74140) by debbugs.gnu.org; 5 Nov 2024 18:33:52 +0000 Original-Received: from localhost ([127.0.0.1]:40613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8OND-0001J5-RG for submit@debbugs.gnu.org; Tue, 05 Nov 2024 13:33:52 -0500 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:55667) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8ONC-0001Io-7K for 74140@debbugs.gnu.org; Tue, 05 Nov 2024 13:33:50 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 13AA51BF20B; Tue, 5 Nov 2024 18:33:20 +0000 (UTC) In-Reply-To: (Paul Nelson's message of "Mon, 4 Nov 2024 21:45:15 +0100") X-GND-Sasl: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:294916 Archived-At: >> > activate continue bind >> > :continue yes yes yes >> > :continue-only no yes yes >> > :exit no no yes >> > :enter yes no no >> >> Thanks, this table provides a clear overview. >> >> So bind-keys doesn't need :enter? Ok. > > I understand the purpose of bind-keys to be "bind keys to commands in > a keymap". Since :enter doesn't bind a key, it doesn't fit in > bind-keys. In defvar-keymap, :enter defines for a list of commands that activate a repeat-map with their global keybindings. Such as e.g. 'C-x u' for 'undo' when there are no keys with the 'undo' keybinding in the repeat-map. > There is a missing fourth case ("yes, no, yes") describing a key bound > to a command in a repeat map which the command activates but the key > exits. I haven't been imaginative enough to think of a good use case. > "Why does this command start a repeat sequence, but then terminate it > when I try to use it in that sequence?" I guess the case "yes, no, yes" is not needed because no one might want to define a global keybinding via bind-keys or defvar-keymap. >> Since defvar-keymap uses :continue by default, >> what is missing in defvar-keymap is :continue-only. >> For adding :continue-only to defvar-keymap >> I looked how you implemented it for bind-keys, >> and it seems making an alias doesn't look >> like a clean solution. >> >> I know that 'define-repeat-map' makes an alias as well. >> So some time ago I had one idea how such aliases >> could be avoided. The solution would be to put >> a new property like this: >> >> (put 'yank 'repeat-continue-keys '("y")) >> (put 'undo 'repeat-continue-keys '("C-/")) >> >> Its semantics is that when such a property exists >> then repeat-mode will check if the last typed keys >> don't exist in this list, only then the repeat map >> should be activated. > > I didn't quite follow. If the repeat map is active and the user > presses "C-/", then repeat-mode will see that the key in question > exists in the repeat-continue-keys list, and so will not activate the > repeat map. This is the opposite of the intended behavior. Perhaps > I've misunderstood? The property 'repeat-continue-keys' is intended to be used only to decide whether a global key sequence should activate the repeat-map or not. So maybe a better property name would be 'repeat-no-enter-keys'. Then your new bind-keys directive :continue-only could be named :no-entry (but :continue-only is fine if it's more clear). In any case such property could check not a command name, but a global key sequence, then decide whether it should activate the repeat-map. > I think that in an ideal world, "repeat-map" would be a property of a > keybinding inside a keymap, rather than a command. The alias-based > approach gives one approximation to that. Extending the standard keymap format would complicate it. So a less radical change would be to add extra information in the symbol property list. I see now that the previous idea was insufficient since it lacks a map. So a better way is to define a combination of a repeat-map and a key: (put 'undo 'repeat-continue-keys '((paragraph-repeat-map . "C-/"))) > I guess one alias-free approach would be to introduce a > repeat-continue property describing keymaps that a command should > perpetuate, e.g., > > (put 'yank 'repeat-continue '(paragraph-repeat-map)) > (put 'undo 'repeat-continue '(paragraph-repeat-map)) Keys are required as well to be able to decide whether to activate the repeat-map. There are two possible ways to do this: opt-in and out-out. 1. opt-in defines all global keys that activate a repeat-map. e.g.: (put 'undo 'repeat-entry-keys '((paragraph-repeat-map . "C-x u"))) 2. out-out defines only keys from the repeat-map that should not activate it by a global key such as the global "u" ('self-insert-command') should not activate paragraph-repeat-map: (put 'undo 'repeat-no-entry-keys '((paragraph-repeat-map . "u"))) > Anyway, is the idea that you'd like to see equivalent functionality in > defvar-keymap and/or to have both implementations avoid aliases? Yes, we need to keep feature parity between bind-keys and defvar-keymap, and I'd like to avoid aliases in defvar-keymap.