From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#54074: 29.0.50; Feature request emacs keymap-set and minor-modes Date: Tue, 22 Feb 2022 09:07:02 -0500 Message-ID: References: <87ley5iclc.fsf.ref@aol.com> <87ley5iclc.fsf@aol.com> <87czjhmior.fsf@gnus.org> <87fsobc9xy.fsf@gnus.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3197"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Ergus , 54074@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 22 15:12:52 2022 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 1nMVuM-0000ZX-LL for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Feb 2022 15:12:50 +0100 Original-Received: from localhost ([::1]:41358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMVuL-0000am-0M for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Feb 2022 09:12:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34638) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMVpi-0000FE-2B for bug-gnu-emacs@gnu.org; Tue, 22 Feb 2022 09:08:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46593) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nMVph-0007bG-Ov for bug-gnu-emacs@gnu.org; Tue, 22 Feb 2022 09:08:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nMVph-0008G4-LO for bug-gnu-emacs@gnu.org; Tue, 22 Feb 2022 09:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Feb 2022 14:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54074 X-GNU-PR-Package: emacs Original-Received: via spool by 54074-submit@debbugs.gnu.org id=B54074.164553883331690 (code B ref 54074); Tue, 22 Feb 2022 14:08:01 +0000 Original-Received: (at 54074) by debbugs.gnu.org; 22 Feb 2022 14:07:13 +0000 Original-Received: from localhost ([127.0.0.1]:40490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMVov-0008F4-8Y for submit@debbugs.gnu.org; Tue, 22 Feb 2022 09:07:13 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMVot-0008En-MF for 54074@debbugs.gnu.org; Tue, 22 Feb 2022 09:07:12 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9CD3E1000D2; Tue, 22 Feb 2022 09:07:05 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0571B1001D2; Tue, 22 Feb 2022 09:07:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1645538824; bh=XmOq5iysKtzBxtWxa/DsjjNL0vjlx3IjFAbYwtDSwnY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GiwiZEz8nPzky5s5497fSfLID/cdcPd4oSt78QOyKvrsjCLpKGA8LLkq4YBvoSEZC vGYMpJDrd1/EhcLsAR0SLU7UkIkWDruAhZPAYkrkI1pmDR3mEdKz0chi7zjewl/2Ol pMeV3vkyLBkS1TUGQthNZb5QQmiMLexkt3TUVZlm2xqXOYvgeXmO1ThZEEjiVX/m/t t9eXW9y1iJVrmkFWjjWxo3WUH2IKk0UuesmBGsjSkEGawnstd35GADG0ClHvTQbyJ6 Ff0dKPhURxFiae5s4GWRvwxw0FeiJeBxn0UnXoVhgIHvny9hlhyVnHr28/WAXFRfAZ GEbcmfF3WX98A== Original-Received: from pastel (unknown [45.72.197.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A8AF2120891; Tue, 22 Feb 2022 09:07:03 -0500 (EST) In-Reply-To: <87fsobc9xy.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 22 Feb 2022 14:22:49 +0100") 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" Xref: news.gmane.io gmane.emacs.bugs:227433 Archived-At: Lars Ingebrigtsen [2022-02-22 14:22:49] wrote: > Stefan Monnier writes: >>> I'm not sure I understand the use case. Isn't the way to do this just >>> to have my-mode add itself to isearch-mode-hook, and then have my-mode >>> have a minor mode keymap with the prefix it uses? >> I think the use case is basically any minor mode which currently uses >> `define-key` in its body to modify some other package's keymap. > But why do that instead of using a minor mode? [ I assume you meant "using a minor mode MAP". ] E.g. because they don't want the priority that comes with minor mode maps? > I think many cases where packages do this, it's because the idea > didn't really occur to the people that did the implementation. Many, maybe, but definitely not all. BTW, we currently have related functions to add/remove a keymap from another: `internal-push/pop-keymap` used by `set-transient-map`. >> The minor mode can then add/remove a function from the list, and just as >> is the case with `add-hook`, `add-function`, etc... it will correctly >> handle the case where the additions/removals are not nested. > My feeling is that this would be both too complicated for most people > writing modes, and it would be really confusing for us people that have > to try to figure out what's actually going on, and finally, values in > Emacs Lisp are mutable, so it won't work reliably anyway. W.r.t complexity, it's a worry, indeed. Until someone implements it and tries to provide convenient ways to use it (e.g. for minor modes), it's hard to tell. W.r.t it being unreliable, it shouldn't be any less reliable than what we have today, and more importantly any misbehavior could then be fixed by making the relevant code(s) use the new API, whereas currently there's basically no way to fix those problems (short of ad-hoc hacks). Stefan