Ага, только я теперь не могу нормально сказать, что хочу видеть только запущенные vim, а не какой‐нибудь screen с -S vim-test. Писать шаблон, который с гарантией выберет только запущенные vim мне не хочется совершенно. Уж лучше я использую сокращения zsh чтобы сократить | grep в G: pps vim G foo. Или просто выберу глазами, гарантированно не получив в числе прочего вывода мусор с vim в аргументах или безумно длинные строчки (люблю открывать все файлы проекта сразу, всё равно vim реально их грузит в память только при необходимости) (ps обрезает строчки, если вывод осуществляется на терминал, pgrep нет).
В имени файла могут быть одинарные кавычки. Причём даже на Windows. Правится одной строчкой, но делать этого не надо: взаимодействие с Vim всегда весьма медленно. Поэтому надо не использовать цикл, а собрать всё в один большой список:
Не делайте так никогда. Есть VIM::Eval("expand('<sfile>:h')"), нужное именно для этого. Ни у меня, ни у огромного числа пользователей pathogen, vundle и vim-addon-manager нет ни малейшего желания помещать ваше дополнение в $HOME/.vim. Кроме того, зачем зря трудить Vim, чтобы он просматривал каталог plugin/cmake-project, в котором для него ничего нет, если можно отправить всё это дело в perl/cmakeproject.pm?
Знаю. Абсолютно бесполезная для меня вещь: во‐первых, мне не нужно и абсолютно не радует использование шаблонов (особенно, требующих по‐умолчанию только частичного совпадения). Во‐вторых, pgrep не пишет аргументы. Нафига мне знать, какие 15 PID соответствуют Vim, если завис и надо прибить только один? Аргументы, с которым я запустил зависший известны, но не номер pty (к тому же, часто не уникальный), не PID (зачем бы мне иначе ps -C?), не SID (что это вообще такое? впрочем не отвечайте, сам нашёл. Проблема та же, что и с терминалом) и не куча других неуникальных параметров.
Там есть поддержка OpenID, анонимные вопросы («user\d+» со слабо отличимым от нуля рейтингом — это они) и возможность связывать аккаунты на множестве сайтов в один (как правило, происходит автоматически). Stackexchange — это просто название проекта, в рамках которого развивается stackoverflow и ещё куча подобных сайтов на том же движке.
Нет, но это показатель того, насколько хорошо устроен редактор. У Vim отличный UI и множество дополнений, из‐за чего (особенно первого) я его и использую, но VimL и архитектура очень далеки от идеальных. Про VimL вы можете почитать мою статью, а архитектура — это общее впечатление от того, что вы
не видите C API, для улучшения интерфейсов с другими языками зачастую приходится экспортировать существующую static функцию или выделять существующий код в отдельную функцию. Единственная документация — комментарии и их далеко не всегда достаточно;
видите отсутствие нормального поддержки клавиатурных сочетаний. Обсуждениям на эту тему уже невесть сколько лет, но у Брама нет времени, а у остальных, видимо, пороха на такую задачу;
видите множество запросов вида «а как сделать подсветку строки там где нет символов/подсветить N’ю колонку» Второе уже решено, но если бы вместо :syn было внятное C API, используемое первой, и соответствующие функции на Python/…, то вопрос бы не требовал создания целой новой настройки;
видите до сих пор не исправленные неровности в скрытии символов вроде некрасивой табуляции, невозможности получить видимую позицию курсора, необходимости нажимать l/h столько раз, сколько символов сокрыто, …;
видите вопросы «а почему я не могу сделать nnoremap d smth, не получая задержку при вводе d»
, то у вас остаётся впечатление, что с архитектурой что‐то не то.
Собственно, VimL, система подсветки и система ввода — то, что нуждается в улучшениях, причём второе можно сделать без нарушения обратной совместимости, третье тоже (хотя если вы попросите меня это сделать или дождётесь пока сам созрею, то часть обратной совместимости будет намеренно нарушена, могу объяснить какая и почему). Вместо первого лучше иметь C API с доступом ко всем возможностям редактора и соответствующие интерфейсы: для того, чтобы всё использование VimL сводилось к чему‐то вроде
. Впрочем это не отменит того, что я считаю необходимым сделать VM для VimL, но это имеет мало смысла без потери малой части обратной совместимости: скажите, как Vim может воспринять вторую строку в следующем коде:
execute variable
nnoremap a b
? Я знаю как минимум три варианта. Если запретить незавершённые блоки :if/:for/:try/:while/:function и принудительно завершать :append/:insert по окончании :execute то всё сведётся к двум вариантам (никак и как создание привязки) и при том возможно будет построить синтаксическое дерево.
У меня основной используемой программой является редактор, но всё же потеря других настроек (zsh, Opera, mplayer, mercurial) была бы весьма неприятной. Особенно zsh и Opera, остальное легко восстановить.
Впрочем, в случае Opera одним репозиторием дело не ограничивается — так как я с самого начала рассматривал возможность сделать его публичным при необходимости, то пароли есть только в резервных копиях.
Изкоробочное решение не может обладать универсальностью: я не хочу иметь один способ восстановления для IDEVim, другой для zsh, третий для браузера. Вопрос здесь в том, как хранятся эти самые настройки? Не трогал файлы IDE, но с firefox, насколько мне известно, простое копирование файлов в другое место легко может и не пройти. Легко получить различия двух разных версий sqlite базы данных, в которой он и хранит настройки, точно не выйдет (правда, мне это почти никогда не нужно).
И ещё — пакетный менеджер там действительно увидев несоответствие между списком дополнений и тем, что реально установлено, начнёт установку недостающих частей? Или придётся заталкивать туда и сами дополнения? VAM, в частности, удобен тем, что если я использую свой vimrc на arm нетбуке, то он загрузит и скомпилирует Command-T. Писать дополнительный код для его компиляции или иметь репозиторий с бинарниками с неправильной архитектурой не требуется.
У редактора или IDE его и так нет. Он есть у меня, и там хранятся все настройки, не только редактора. Кроме того, странно, что вы не слышали: на github 20 449 репозиториев, названных «dotfiles». Значительное количество подобных репозиториев названо по‐другому (у меня — config, но на bitbucket и скрытый).
И это разве сложно? Как раз удобно — хранить настройки в репозитории, чтобы при переустановке ОС/покупке нового компьютера/… не начинать с нуля.
Если также сохранить и /etc (+ аналог /var/lib/portage/world из Gentoo со списком установленных пакетов) (и сделать резервные копии всего из $HOME, что не вошло в репозиторий с настройками), то у вас будет вся информация, необходимая для восстановления системы или отката при неверно выполненной настройке.
Получается, дополнения надо ставить и туда, и туда. Но у меня список дополнений описан в vimrc и для того, чтобы их поставить надо выполнить всего четыре действия:
Клонировать репозиторий с настройками.
Создать в нужном месте символические ссылки.
Клонировать vim-addon-manager.
Запустить Vim.
Vim-addon-manager далее затем сам установит всё, что нужно. Причём первый и третий шаги можно объединить с помощью submodules (я так не сделал, потому что VAM у меня установлен пакетным менеджером) либо поместив в vimrc код, который делает третий шаг (код можно просто скопировать из документации). Конечно, нужен по крайней мере git, но он нужен и с IDE.
А оставшиеся 5, видимо, не могут быть покрыты в принципе.
Мне лично проще жить с более плохим автодополнением, чем настроить IDE под себя: слишком много придётся настраивать, причём значительная часть из этого «много» является либо одной из основных возможностей Vim, либо предоставляется чужими дополнениями с небольшой настройкой. Оставшееся написано самостоятельно.
Вот как раз у Vim одна из самых совершенных систем навигации внутри файла (за исключением штук вроде «перейти к объявлению», не работающих без дополнений). Никаких PageUp/PageDown, работа с Vim вообще не предполагает перемещение рук куда‐либо с основного блока клавиатуры.
Кроме того, зачастую нужно сделать «command|xclip -i» и затем нормально вставлять вывод команды куда угодно средней кнопкой мыши. Можно сразу отправить текст на pastebin. Если вывод длиннее одной строчки, а запуск команды два раза быстр и производит одинаковый текст, то в GUI это будет сложнее сделать. Отдельно про SO: у меня есть
alias +4='sed "s/^/ /" | xclip -i'
, в Vim можно сделать привязку для того же (а можно просто выделить текст и сделать «>gv>», затем вставить). Интересно услышать, как вы копируете код из GUI.
Есть огромная куча дополнений к Vim разной степени работоспособности для различных языков, предоставляющих возможность перехода к определению и интеллектуального автодополнения. Дополнения, использующие синтаксические анализаторы тоже есть, но VimL не даёт (точнее, требует медленных и неприглядных решений) довольно большого количества возможностей их интеграции.
Grep обычно делается из Vim, а не из консоли в этом случае, так переход к найденному можно осуществить гораздо быстрее.
16 символов в секунду — это 960 в минуту. Какое здесь «даже при»?
В Vim очень удобно использовать Command-T для открытия файлов. Впрочем, это не единственное дополнение на эту тему: есть также FuzzyFinder, Unity, ku, LustyExplorer, … А автодополнение файлов в Vim убого. Я как‐то сделал аналог автодополнения файлов в zsh (причём, в zsh автодополнение именно файлов оказалось несколько хуже), но Command-T оказался ещё удобнее, поэтому проект заглох несмотря на несколько очевидных проблем.
Относительно virtualenv: “workon env” не работает в Vim (в смысле, если запустить workon и затем Vim, встроенная поддержка python будет игнорировать виртуальное окружение, но запущенные из Vim команды игнорировать не будут). Приходится использовать github.com/jmcantrell/vim-virtualenv.
-S vim-test. Писать шаблон, который с гарантией выберет только запущенные vim мне не хочется совершенно. Уж лучше я использую сокращения zsh чтобы сократить| grepвG:pps vim G foo. Или просто выберу глазами, гарантированно не получив в числе прочего вывода мусор с vim в аргументах или безумно длинные строчки (люблю открывать все файлы проекта сразу, всё равно vim реально их грузит в память только при необходимости) (ps обрезает строчки, если вывод осуществляется на терминал, pgrep нет).В имени файла могут быть одинарные кавычки. Причём даже на Windows. Правится одной строчкой, но делать этого не надо: взаимодействие с Vim всегда весьма медленно. Поэтому надо не использовать цикл, а собрать всё в один большой список:
VIM::Eval("expand('<sfile>:h')"), нужное именно для этого. Ни у меня, ни у огромного числа пользователей pathogen, vundle и vim-addon-manager нет ни малейшего желания помещать ваше дополнение в $HOME/.vim. Кроме того, зачем зря трудить Vim, чтобы он просматривал каталог plugin/cmake-project, в котором для него ничего нет, если можно отправить всё это дело в perl/cmakeproject.pm?ps -C?), не SID (что это вообще такое? впрочем не отвечайте, сам нашёл. Проблема та же, что и с терминалом) и не куча других неуникальных параметров.kill, еслиkillallнеприменим и что я редактирую в Vim’ах (с прибиванием лишнего).ps ax | grep? Гораздо проще и надёжнее использовать[[ "$(ps -C vmplayer -o args=)" == *user01* ]](bash/zsh) или эквивалент с grep.- не видите C API, для улучшения интерфейсов с другими языками зачастую приходится экспортировать существующую static функцию или выделять существующий код в отдельную функцию. Единственная документация — комментарии и их далеко не всегда достаточно;
- видите отсутствие нормального поддержки клавиатурных сочетаний. Обсуждениям на эту тему уже невесть сколько лет, но у Брама нет времени, а у остальных, видимо, пороха на такую задачу;
- видите множество запросов вида «а как сделать подсветку строки там где нет символов/подсветить N’ю колонку» Второе уже решено, но если бы вместо :syn было внятное C API, используемое первой, и соответствующие функции на Python/…, то вопрос бы не требовал создания целой новой настройки;
- видите до сих пор не исправленные неровности в скрытии символов вроде некрасивой табуляции, невозможности получить видимую позицию курсора, необходимости нажимать l/h столько раз, сколько символов сокрыто, …;
- видите вопросы «а почему я не могу сделать
, то у вас остаётся впечатление, что с архитектурой что‐то не то.nnoremap d smth, не получая задержку при вводе d»Собственно, VimL, система подсветки и система ввода — то, что нуждается в улучшениях, причём второе можно сделать без нарушения обратной совместимости, третье тоже (хотя если вы попросите меня это сделать или дождётесь пока сам созрею, то часть обратной совместимости будет намеренно нарушена, могу объяснить какая и почему). Вместо первого лучше иметь C API с доступом ко всем возможностям редактора и соответствующие интерфейсы: для того, чтобы всё использование VimL сводилось к чему‐то вроде
. Впрочем это не отменит того, что я считаю необходимым сделать VM для VimL, но это имеет мало смысла без потери малой части обратной совместимости: скажите, как Vim может воспринять вторую строку в следующем коде:
? Я знаю как минимум три варианта. Если запретить незавершённые блоки :if/:for/:try/:while/:function и принудительно завершать :append/:insert по окончании :execute то всё сведётся к двум вариантам (никак и как создание привязки) и при том возможно будет построить синтаксическое дерево.
Впрочем, в случае Opera одним репозиторием дело не ограничивается — так как я с самого начала рассматривал возможность сделать его публичным при необходимости, то пароли есть только в резервных копиях.
IDEVim, другой для zsh, третий для браузера. Вопрос здесь в том, как хранятся эти самые настройки? Не трогал файлы IDE, но с firefox, насколько мне известно, простое копирование файлов в другое место легко может и не пройти. Легко получить различия двух разных версий sqlite базы данных, в которой он и хранит настройки, точно не выйдет (правда, мне это почти никогда не нужно).И ещё — пакетный менеджер там действительно увидев несоответствие между списком дополнений и тем, что реально установлено, начнёт установку недостающих частей? Или придётся заталкивать туда и сами дополнения? VAM, в частности, удобен тем, что если я использую свой vimrc на arm нетбуке, то он загрузит и скомпилирует Command-T. Писать дополнительный код для его компиляции или иметь репозиторий с бинарниками с неправильной архитектурой не требуется.
И это разве сложно? Как раз удобно — хранить настройки в репозитории, чтобы при переустановке ОС/покупке нового компьютера/… не начинать с нуля.
Если также сохранить и /etc (+ аналог /var/lib/portage/world из Gentoo со списком установленных пакетов) (и сделать резервные копии всего из $HOME, что не вошло в репозиторий с настройками), то у вас будет вся информация, необходимая для восстановления системы или отката при неверно выполненной настройке.
Vim-addon-manager далее затем сам установит всё, что нужно. Причём первый и третий шаги можно объединить с помощью submodules (я так не сделал, потому что VAM у меня установлен пакетным менеджером) либо поместив в vimrc код, который делает третий шаг (код можно просто скопировать из документации). Конечно, нужен по крайней мере git, но он нужен и с IDE.
Мне лично проще жить с более плохим автодополнением, чем настроить IDE под себя: слишком много придётся настраивать, причём значительная часть из этого «много» является либо одной из основных возможностей Vim, либо предоставляется чужими дополнениями с небольшой настройкой. Оставшееся написано самостоятельно.
Кроме того, зачастую нужно сделать «command|xclip -i» и затем нормально вставлять вывод команды куда угодно средней кнопкой мыши. Можно сразу отправить текст на pastebin. Если вывод длиннее одной строчки, а запуск команды два раза быстр и производит одинаковый текст, то в GUI это будет сложнее сделать. Отдельно про SO: у меня есть
, в Vim можно сделать привязку для того же (а можно просто выделить текст и сделать «>gv>», затем вставить). Интересно услышать, как вы копируете код из GUI.
Копирование откуда‐то ещё тривиальнее.
Grep обычно делается из Vim, а не из консоли в этом случае, так переход к найденному можно осуществить гораздо быстрее.
В Vim очень удобно использовать Command-T для открытия файлов. Впрочем, это не единственное дополнение на эту тему: есть также FuzzyFinder, Unity, ku, LustyExplorer, … А автодополнение файлов в Vim убого. Я как‐то сделал аналог автодополнения файлов в zsh (причём, в zsh автодополнение именно файлов оказалось несколько хуже), но Command-T оказался ещё удобнее, поэтому проект заглох несмотря на несколько очевидных проблем.
Относительно virtualenv: “workon env” не работает в Vim (в смысле, если запустить workon и затем Vim, встроенная поддержка python будет игнорировать виртуальное окружение, но запущенные из Vim команды игнорировать не будут). Приходится использовать github.com/jmcantrell/vim-virtualenv.
:make; посмотрите её описание на предмет, чем оно лучше:!make.