C-h f keyboard-translate
RET says that:
This variable has a separate binding for each terminal. See Info node
`(elisp)Multiple displays'.
which points us in the right direction, although there's an error in that documentation, as the referenced info node doesn't exist. A search suggests that the node is actually renamed (elisp)Multiple terminals
, which you can also read here: http://www.gnu.org/s/emacs/manual/html_node/elisp/Multiple-Terminals.html
On GNU and Unix systems, each X display is a separate graphical terminal [...] Emacs can even connect to other text-only terminals, by interacting with the emacsclient program.
So when you start emacs as a daemon, you have not yet connected to a terminal (or at least, not to one that is useful to you), and so your commands do not generate bindings for the terminal(s) that you end up using.
The after-make-frame-functions
variable provides one way to resolve this.
(defun my-dvorak-translations (&optional frame)
"Re-map keys in the current terminal."
(with-selected-frame (or frame (selected-frame))
(keyboard-translate ?\C-j ?\C-c)
(keyboard-translate ?\C-c ?\C-j)))
;; Evaluate both now (for non-daemon emacs) and upon frame creation
;; (for new terminals via emacsclient).
(my-dvorak-translations)
(add-hook 'after-make-frame-functions 'my-dvorak-translations)
Experimentally it appears safe to repeat your commands, so we don't need to worry about only executing this once per terminal (but if we did, we could use (get-device-terminal FRAME)
to help with that).
after-make-frame-functions
was auto-selecting the frame back then or not, but it certainly hasn't done so anytime recently... I was a bit startled to find this old answer and notice my bug. Glad to see you'd added this correction. – Fallal