Stefan Monnier writes: >> in the recent discussion on reserving a keymap for packages, I proposed >> extending package.el to support a sort of formal specification of what a >> user should or could customize. As there were some supportive comments, >> I attempted to improve on an earlier proof-of-concept[0], resulting in >> the attached patch. > > Thanks. Could we "simply" make it a Custom group? > For keys I'd imagine something like > > (defcustom avy-global-goto-key nil > :group 'suggestions > :type 'key-sequence > :options '("C-:") > :set (lambda (symbol value) > (if value (global-set-key value 'avy-goto-char)))) > >> Part of my intention was to generate code that can easily be changed >> and adapted by the user (unlike custom-set-variables), so I don't >> analyse the files themselves. This might not look nice in some cases, >> but then again, these people are probably not the ones using this >> feature > > I don't understand what you mean to say here, sorry. No, it's my mistake, I'll try to rephrase it: The suggestion you've made above was also something I considered: Relying on the customize system makes it easier to implement the functionality but it at the same time hides it behind the complexity of customize. So while the absolute beginner wouldn't notice or care, the next step of a beginner might be confused how the keys were bound, and how to change it. That is why the patch generates "real" configuration code, not "hiding" what is going on, but demonstrating what and how changing your Emacs is done. The downside to this is that because there is no interface like customize, it can't just find and replace a previous global-set-key, because that would require modifying regular code in a user configuration, that might not even be in .emacs or init.el. Hope that clarifies the intention. > Stefan > -- Philip K.