Gregory Heytings writes: > No, with one control key you have all characters (not just letters, > also digits and symbols), plus all C-something, plus all M-something, > plus C-M-something. With one control key and its corrsponding meta > key you multiply that number by two. Ah ok, I get what you mean. Does it really make that much of a difference? I'm not sure how many packages you are expecting would add default bindings (or how conflict resolution should happen), but do you really need more than 26? How many packages do people install, where an interactive command is the entry-point _and_ has to be bound to a key by default? In my case it is only Magit, and that's bound to C-c g without any problems. Also, here's another annoyance: What if I don't like the default binding? How would you expect this to be modified? Would a package constantly try to modify my config to add what it thinks should be the right key to trigger the right command? >>> It's what most users expect. apt install elpa-magit, C-x g, and >>> voilà: Magit works. >> >> How do you come to this conclusion? > > It's what Magit (and other similar packages) do. The presupposition > of the proposal is that such packages know their users. I only know of Magit that does it, and as I have said before, I think it is a mistake and unfriendly. But that still doesn't answer the question. Why do you think that users expect it -- not the image that magit has it it's users. >>> BTW, Emacs already does "behind-your-back" customizations, and >>> doesn't ask you any questions for them. It provides sensible >>> defaults, which work in most cases, and which you can change if >>> need be. >> >> I don't get your point here. Are you saying "default Emacs" is a >> "behind-your-back customization"? > > No, I mean that installing packages already does some > "behind-your-back" customizations, for example by modifying > auto-mode-alist. There are cases when such modifications do not what > some particular user would expect; as someone mentioned, a package for > Perl who would override the setting of a package for Prolog because > both use the .pl extension. Yes, and as I have said in a previous message (or in my article for that matter), I think it is problematic. Lucky the situation with auto-mode-alist is more relaxed, since auto-mode-list benefits from the fact that file extensions tend not to conflict with one-another (survival of the more popular). Also, if I am not mistaken, packages that manipulate auto-mode-alist add their entry to the end of the list, so that if a user wants to interpret .pl as whatever they want, they won't interfere. This kind of a respect for the user would have to be necessary for what you propose, so that an implicit Emacs etiquette is preserved. -- Philip K.