Re: Customizing key bindings

[Miles Bader]

Per Abrahamsen <address@hidden> writes:
> > The above situation seems rather silly (and unlikely); if `foo-extra' screws
> > around like that, then I don't think we should expect custom to intuit what
> > the right thing to do is. 
> 
> Such packages are common for "global-map".

My first reaction was to say `true', but now that I think about it, are they?

The usual way that global bindings are established is to bind the key
ahead of time (often via ###autoload), and autoload the package when
the binding is first invoked.  In those cases, the `default binding' is
established ahead of time, so customize will find it.

One exception is e.g., gdb-mode (with its `C-x C-a' prefix bindings).

> > ... which is a misnomer, since it's not really `100%', just 90% with a
> > different 10% cut out.
> 
> As you pointed out, it would require a "when (interactive-p)" added to
> global-(un)set-key and local-(un)set-key to be a 100% solution.

The truth is that to really be 100%, you have to read the users mind,
and we (sadly) can't do that.

Non-trival differences in behavior based on (interactive-p) are
something that make me nervous.

For example, someone has a bunch of (global-set-key ...) forms in his
.emacs file, and notices some binding isn't as he wants it, so he does
`eval-region' on them.  Or he has a hook set up some bindings.  In both
cases, if they're shadowed by customize bindings, they act as if they
don't exist, no matter how many times he evaluates them.

On the other hand, the case that you cite is that when a package is
loaded, it shouldn't override a customized binding (though I expect
there are some occasions that users will think it should), and that if
the user undoes his customization, he should get the last-executed
`traditional' binding.


If I can try to restate what you said, it seems to be:

   [a] customize-bindings override traditional bindings (with
       interactive uses of `global-set-key' granted honorary customize
       status)
        
   [b] traditional (define-key, etc) bindings provide the value for
       `restore default' in customize

(and within each category, `customize' and `traditional', the most
recent definition always supersedes previous ones)


What seem better to me is this:

   [a] _user_ bindings override non-user bindings

   [b] non-user bindings provide the value for `restore default'

(with the same time-ordering within each category)

Where `user' is fuzzily defined to be `something the user did, not a package.'

So is there a definition of `user' that's easy to implement?  I'm not
sure, maybe something like `not defined while loading a file'.  That
would catch customize, M-x global-set-key, M-: (global-set-key ...),
hooks, eval-region, etc.  It would also mean that bindings established
in .emacs are `non-user' which may be good or bad, but maybe it could be
made be an exception to the loading-files test.

Note that this sort of test could be done entirely within `define-key',
and wouldn't have to distinguish between customization and other uses.

It's possible to implement this either as a nested set of keymaps (like
you use), where the decision whether to use a `user' or `default'
binding is made at key-lookup time, or to simply stash the default
bindings in a different keymap for use by customize and also put them in
the real keymap when appropriate.


Another question is `if there the implementation uses two keymaps
(either for nesting at lookup time, or just for bookkeeping purposes),
where is the second one stored?'  I really dislike your idea of having
two separate lisp variable to store them.  It oughtn't even be necessary
to know the name of a keymap to find its associated `2nd keymap',
especially when more than just customize is looking at them.

Is it possible to stash the `2nd keymap' within the primary keymap
directly?  Alternatively, there could be a global alist mapping primary
keymaps (note, _not_ variable names) to 2ndary keymaps.

-Miles