Clojure mode doesn't honour (or maybe tramples on) input-decode-map

[sw1nn]

If I runs emacs in a terminal with windmove and it's default bindings. I can navigate between windows using various combinations of Shift + → ← ↑ ↓, Also paredit has bindings that involve Ctrl/Meta + → ← ↑ ↓,

This functionality relies on emacs decoding terminal escape sequences, via (I think) the input-decode-map

However, if I set the major mode as clojure-mode then the decoding of the escape sequences appears to be disabled (or overwritten).

It seems that clojure-mode is doing something undesirable to the input-decode-map

[technomancy]

There's no mention of input-decode-map in clojure-mode. I'm actually unable to use shift+arrow combinations in a terminal at all regardless of major-mode, so I'm afraid I can't reproduce this problem.

[sw1nn]

I appreciate that there are a lot of moving parts here. FWIW, I suspect that clojure-mode is not doing something that (say) emac-lisp-mode does do, I found terminal-init-xterm in xterm.el that seems to do something appropriate.

If it helps anyone who knows more than me replicate, I'm running iterm2 on OSX Mountain Lion with a profile that has the key bindings set via Profiles->Open-Profiles->Edit Profiles->Keys tab->Load Preset->xterm Defaults

I have TERM set to xterm-256color on the remote server.

[sw1nn]

I've reproduced the same issue on linux, using st (v0.5) from suckless.org. I have to add some terminal control sequences to get arrow bindings working in elisp-mode and they all work fine there, but they still do not work in clojure-mode specifically.

[sw1nn]

Finally tracked it down to a key binding to M-[ in my clojure-mode setup, something like....

(define-key clojure-mode-map (kbd "M-[") 'paredit-wrap-square)

This was a spectacularly bad idea on my part - since most terminal control sequence start with ESC [ this causes great confusion.

Closing the issue, but clojure-mode should avoid adding that binding in the future if terminal control sequences are going to work.