Мне нравится визуально разграничивать исходный код длинными строками комментариев: в C++ я использую 80 /
символов, в Python я использую 80 #
символов и т. д. За эти годы я заметил, что Vim иногда подтормаживает (перестает отвечать примерно на полсекунды или около того), когда я перемещаюсь; сегодня я обнаружил, что это происходит только со строками-разделителями.
Например:
line 1
line 2
////////////////////////////////////////////////////////////////////////////////
line 4
line 5
Когда курсор находится в любой точке строки 3, любое движение (вверх, вниз, на страницу вверх, на страницу вниз, влево, вправо, $
, 0
, ...) почти всегда приводит к задержке; на других строках ее нет.
Экспериментируя с этим, я обнаружил:
- Задержка, по-видимому, возникает в строках, содержащих в общей сложности 40 или более символов (
/
,-
,=
,.
,#
и т. д.), в любом месте строки, не включая_
(возможно, потому, что подчеркивание включено в определение Vim для aword
). - Задержка, похоже, не увеличивается для более длинных строк. Например, строки из 1000
/
символов имеют такую же задержку, как и строки из 40/
символов. - Задержка происходит только при начале "нового" движения с этой строки. Использование повтора клавиши OS для перемещения по строке не добавляет задержки.
- Задержка, по-видимому, не связана с подсветкой синтаксиса или плагинами: я наблюдаю такое же поведение с
vim -u NONE
,syntax off
, иfiletype=
. - В графическом интерфейсе Vim (gvim) такой проблемы, похоже, нет.
Я использую MacVim 8.0 от macports в приложении «Терминал» на MacBook Pro, но предустановленный Apple Vim 7.4 ведет себя так же.
Мне не удалось найти никаких упоминаний об этом в Google, Stack Overflow или Super User, но это вполне воспроизводимо в моей системе.
Это известная проблема? Есть ли настройка времени выполнения или опция сборки, которая контролирует это (максимальное количество поддерживаемых символов в строке или что-то еще), или обходной путь, который ее устраняет?