나는 긴 주석 줄로 소스 코드를 시각적으로 구분하는 것을 좋아합니다. C++에서는 80 /자를 사용하고, Python에서는 80자를 사용합니다 #. 수년에 걸쳐 Vim이 가끔씩 딸꾹질을 하는 것을 보았습니다(약 0.5초 정도 응답이 멈춤). 내가 움직일 때; 오늘 나는 이것이 내 구분선에서만 발생한다는 것을 발견했습니다.
예를 들어:
line 1
line 2
////////////////////////////////////////////////////////////////////////////////
line 4
line 5
커서가 라인 3의 아무 곳에나 있으면 모든 이동(위, 아래, 페이지 위로, 페이지 아래로, 왼쪽, 오른쪽, $, 0, ...)은 거의 항상 지연을 나타냅니다. 다른 라인에서는 그렇지 않습니다.
이것을 가지고 놀면서 다음을 발견했습니다.
- 지연은 줄의 어디든 포함되지 않은 총 40개 이상의 기호(
/,-,=,.등 )가 있는 줄에서 발생하는 것으로 보입니다 (아마도 밑줄이 a 의 Vim 정의에 포함되어 있기 때문일 수 있음 ).#_word - 더 긴 회선에서는 지연이 증가하지 않는 것 같습니다. 예를 들어 1,000
/자로 구성된 줄은 40자로 구성된 줄과 비슷한 지연 시간을 갖습니다/. - 지연은 해당 라인에서 "새로운" 움직임을 시작할 때만 발생합니다. OS 키 반복을 사용하여 회선을 이동하면 지연이 추가되지 않습니다.
vim -u NONE지연은 구문 강조 또는 플러그인과 관련이 없는 것 같습니다. ,syntax off및 에서 동일한 동작을 볼 수 있습니다filetype=.- GUI Vim(gvim)에는 이 문제가 없는 것 같습니다.
MacBook Pro 터미널 앱의 macports에서 MacVim 8.0을 사용하고 있지만 Apple에서 제공하는 기본 Vim 7.4의 동작은 동일합니다.
Google, Stack Overflow 또는 Super User에서는 이에 대한 언급을 찾을 수 없지만 내 시스템에서는 매우 재현 가능합니다.
이것이 알려진 문제인가요? 이를 제어하는 런타임 설정 또는 빌드 옵션(한 줄에서 지원되는 최대 기호 등)이 있습니까, 아니면 이를 완화하는 해결 방법이 있습니까?