Какая настройка по умолчанию делает Vim очень медленным на экране Mac? - PullRequest
3 голосов
/ 24 мая 2009

Проблема не решена, хотя я принял один ответ.

Проблема: Vim очень медленно обновляет экран в Screen в Mac, хотя lazyredraw и showcmd отключены .


Номера строк попадают в foldColumn, как показано ниже, например, когда у меня есть номера строк альтернативный текст http://dl.getdropbox.com/u/175564/vimScreenFold.png

Когда в моем .vimrc ничего нет, проблему можно увидеть по умноженным строкам комментариев друг на друга: альтернативный текст http://dl.getdropbox.com/u/175564/vimScatteredBug.png

Я не набирал следующий комментарий более одного раза слева

"set list...

Наблюдения

  1. , кажется, встречается только в строках комментариев и пустых строках . Тем не менее, я получил доказательства (2) , которые показывают, что это не так.
  2. разброс происходит в основном в левом окне. Они происходят также с одним окном. Однако с ним труднее обнаружить.
  3. Ошибка возникает немного по-другому, когда у меня ничего нет в .vimrc. Однако «застой» происходит в обеих ситуациях: с пустым .vimrc и с непустым .vimrc.

Идентификация ошибки

Зависимые переменные

  1. зависит от знаков комментариев, автоматически выставляемых Vim . Я заметил исчезнувшие пиксели, когда Vim автоматически добавил знаки комментария Python # в мои файлы, когда он не мог показать весь файл.
  2. зависит от как минимум OS / X Leopard.

Независимые переменные

  1. не зависит от файла : встречается во всех файлах, отредактированных Vim
  2. независимая от строки : встречается в коде Python без комментариев и пустых строк
  3. .vimrc независимо : происходит с пустым .vimrc
  4. .screenrc независимо : происходит с пустым .screenrc
  5. независимый от оболочки : происходит с Bash и Zsh
  6. Не зависит от версии экрана : происходит со стандартным экраном Leopard и с экраном 4.0.3
  7. независимо от различных символов комментария : происходит при прокрутке вниз, например, .zshrc, .vimrc и .screenrc

Как отключить настройки Vim по умолчанию ?

Ответы [ 8 ]

3 голосов
/ 25 мая 2009

Я предполагаю, что проблема может быть связана с вашими настройками termcap и terminfo. Попробуйте закомментировать их со своего экрана и перезапустить экран.

Кроме того, какой (не виртуальный) терминал вы используете?

Ах, выглядит как будто вы используете OSX Terminal.app, который я и использую (с screen/zsh/vim). /usr/bin/screen должно работать с /usr/bin/vim с пустыми .screenrc и .vimrc по умолчанию.

% touch empty_screenrc
% cat empty_screerc
% /usr/bin/screen -c empty_screenrc
#...and within screen
% /usr/bin/vim -u NONE

Если проблема не устранена, возможно, проблема в вашей оболочке. Но если это решит проблему, я бы предложил опубликовать ваш ~/.vimrc, чтобы помочь в дальнейшей диагностике.

2 голосов
/ 21 января 2011

У меня была эта проблема (просто мучительно медленная), и она оказалась шрифтом Consolas, который я использовал в Terminal.App и ITerm. В моем случае переход на Монако значительно ускорился.

2 голосов
/ 30 мая 2009

Я думаю, что версия экрана OS X по умолчанию не поддерживает 256 цветов. Вы можете настроить vim на использование меньшего количества цветов в вашем файле .vimrc:

set t_Co=16

В Mac OS X вы можете восстановить экран, чтобы использовать 256 цветов, см. Здесь: http://pjkh.com/articles/2008/07/09/osx-iterm-screen-vim-256-colors.

Вот краткая версия инструкции:

Перестройте экран, включив опцию 256 цветов:

./configure --enable-colors256

Затем вам нужно добавить следующее в ~ / .screenrc:

# terminfo and termcap for nice 256 color terminal
# allow bold colors - necessary for some reason
attrcolor b ".I"
# tell screen how to set colors. AB = background, AF=foreground
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
# erase background with current bg color
defbce "on"

Источник

2 голосов
/ 27 мая 2009

У меня нет плагинов и ничего в .vimrc и .screenrc. Проблема все еще сохраняется.

Идентификация ошибки

  1. не зависит от файла : встречается во всех файлах, отредактированных Vim

«Застой», по-видимому, происходит в основном в строках комментариев и пустых строках. Тем не менее, ошибка возникает также без комментариев и пустых строк, но влияние этого кажется гораздо меньше.

Картинка для наблюдения 2 альтернативный текст http://dl.getdropbox.com/u/175564/cruxMoveInVimScattered.png

1 голос
/ 05 июля 2009

У меня были похожие проблемы с irssi и bash, которые были вызваны неправильной цветовой кодировкой ..

Вы пробовали другую тему vim (в частности, тему по умолчанию) или работали :syntax off?

1 голос
/ 02 июня 2009

Похоже, что есть некоторые известные проблемы, связанные с режимом переноса для OS X, см. Номер 1. здесь . Это предлагает обходной путь.

1 голос
/ 30 мая 2009

Ключевой ход: ошибка возникает из-за того, что некоторые опции Vim по умолчанию вызывают проблему

Сейчас я использую свои стандартные конфигурации в .vimrc и .screenrc, так как я заметил, что они не вызывают ошибку.

Ошибка, похоже, незначительная комментарий и пустая строка зависит . У меня есть доказательства этого.

У меня нет комментариев и пустых строк в моем коде Python. Тем не менее, я заметил, что когда Vim не может показывать полные строки, он ставит комментарии к моему коду. Например, отметьте три # -марки, которые Vim поставил там.

Это вызвало исчезновение пикселя.

альтернативный текст http://dl.getdropbox.com/u/175564/pythonBug.png


Ошибка возникает в том же файле, когда я не вижу знаки комментария, автоматически выставленные Vim.

альтернативный текст http://dl.getdropbox.com/u/175564/counterExample.png

Я специально продублировал код картинки, чтобы вы могли четко видеть исчезнувшие пиксели.

Однажды, когда я играл с кодом Python, я заметил, что «застой» произошел очень сильно после того, как я поместил в код одну пустую строку. Однако мне не удалось продублировать событие.


Неудачные попытки исправить ошибку с помощью .vimrc

  1. для отключения комментариев, автоматически устанавливаемых Vim

    набор форматирования- = с

0 голосов
/ 12 июня 2009

Debugging:

Один предложил мне заморозить свой терминал от изменений других приложений на

ttyctl -f

Однако, похоже, это не решило проблему. Тем не менее, это может помочь нам найти ошибку, поскольку у нас нет других приложений, которые сейчас меняют ситуацию.

...