More expclit guidelines for key-binding conventions

Karthik Chikmagalur <[email protected]> Wed, 05 Aug 2026 13:46:22 -0700
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
The rate at which new Emacs packages are created and released has gone
up in the last decade and continues to increase.  With this increase,
I'm also noticing that more Emacs packages are binding C-c LETTER keys
out of the box, ignoring the Elisp Key Binding Conventions laid out in
(info "(elisp) Key Binding Conventions").  These keybindings are applied
when the feature is loaded, usually overwriting the user's C-c LETTER
bindings.

I noticed three new-ish packages in the last two weeks that do this, but
several more every month this year.  I don't want to call anyone out since

- the convention is listed in an obscure location (Appendix D of the
  elisp manual),
- these packages are usually (but not always) by new authors naturally
  unaware of the guidelines,
- or they simply want it that way and don't care about conventions.
  They created the package and Emacs should work how they like, after
  all.  In this case it's only realistically an issue once the package
  has many users and the conflicting bindings causes them sufficient
  annoyance.

If you're not aware of this convention, I can also see the allure of the
mysteriously free cluster of C-c LETTER bindings in the midst of Emacs'
otherwise crowded keymap space.  It's natural to want your package to
take over those.

In the cases where this is out of ignorance, I was thinking that adding
a package-lint rule might help.   Not everyone runs package-lint (or its
flymake backend), so ideally a byte-compiler or checkdoc warning would
be better, but I'm not sure how these can be made to apply only to
features as opposed to the user-init-file.

Is something like this feasible and a good idea?

Karthik