1

I'm overhauling all of my keybinds and I'm trying to keep it logically consistent.

When I issue the command describe-key -> RET
This pops up in the *Help* buffer:

RET (translated from <return>) runs the command newline (found in global-map),
which is an interactive compiled Lisp function in ‘simple.el’.

It is bound to RET.

(newline &optional ARG INTERACTIVE)

What I don't like about this is the fact that RET is translated from < return >.
This is also the case with DEL -> < backspace >, M-DEL -> < M-backspace >, etc.

So to get rid of said indirections I issue the command:
(define-key function-key-map (kbd "<return>") 'nil)

And thus bind RET to newline:
(define-key global-map (kbd "RET") 'newline)

But then I get this error in the minibuffer when pressing the RET key:
<return> is undefined

How do I get rid of this behavior?

I tried reading the documentation on map translations, but it is very confusing to me. Perhaps I haven't had that AHA moment.

  • Just curious: Why do you want to get rid of such indirection? If a keymap you use (such as a minibuffer keymap, which you cite indirectly) creates such an indirection. Is this perhaps an X Y question? What is it that you are really trying to do? – Drew Aug 28 '18 at 14:02
  • The reason I want to get rid of said indirections is twofold: 1) I want to eliminate every unnecessary layer of abstraction unless truly needed. 2) I want to keep my keybinds logically consistent; so instead of having keys bound to sporadic DEL and <backspace> arbitrarily, they will just be bound to DEL. – John DeBord Aug 28 '18 at 16:04
  • @Drew It looks to me that I'm gonna have to do some cons cell manipulation (correct me if I'm using that term wrong)? I'm looking at the variable function-key-map and I can see (backspace . [127]) 127 is the ASCII code for DEL. Could be a clue. – John DeBord Aug 28 '18 at 17:48
5

For clarity: "RET (translated from <return>)" tells you that Emacs is receiving <return>. That's what your OS sent it when you typed that key. You want Emacs to translate <return> to RET for you, because the standard key bindings are for RET, not <return>. Hence the error "<return> is undefined" after you removed that translation.

The reason for all this is that terminals send RET (which is ASCII code 13, aka C-m or ^M), whereas in a windowing/GUI system the return/enter key has its own distinct code <return> (which terminals don't know about, and can't send). Because Emacs supports both, it makes sense for the key bindings to be for RET.

Personally I recommend that you just leave things the way they are; but if you can't, then maybe something like this:

(define-key special-event-map (kbd "<return>") 'my-ret-event)

(defun my-ret-event ()
  "Push RET onto `unread-command-events'."
  (interactive)
  (push '(t . ?\C-m) unread-command-events))

Refer to C-hig (elisp)Special Events

Any key bindings which are actually using <return> then become inaccessible (that's probably an empty list, as such bindings wouldn't work in a terminal, but obviously it's still possible).

Experimentally, the various translation and decoding maps (although I didn't check every option) all seem cause Emacs to report the translation; but the special events are processed further behind the scenes.

n.b. I'm not convinced this is sensible, and for all I know it might cause problems in some situations.

Someone else may have a better method.

  • Great response and comment as well. I didn't know that it is actually the OS that sends <return> I spent a while trying to figure out where <return> was defined all for naught. But that now makes sense. – John DeBord Aug 29 '18 at 5:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.