unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Ergus <spacibba@aol.com>, 54074@debbugs.gnu.org
Subject: bug#54074: 29.0.50; Feature request emacs keymap-set and minor-modes
Date: Tue, 22 Feb 2022 09:07:02 -0500	[thread overview]
Message-ID: <jwv35kbhump.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87fsobc9xy.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 22 Feb 2022 14:22:49 +0100")

Lars Ingebrigtsen [2022-02-22 14:22:49] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> 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






  reply	other threads:[~2022-02-22 14:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87ley5iclc.fsf.ref@aol.com>
2022-02-20 19:04 ` bug#54074: 29.0.50; Feature request emacs keymap-set and minor-modes Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-20 19:39   ` Lars Ingebrigtsen
2022-02-20 21:18     ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-20 22:09     ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 21:22     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-22 13:22       ` Lars Ingebrigtsen
2022-02-22 14:07         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-02-22 14:31           ` Lars Ingebrigtsen
2022-02-22 15:39             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-23 12:12               ` Lars Ingebrigtsen
2022-02-20 22:34   ` bug#54074: [External] : " Drew Adams
2022-02-21 21:05     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21  8:28   ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv35kbhump.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=54074@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=spacibba@aol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).