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