writing lisp emacs key binding and cannot specify the <delete> character

For some reason I got the default M-del key binding for backward-kill-word mapped to a scan for matching brackets and resetting is not working, so I am trying to set the global key binding in lisp. So I wrote in ~/.emacs.d/init.el the lisp commands:

(global-set-key (kbd "M-h") 'backward-kill-word)

(glob开发者_开发百科al-set-key (kbd "M-<\delete>") ‘backward-kill-word)

I tried them with C-x C-e and they both give the 'backward-kill-word output but only the first key-binding works "M-h", the other is ignored and M-del still trying the strange scanning action. The delete key works in emacs elsewhere, so it seems like "delete" is not being mapped to the physical key in lisp (and the backslash is there to show in this text only as the word was being commented out). Any idea what keyword to use or special character? Best.

(I looked for libraries that may have overrided this command but I cannot find them)

On some systems, the delete key is defined as an alias to C-d. This is done through function-key-map on GNU Emacs <23 and local-function-key-map on GNU Emacs 23. (I've observed this behavior on Debian and Ubuntu 10.04 under X.) The purpose of such translations is to isolate people who code modes from the terminal intricacies: a mode that wants to shadow the delete command only needs to rebind C-d and not wonder if it should rebind delete (is that a delete left or delete right?) or deletechar or something else.

If there is a global or local binding for delete, it shadows this translation to C-d. However, if you press ESC delete, if there is no global or local binding for ESC delete, the second key is translated to C-d. This translation has precedence over the interpretation of ESC delete as M-delete. So ESC delete becomes equivalent to C-M-d.

This is arguably a bug in Emacs: the effect of ESC delete should be the same as M-delete, and there is no reason why ESC delete would run down-list which has nothing to do with deletion.

There are several possible fixes; I don't know which is best. One that should work with any version of Emacs is

(global-set-key [?\e delete] 'backward-kill-word)

The really nice thing about kbd is that what you type there is the same string that Emacs displays. So, try the following

C-h k M-<\delete>       (to use your syntax)

or

M-x describe-key M-<\delete>

Emacs (for me) responds with:

M-DEL (translated from <M-delete>) runs the command backward-kill-word, which is an interactive compiled Lisp function in `simple.el'.

It is bound to , M-DEL.

(backward-kill-word arg)

....

Which you can see shows that the representation for the key you want is M-DEL or M-delete.

Which is a long way of getting to the point that what you want is

(global-set-key (kbd "M-delete") 'backward-kill-word)

Of course, if you have something in your .emacs that overrides it, the above won't help. You'll need to find that included library and stop using it (or customize its behavior).

You might want to call global-set-key interactively to see how it interprets meta-delete. Also try local-set-key to ensure the strange binding is not mode-specific.

After not being able to find the library holding the conflict I found this webpage http://www.cs.cmu.edu/cgi-bin/info2www?%28emacs%29Rebinding

Changing Key Bindings Interactively...

`M-x global-set-key KEY CMD ' Define KEY globally to run CMD....

Normally, C-z' is bound to the function suspend-emacs' (when not using the X Window System), but you can change C-z' to invoke an interactive subshell within Emacs, by binding it toshell' as follows:

 M-x global-set-key <RET> C-z shell <RET>

`global-set-key' reads the command name after the key. After you press the key, a message like this appears so that you can confirm that you are binding the key you want:

 Set key C-z to command:...

And now the standard default is returned to by doing

M-x global-set-key M-del ...

backward-kill-word But this is transient and must be done on each reload, any way to make this permanent? Putting a command into the init.el is not overriding the other effect