From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: (wrong-type-argument keymapp notmuch-show-mode-map) in emacs on upgrade to notmuch from master
Date: Wed, 26 May 2021 22:03:42 -0400 [thread overview]
Message-ID: <87zgwhvsox.fsf@fifthhorseman.net> (raw)
In-Reply-To: <87h7ip2baq.fsf@fifthhorseman.net>
[-- Attachment #1.1: Type: text/plain, Size: 1863 bytes --]
On Wed 2021-05-26 21:52:13 -0400, Daniel Kahn Gillmor wrote:
> I'll try downgrading again to see what's replicable, but i'm kind of
> confused by this, as it's been working for years.
I don't have any problem with 0.31.4-1, but the problem is present with
0.32.1-1 from experimental. In all cases, i'm upgrading notmuch,
libnotmuch*, and elpa-notmuch in lockstep.
Nothing in NEWS between these versions suggests that my way of binding
keys is now deprecated.
I worry that this is due to one of the two following commits but my
elisp-foo is weak enough that i don't know what the right next steps are:
commit adfded9ed0a5a4b06886f462314cd4511cb72d47
Author: Jonas Bernoulli <jonas@bernoul.li>
Date: Mon Nov 16 22:28:42 2020 +0100
emacs: avoid binding unnamed commands in keymaps
One should never bind unnamed commands in keymaps because doing that
makes it needlessly hard for users to change these bindings.
Replace such anonymous bindings with named commands that are generated
using macros and some boilerplate. Using macros is better than using a
simple loop because that makes it possible for `find-function' to find
the definitions. Eat your boilerplate--it forms character.
Admittedly this approach is quite ugly and it might be better to teach
the original commands to support different buffers directly instead of
requiring wrapper commands to do just that.
Never-the-less as a short-term solution this is better than what we
had before.
commit 05a436f730cf6277c403b445bca9419ea89a7b2d
Author: Jonas Bernoulli <jonas@bernoul.li>
Date: Sun Nov 8 20:02:48 2020 +0100
emacs: don't fset keymaps
These keymaps are never invoked as commands
so the function definitions serve no purpose.
Regards,
--dkg
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2021-05-27 2:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 1:52 (wrong-type-argument keymapp notmuch-show-mode-map) in emacs on upgrade to notmuch from master Daniel Kahn Gillmor
2021-05-27 2:03 ` Daniel Kahn Gillmor [this message]
2021-05-27 3:34 ` Kyle Meyer
2021-05-27 14:01 ` Daniel Kahn Gillmor
2021-05-27 14:50 ` David Bremner
2021-05-27 16:58 ` [PATCH] NEWS/emacs: document changes in 0.32 that affect keybindings Daniel Kahn Gillmor
2021-05-27 17:11 ` Tomi Ollila
2021-05-27 21:46 ` Daniel Kahn Gillmor
2021-05-28 20:59 ` Tomi Ollila
2021-05-31 23:27 ` David Bremner
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://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zgwhvsox.fsf@fifthhorseman.net \
--to=dkg@fifthhorseman.net \
--cc=notmuch@notmuchmail.org \
/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://yhetil.org/notmuch.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).