Dlaczego to mapowanie trybu normalnego <Esc> wpływa na uruchamianie?

Mam dziwny problem z mapowaniem trybu normalnego Esc.

Jeśli utworzysz plik escmapvimrcz zawartością:

set nocompatible
set showcmd " Doesn't affect the problem: just makes it easier to see
nnoremap <Esc> :noh<CR><esc>

A następnie uruchom vim za pomocą tego vimrc:

vim --noplugin -u escmapvimrc

Następnie vim uruchomi się w trybie oczekiwania operatora z cpoleceniem oczekującym na dalsze wprowadzanie, wyświetlaniem pustego pliku i wyświetlaniem wiersza poleceń :noh.

Jeśli usuniesz nnoremaplinię, problem zniknie.

Jeśli debugujesz i przejdziesz przez wszystko, otrzymasz następujące dane wyjściowe:

Entering Debug mode.  Type "cont" to continue.
/[...]/escmapvimrc
line 1: set nocompatible
>s
/[...]/escmapvimrc
line 2: set showcmd " Doesn't affect the problem: just makes it easier to see
>s
/[...]/escmapvimrc
line 3: nnoremap <Esc> :noh<CR><esc>
>s
/[...]/escmapvimrc
line 4: End of sourced file
>s
Press ENTER or type command to continue

Po wciśnięciu enter wyświetli się ekran startowy Vima, a pod nim:

Entering Debug mode.  Type "cont" to continue.
cmd: noh
>s

Ekran startowy Vima znika, a ty jesteś w trybie oczekiwania operatora, jak opisano powyżej.

Co się dzieje?

EDYCJA: Zachowanie jest takie, jak opisano w Vim 7.3. W Vimie 7.4.52 nmappowoduje , że Vim uruchamia się w trybie Zastąpienia podczas uruchamiania Vima bez pliku. (Jeśli Vim 7.4.52 jest uruchamiany z plikiem, uruchamia się również z trwającym poleceniem c). Tak czy inaczej, problem zniknie po usunięciu nmap.

Podczas uruchamiania Vim wysyła specjalne kody terminali (które zwykle zawierają <esc>klucz), aby określić kilka rzeczy (kolory, bs, ...). Jeśli to zmapujesz <esc>, najprawdopodobniej pomylisz parser kodów powrotu i mogą się zdarzyć dziwne rzeczy.

Dlatego używaj powyższej mapy tylko po prawidłowym skonfigurowaniu wszystkich elementów (np. Za pomocą komendy automatycznej VimEnter).

Terminal Linux wykorzystuje sekwencje specjalne ANSI (tj. Ciągi znaków rozpoczynające się od <Esc>) do wysyłania specjalnych kluczy do Vima oraz jako część protokołu komunikacyjnego, z którym aplikacja pyta o swoje możliwości. Twoje mapowanie zakłóca to, a tym samym prowadzi do tych „dziwnych” zachowań.

Dlatego nie mapuj<Esc> . Użyj innego klucza. Problem jest mniej wyraźny w GVIM, ale nie poleciłbym go też tam.

Spróbuj tego:

augroup escape_mapping
  autocmd TermResponse * nnoremap <Esc> :noh<CR><esc>
augroup end

por. /programming//a/16027716/400545

Próbowałem skonfigurować automatyczne polecenie, aby ustawić mapowanie później podczas uruchamiania, ale problem nadal występował. ^*

W końcu utworzyłem komendę automatyczną, która pojawi się przy pierwszym wejściu w tryb wstawiania. To oczywiście nie jest idealne rozwiązanie, ale dla mnie będzie działać przez większość czasu i wydaje się, że najlepiej, co mogę zrobić:

AKTUALIZACJA : Po kilku latach używania dłuższej wersji bez problemu zdecydowałem, że jest ona nieco przerobiona i od tego czasu korzystam z tej znacznie prostszej wersji, która zamiast tego resetuje mapowanie za każdym razem, gdy wchodzisz w tryb wstawiania:

augroup escape_mapping
  autocmd!
  autocmd InsertEnter * call s:setupEscapeMap()
augroup END

function! s:setupEscapeMap()
  nnoremap <Esc> :noh<CR><Esc>
endfunction

Mapowanie nie musi być resetowane za każdym razem, gdy wchodzisz w tryb wstawiania, ale nie wyrządza to żadnej szkody Vimowi.

WERSJA ORYGINALNA :

if !exists('g:escape_mapped')  " Only need to set the mapping up once.
  augroup escape_mapping
    autocmd!
    " Create the autocommand, to fire when Insert mode is entered
    autocmd InsertEnter * call s:setupEscapeMap()
  augroup END
endif

function! s:setupEscapeMap()
  " Actually create the mapping
  nnoremap <Esc> :noh<CR><Esc> 

  " Now the map exists, so we won't ever need the autocommand again.
  let g:escape_mapped = 1

  " Tidy up the autocommand and group
  autocmd! escape_mapping InsertEnter *
  augroup! escape_mapping
endfunction

^{* Próbowałem dołączając je do różnych wydarzeń: VimEnter, BufReadPost, BufWinEnter, a nawet CursorMoved(!), Ale wszystkie one wydają się ognia zbyt wcześnie.}