RE: customizing key definitions with Customize

[Drew Adams]

>     handle it as I suggested: customize an option. A keymap-valued
>     symbol is just a variable. Either such a variable could itself
>     be made a user option or, as I showed, a separate but
>     corresponding user option can be created.  Both approaches can
>     be treated the same way (e.g. as I indicated); it depends on
>     what we want.
> 
>     If we want a given keymap variable itself to be completely
>     customizable (i.e., for all of its keys), then we can just
>     make it a defcustom of the sort I indicated. If we want some
>     keymap variables not to be options, then we need not
>     use defcustom for them.
> 
> Now it seems you are saying that the _code_ should choose whether the
> user should see the entire keymap or just his changes.

Don't know what you mean by that. What I meant was that it could be useful for
code (e.g. a library, built-in or 3rd-party) to decide whether and how much of a
given keymap should be customizable, by default. I'm talking possibilities, not
"should".

I can see some use value in not always presenting a user, by default, with a
complete keymap to customize. That's all. That doesn't mean we couldn't also
provide a way for a user to go ahead and customize the whole keymap. I'm
thinking of user convenience and possible confusion.

> We were already aware of that possibility, but it has an obvious
> drawback.  That is why I suggested that we instead let the _user_
> choose one or the other, for each keymap.

I'm not sure we're saying something different. Nothing would prevent a user from
customizing a complete keymap. But a library might want to (also) give users a
lite keymap option that only shows some of the keys in a map.

Anyway, in the approach I outlined, the flexibility is there to do both.