5

Everyone once in a while in insert mode in Vim, I'd be happily typing along, when all of a sudden I'd be thrown out of insert mode and my last edit undone after hitting a certain key combination.

Today I realized that the mysterious combination was Shift+Enter. Sure enough, hitting Shift+Enter runs undo, regardless of being in insert mode.

I then tried doing Ctrl+VShift+Enter to see what the literal value of Shift+Enter was, and it printed out:

^[[13;2u

And now it made sense - ^[ is escape, and the u at the end is undo. The other characters don't do anything when typed in this order.

It appears to be a control code of some kind, but I can't seem to find the right thing to search for to know what this means.

Does anyone know what this control code means, and whether it is possible to disable it in Vim? I'm assuming my terminal might have something to do with it – I'm using Cygwin's stock terminal to ssh into a Linux box and running ssh over that.

1 Answer 1

5

Without getting into the intricacies of terminal capabilities and escape codes, I will confirm what you have already discovered: The terminal is trying to provide a way to distinguish between a modified and unmodified enter key.

Edit: Correction, it appears that when Vim puts the Mintty terminal in a "raw" mode it sees Shift+Enter as a null byte and displays it as ^@ when you precede it with Control+v, but otherwise treats it as a newline anyway.

There are multiple ways to solve this problem. One is to use Cygwin's Mintty instead, which doesn't send anything unique with Shift+Enter. It has other advantages over the stock terminal as well.

However, a "quick and dirty" solution is to just add something like this to your ~/.vimrc on the remote machine:

:imap <esc>[13;2u <CR>

The drawback to this is that from that point forward every time you press escape it will not leave insert mode until you start using movement commands or the map timeout interval expires. See ":help 'timeout'" and the following related entries.

The other solution may not be feasible (and might not actually solve the problem), but it is to make sure your TERM variable is properly set on your Cygwin shell before you ssh, and on the remote shell after you ssh, and that they match, or they are are sufficiently similar. (You should never, ever have an unconditional TERM=<anything> setting in your shell configuration files.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .