2

Мне нравится визуально разграничивать исходный код длинными строками комментариев: в C++ я использую символы 80 / , в Python я использую символы 80 # и т.д. За прошедшие годы я заметил, что Vim иногда икает (перестает отвечать примерно на полсекунды или итак) когда я двигаюсь; сегодня я обнаружил, что это происходит только в моих разделительных линиях.

Например:

line 1
line 2
////////////////////////////////////////////////////////////////////////////////
line 4
line 5

Когда курсор находится где-нибудь в строке 3, любое движение (вверх, вниз, страница вверх, страница вниз, влево, вправо, $ , 0 , ...) почти всегда показывает задержку; на других линиях это не так.

Играя с этим, я нашел:

  • Кажется, что задержка происходит в строках, содержащих в общей сложности 40 или более символов (/ , - , = , . , # т.д.) В любом месте строки, не включая _ (возможно, потому, что подчеркивание включено в определение word Vim).
  • Задержка, кажется, не увеличивается для более длинных линий. Например, строки 1000 / символов имеют задержку, аналогичную 40 / символов.
  • Задержка происходит только при запуске "нового" движения с этой линии. Использование OS OS повтора для перемещения по линии не добавляет задержки.
  • Кажется, что задержка не связана с подсветкой синтаксиса или плагинами: я вижу такое же поведение с vim -u NONE , syntax off и filetype= .
  • GUI Vim (gvim), похоже, не имеет этой проблемы.

Я использую MacVim 8.0 из macports в приложении Terminal на MacBook Pro, но по умолчанию Vim 7.4, предоставляемый Apple, имеет такое же поведение.

Я не смог найти упоминаний об этом в Google, Stack Overflow или Super User, но это очень воспроизводимо в моей системе.

Это известная проблема? Существует ли параметр времени выполнения или параметр сборки, который управляет этим (максимальное количество поддерживаемых символов в строке или что-то в этом роде), или обходной путь, который облегчает это?

|источник

0