I cannot use Ctrl+= (CTRL and equal sign) in terminal mode emacs. All what I have is only '=' typing instead of keybindings execution. At least Terminal.app does not have such behaviour (but I don't like it for other reasons), so this obviously isn't the terminal mode emacs problem. Is it possible to fix this? May be this is some configuration issues (plist-file attached)?
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Related to this, using Emacs on a terminal doesn't seem to work properly for me. C-n and C-p work, but eg C-x or C-c or C-g don't register (and sometimes hang Emacs).
There is no standard key mapping for C-= in a terminal. Terminal swallows it while we send an =, but neither is what you want. You could bind C-= to another keystroke.
(Use the Send Escape Sequence action on a keybinding, with a "characters to send" value of [97;6~, or whatever is appropriate for your keystroke).
As for getting Emacs to understand this keystroke, I'm not an emacs user, but I'm sure it's possible :)
I'm not sure why C-x C-c or C-g have issues; I suggest running cat and ensuring they send the right thing in general. Does Emacs in Terminal have the same issue with those keys?
@gnachman I've tried testing the codes sent using sed -e l, and in current stable iTerm 2 (when typing C-x C-x C-c):
~ >> sed -e l^X^X^C
and in the beta iTerm 2 3:
~ >> sed -e l^X^C
So it seems like the new iTerm is swallowing the first C-x call. This is consistent with other keyboard shortcuts (eg C-x C-f - the output is ^F only).
I can confirm that Terminal.app and iTerm2 2.1.4 both behave as expected (and display the full key combination, and therefore send it on to Emacs).
Looks like you have a keybinding defined in $HOME/Library/KeyBindings/DefaultKeyBinding.dict that affects ^X. I wonder if we're handling it incorrectly; would you mind sharing your key binding file?
It looks like Terminal no longer supports DefaultKeyBindings.dict.
We support it only for insertText: entries, which you happen to have none of. I would like to continue to support it since many users use it. But it seems like an anti-feature to swallow your input when it cannot possibly lead to us doing anything. So commit f888a5e6 prunes out branches from the tree of keybindings that do not lead to insertText: being called. The effect for you will be that all input gets passed through.
If you have a key binding like this:
{ "^x" = { "g" = ("insertText:", "george"); };}
Then any keypress of ctrl-x will get dropped. If it's not followed by a g then it will do nothing. If it is followed by a g then george will be inserted. That is consistent with how key bindings are handled by default (e.g., in TextEdit).
@gnachman I've added a custom keybinding for ^= (C-=) to Do Not Remap Modifiers in iTerm2, now it stopped writing = when I press it, but it seems to just ignore the key now, e.g. Emacs launched in terminal doesn't seem to receive anything.
I've launched echo keys in emacs launched with emacs -nw, and pressed C-1 through C-= on my keyboard, results were:
1C-@C-M-\C-]C-^C-_DEL90C-_
So now I'm confused even more with what's being sent upon those combinations. Sorry if I misunderstood your previous comment regarding what I should do, I see it did a rebinding of F-keys and I didn't understand how that is related to my problem.
UPDATE: totally forgot, I'm pressing "caps lock", not "control", since it is binded to be Control in my iTerm2. Capslock gives different codes in "echo key press" of emacs, but still no signal upon C-=.
Since there is no binding for C-= you have to assign it a keystroke that emacs will understand, such as F13. That's what the link I sent above suggests doing. The control+number combos have pretty random and haphazard bindings as you've seen.
@gnachman ah, I see now, thank you. It was a bit confusing since it's probably easier to assign it to something within the regular keys (C-\ maybe, I'll have to experiment), since pressing F-buttons needs me to also press Fn on my keyboard.