emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: customizing key definitions with Customize


From: Drew Adams
Subject: RE: customizing key definitions with Customize
Date: Sat, 17 May 2008 18:22:23 -0700

> New keymap-option.el attached - please try it out.
> 
> 1. In the implementation I sent previously, the :set function
> only did `define-key' for the key definitions (after the user
> was done editing them and chose `Set for Session'). That meant
> that no previously existing key bindings were removed or changed,
> even if the user changed a `Key' value or clicked DEL
> to delete the key definition from the option. Only new 
> bindings were made.
> 
> 2. To remedy that, the :set function needs to first remove 
> all existing key bindings, so the only bindings will be those
> the user has kept. I've done that now, in the attached version.
> The :set code now calls `makunbound' and then sets
> the keymap variable to (make-sparse-keymap) before it defines 
> the keys per the user's customizations.

That doesn't really do the trick, unfortunately.

The keymap itself, not just the keymap variable, needs to be reinitialized and
then filled with the new bindings, because the keymap might already have been
used as part of other keymaps.

In the :set function I had, I've thus replaced (makunbound ',map) and (setq ,map
(make-sparse-keymap)) with (when (keymapp ,map) (setcdr ,map nil)). That seems
to fix that problem, but there are other problems, listed below. The updated
code is attached.

1. Non-sparse keymaps, such as `global-map', can end up with some of their keys
undefined after customization.

I cobbled together some code that processes key ranges such as "SPC .. ~", in
particular to handle the multiple bindings of things like `self-insert-command'
in non-sparse keymaps. The attached code raises an error for a non-sparse
keymap, but you can comment out the two lines that raise the error (marked "<===
1"), to try it.

2. However, some maps, such as `global-map', can still end up with some of their
keys undefined. You won't want to try `global-map' with error handling #1 turned
off. If you want to experiment with `global-map', comment out the line marked
"<=== 2".

I'm not sure why some key definitions are not reinstated as they should be.
Perhaps it has to do with the order of processing the key definitions (e.g. wrt
prefix keys).

3. The approach I've used of relying on the output of `substitute-command-keys'
does not work completely for menu maps, because it loses the other information
besides the real binding (e.g. command). For instance, if this is a menu item:

(search-documentation
  menu-item "Search Documentation"
  (keymap
    (emacs-terminology
      menu-item "Emacs Terminology" search-emacs-glossary (nil)
      :help "Display the Glossary section of the Emacs manual")
     ...))
 
Then the :set function changes that to just this:

(search-documentation 
  keymap (emacs-terminology . search-emacs-glossary))

So this is another reason why we should work directly from the keymap, using,
say, `map-keymap', and not try to use the output of `substitute-command-keys'.

To deal with menus generally, we would need to extend the definion of
`key-definition' to accommodate not only the binding (command) but also the
other stuff that menu bindings include. A less satisfying alternative would be
to just forego being able to customize menu keymaps. The attached code just
raises an error if you try to create an option for a menu keymap.

4. There still is an `edmacro-parse-keys' bug that prevents some keys from being
handled correctly. With the attached code, the only such key in the global map
is, I think, "M-<" - see the separate bug report. Someone more knowledgeable
will need to fix `edmacro-parse-keys' the right way.

I won't be going any further with this, but I hope someone will. I spent more
time on it than I wished, but I hope that some of what I explored might help
someone else do things right. I've added some comments in the code, in case it
helps.

There hasn't been much interest expressed, but I think this would be a good
feature if done right. Users can customize the rest of Emacs, besides key
bindings, and bindings can be fairly complex to work with. Besides letting users
customize bindings generally, such a feature can be used by a library to control
(e.g. encourage/discourage) which bindings users customize (with Customize).

HTH.

Attachment: keymap-option.el
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]