RE: customizing key definitions with Customize

["Drew Adams" <drew.adams@oracle.com>]

>     Command `custom-create-keymap-option' creates a user 
>     option of the same = name as
>     its keymap argument, but with `-defs' appended. E.g.,
> 
>      M-x custom-create-keymap-option RET bookmark-map
> 
> We should not ask _users_ to type any commands to make a map
> customizable.

"Should", "should". This thread started with my mail about libraries
(programmers) using defcustom to provide users the ability to customize some key
bindings. It would typically be libraries, not users, that would create
customizable keymaps (i.e. options). But please don't get hung up on where or
when the option is created. The first item to discuss is the means of
customizing - how it works in Lisp and what the user experiences in Customize.

There are lots of possibilities along the lines of the topic raised, including
complete customization of a keymap or of all keymaps, and automatic defcustoms
(or defkeymaps or whatever) for all keymaps. Let's keep the discussion open for
the moment, without immediately nailing down what "should" be done.

> Rather, all the keymaps that Emacs knows about should
> be known to Custom as well.  So anything that has to be done in order
> to make a keymap known to Custom should be done in the Lisp code.

Should be _doable_ in Lisp code. It's not a foregone conclusion that we want
users to use Customize on all keymaps. But Lisp should be able to make any
keymap customizable.

> It would make sense to have a command `customize-keymap' as a user
> interface for running Custom to customize one particular keymap.

Yes. In the approach I suggested, that is just `customize-option'. I hope you
will at least try the code.

> But we also should be able to include keymaps in custom groups.

Keymaps or keymap-valued variables? That's one question. The approach I outlined
was to use the latter. And being normal defcustoms, they can of course be
included in groups.

>     Unlike faces, keymaps, apart from keymap-valued variables, do not
>     have names, so the approach I suggested makes sense: customize
>     keymap variables, not "first-class" keymap objects.
> 
> If that works out conveniently, I am not against it.
> 
> It would be nice if the macros for defining major modes
> were connected to this, so that all the keymaps were
> customizable.

I agree. But we might (might) want to be able to specify some keymaps, or some
parts of some keymaps, as not customizable - or at least not make it immediate
and easy to customize them.