Re: Customizing key bindings

[Per Abrahamsen]

Miles Bader <address@hidden> writes:

> 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.

Only for bundled packages.  

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

Me too, but nobody protested when Stefan added such functionality to
define-minor-mode, so I presumed it was an acceptable solution.

> 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)

Yes.  I find this this simple and intuitive.

> So is there a definition of `user' that's easy to implement? 

I define "user" to be someone who use the interactive fascilities for
customizing Emacs, rather than the Lisp fascilities for the same.

> I'm not sure, maybe something like `not defined while loading a
> file'.

That may be more reliable, rather than, as now, gradually making
existing commands customize aware, as people think of them.

E.g. set-variable should probably really be customize aware when
called interactively.

> 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.

They should be "non-user", as we don't want customize to duplicate
these bindings on start-up.

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

Cool.

Do you want to propose the same for "setq" ;-)

> 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.

I probably shouldn't say this, but it will be simpler for XEmacs,
where keymaps are an opaque type.