Tim Chase wrote: > On 03/22/12 07:18, Constantin Stefanov wrote: >> >> Tim Chase wrote: >>> On 03/22/12 06:42, Constantin Stefanov wrote: >>>> Nothing changed, Esc then up arrow gives strange results. >>> >>> Is this in vim or gvim? >>> >>> I suspect it's (non-g)vim and it's receiving an ANSI escape >>> sequence for the arrow keys. So you'll need to tweak the >>> 'timeoutlen' setting to be more than the time it takes you to hit >>> <esc><esc>, but less than the time it takes you to hit<esc><arrow>. >> Yes, it is vim, not gvim. I know about timeoutlen, but I hoped that >> there is better soultion. > > the problem is that in the <esc><left> sequence, terminal Vim > sees "<esc><esc>[D", so the "<esc><esc>" mapping gets triggered > with the side-effect of issuing "[D" (a backwards jump and then a > delete-the-rest-of-the-line). So to distinguish them, you need > to tell how much time goes between the "<esc><esc>" and the > "<esc><left>" which is done via 'timeoutlen'. I'd just reach for > another key rather than messing with <esc><esc>. > > Personally, I tend to add the functionality to control+L which > does a refresh anyways: > > :nnoremap <C-L> :noh<cr><C-L> I know why that happens, and have another key (I use Esc Tab), but Esc Esc (and more than that, single Esc) seems better.
I tried to use some tricks with getchar, which can chow, is there something more in input buffer, but it seems that if I return single Esc from map, and take something alese from input, it will not be treated as Esc sequence. -- Constantin Stefanov -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
