Re: More expclit guidelines for key-binding conventions

Sean Whitton <[email protected]> Fri, 07 Aug 2026 11:46:02 +0100
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
Karthik Chikmagalur [05/Aug  1:46pm -07] wrote:
> 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?

Yes, automated checking for this problem is certainly welcome.

-- 
Sean Whitton