Re: Standardizing more key bindings?

[Stefan Monnier]

> So one decent example I have is minibuffer completion. Lets say I'm using
> ErgoEmacs and it expects previous element to work on F11 and next element on
> F12. But there are multiple minibuffer completion packages, like Ivy,
> Icicles, Helm and ErgoEmacs developers have to currently try to provide
> concrete bindings for whatever they choose to support.

The problem with it is that all of those completion packages provide
a slightly different set of commands.  So while the "next element" and
"previous element" command can easily be handled such that the choice of
key is handled elsewhere, you're still stuck with the choice of key for
the commands specific to Helm (say), unless your protocol covers "a
superset of all the completion packages".  If it's not a superset, then
the few missing commands will end up sticking out like a sore thumb
(or even conflict with some other keybinding).

So, I think the "keytheme" packages should be able to do more than give
explicit bindings to a particular set of (concrete or abstract)
commands.  They should also be able to describe their style in a more
"intensional" way, which would be used to *compute* the key to use for
a new command based on some suggestion from the command's package.


        Stefan