Оглавление
- Введение (vim_lib)
- Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
- Уровень проекта и файловая система (vim_prj, nerdtree)
- Snippets и шаблоны файлов (UltiSnips, vim_template)
- Компиляция и выполнение чего угодно (vim-quickrun)
- Работа с Git (vim_git)
- Деплой (vim_deploy)
- Тестирование с помощью xUnit (vim_unittest)
- Библиотека, на которой все держится (vim_lib)
- Другие полезные плагины
Проекты, это то, чего очень не хватает редактору Vim. Реализация проекта позволяет не только выделить его как отдельную сущность среди других папок и файлов в ФС, но и реализовать такие свистелки, как:
- Автоматическое сохранение и восстановление последней сессии проекта так, что после повторного открытия, мы получим редактируемый в прошлый раз файл(ы), с теми же настройками и положением
- Хранение информации о проекте, такой как автор проекта, лицензия, версия и так далее. Все эти данные можно будет добавлять в шаблоны и сниппеты
- Корневой каталог проекта строго определен. Это упростит использования других инструментов, на пример xUnit, дебагеры, генераторы документации и т.д.
- Отдельный, принадлежащий только проекту каталог .vim и файл .vimrc, аналогичный пользовательским версиям. Теперь настройки и плагины проекта будут хранится в нем
Проекты в Vim
Не знаю почему, но пользователи Vim либо не используют проектную модель, либо реализуют/используют довольно странные плагины, которые, по сути, дают лишь часть от необходимой функциональности проекта. В Vim есть готовые механизмы, позволяющие реализовать новый уровень проекта, это опция exrc, которая заставляет Vim при загрузке искать и запускать файл .vimrc в корневом каталоге, но очевидно этого недостаточно. Что не хватает этому решению? Во-первых мы получаем в проекте один толстый файл .vimrc, изменять который со временем становится все сложнее. Во-вторых переопределять конфигурации Vim для проекта, такие как: подсветка, сниппеты, шаблоны, плагины — становится сложнее. В идеале проекту нужен как файл .vimrc, так и свой собственный каталог .vim (аналог .idea). Этот каталог должен повторять функциональность своего собрата уровня пользователя, а это значит использование тех же подкаталогов и той же логики загрузки (по возможности, средствами самого Vim, дабы все было прозрачно и гибко).
Один небольшой плагин
Подключение и использование каталога .vim реализуется уже знакомой нам библиотекой vim_lib. Класс sys/Autoload подключает каталог проектный каталог .vim к runtimepath так, что он загружается в правильной последовательности (последним) и может переопределять любые настройки Vim. Остальную логику реализует плагин vim_prj. В его задачи входит:
- Подключить с помощью опции exrc файл .vimrc
- Сохранять и восстанавливать последнюю сессию проекта
- Создавать инфраструктуру проекта по команде
- Хранить опции проекта, такие как автор, лицензия и т.д.
- Хранить информацию о расположении проекта в ФС и всех уровнях загрузки
Проектный .vimrc
Если кто не знает, опция exrc заставляет Vim искать в текущем каталоге (каталог, в котором запущен редактор) файлы с именами .vimrc или _vimrc и запускать их. Плагин vim_prj просто устанавливает эту опцию в значение «включено».
Сессии проекта
Здесь все не намного сложнее. Vim из коробки умеет сохранять и восстанавливать сессию с помощью хранящего информацию о сессии файла и команды mksession. Опция sessionoptions позволяет определить, какие именно данные будут сохраняться, а какие можно «забыть».
Плагин реагирует только на проекты (корневой каталог содержит .vim) и автоматически сохраняет и восстанавливает последнюю сессию при открытии и закрытии проекта. Сессия проекта хранится в файле .vim/session.vim.
Инфраструктура проекта
Для того, чтобы плагин работал с некоторым каталогом как с проектом, достаточно создать в нем каталог .vim. Все ленивые программисты в голос скажут — мне что, руками его создавать? — конечно нет! Для этого плагин реализует команду VimPrjCreate, которая помимо .vim создает файл .vimrc в проекте, инициализирует его согласно требованиям загрузчика sys/Autoload, создает .vim/plugins.vim и .vim/bundle. Такая структура позволяет быстро устанавливать плагины с помощью vim_plugmanager (они сразу подключаются в .vim/plugins.vim).
filetype off
call vim_lib#sys#Autoload#init('.vim', 'bundle')
so .vim/plugins.vim " Все объявления установленных в проекте плагинов должны хранится в этом файле
filetype indent plugin on
Информация о проекте
Глобальный словарь vim_prj#opt, создаваемый плагином, не является чем то особенным, а просто определяет место, в котором должны хранится данные о проекте. Вы можете задать общую информацию для всех проектов в вашем пользовательском ~/.vimrc
" В файле ~/.vimrc
let g:vim_prj#opt = {'author': 'Vim_*', 'license': 'GNU GPL 3'}
и переопределить их для конкретного проекта в .vimrc файле проекта.
" В файле ./.vimrc
let g:vim_prj#opt = {'author': 'Vim_*', 'license': 'MIT'} " Словарь будет переопределен, а не слит
Этот словарь активно используется моими сниппетами и шаблонами, что позволяет быстро изменять информацию о проекте, не копаясь в куче файлов.
Дом проекта
Очень полезной особенностью плагина, которую даже не пришлось реализовывать, является определение расположения проекта в ФС. Если вы открываете редактор Vim в корневом каталоге проекта (в котором хранится .vim), то вы работаете в проекте, иначе, вы просто открыли редактор. Соответственно плагину будет известен адрес корневого каталога проекта, все другие уровни загрузки редактора ($VIMRUNTIME и ~/.vim), что может понадобится другим вашим плагинам. Естественно для того, чтобы работать с таким проектом, нужна возможность просматривать файловую структуру проекта и открывать файлы. Делается это с помощью плагина nerdtree. Другими словами вы просто открываете редактор в корне вашего проекта командой vim, и получаете все прелести, присущие проекту.
Пока все
Не вижу смысла расписывать плагин nerdtree в этой статье (думаю вы и так о нем знаете), скажу лишь, что в будущем он будет заменен или переписан, так как в нем отсутствуют некоторые обязательные для файлового менеджера функции и удобный API для использования другими плагинами.
Комментарии (53)
Vyazovoi
11.06.2015 09:48Я не работаю с проектами в vim, но некоторое время назад пробовал реализовать в нём концепцию проекта. Оказалось, в vim действительно для этого всё уже есть. Только вы как-то переусложнили, мне вполне хватало описанного здесь: paul.elms.pro/blog/2014/05/06/vim-projects
Т.е. сессии это и так отдельные конфиги, которые могут и корневую директорию задать, и настройки поменять, и открыть все нужные вкладки и инструменты. Остаётся только добавить удобный способ перечитывать файлы сессий в vim.
Delphinum Автор
11.06.2015 11:25На самом деле vim_prj работает точно так же, только запускает сессию не с помощью ключа -S редактора, а с помощью команды :source.
ZyXI
11.06.2015 18:07На самом деле ключ -S запускает команду
source, причём даже без экранирования: попробуйтеvim -u NONE -i NONE -S '/dev/null | echomsg 123': данная команда отличается отvim -u NONE -i NONE -c 'so /dev/null | echomsg 123'на несколько условных переходов и одно выделение памяти.Delphinum Автор
11.06.2015 18:11Я верю, но какая разница, как там все это дело внутри работает? В результате получаем загрузку сессии при открытии проекта с помощью простой команды vim, а не vim -S ~/.vim/sessions/myLastSession.vim
ZyXI
11.06.2015 18:22Просто механизмы не отличаются и можно делать тот же source из живой сессии, как vim_prj, но без vim_prj. Вопрос?то в том, есть в Vim всё, что нужно, или нет.
К тому же, автоматическое открытие последней сесии при запуске Vim без аргументов — очень плохая идея для многих разработчиков дополнений для Vim. Я могу открыть Vim для тестов в любом каталоге, что?то проверить и потом закрыть. А у вас даже настройки на отключение такого поведения нет.Delphinum Автор
11.06.2015 18:33Просто механизмы не отличаются и можно делать тот же source из живой сессии, как vim_prj, но без vim_prj
Конечно можно, но для этого нужно разобраться, как работают сессии в Vim и как их восстанавливать с помощью source. Думаете все хотят в этом разбираться, вместо того, чтобы установить один плагин? Да и сохранение/восстановление сессии это не единственная задача vim_prj.
А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге, протестировать что-то и потом закрыть? Возможно вы не совсем правильно поняли идею. Сессия восстанавливается плагином только в том случае, если в текущем каталоге есть файл ./.vim/sessions.vim.ZyXI
11.06.2015 18:42Конечно можно, но для этого нужно разобраться, как работают сессии в Vim и как их восстанавливать с помощью source. Думаете все хотят в этом разбираться, вместо того, чтобы установить один плагин? Да и сохранение/восстановление сессии это не единственная задача vim_prj.
Ни в чём не нужно разбираться: в:h :mksessionчто представляет из себя файл сессии кратко написано прямо в первой строке. А восемь строчек ниже об использовании:sourceнаписано уже в явном виде.
А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге, протестировать что-то и потом закрыть?
Зачем?Delphinum Автор
11.06.2015 19:29Ни в чём не нужно разбираться: в :h :mksession что представляет из себя файл сессии кратко написано прямо в первой строке. А восемь строчек ниже об использовании :source написано уже в явном виде
Но программисты, это ленивые люди, не забывайте об этом ;)
Я могу открыть Vim для тестов в любом каталоге
А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге
Зачем?
Вот и мне интересно, зачем?ZyXI
11.06.2015 20:46Затем, чтобы что?то проверить. Вот сказал кто?то в vim-dev, что есть в Vim ошибка, надо проверить. Или в моём дополнении ошибка. Или в vim-use задали интересный вопрос, надо бы написать ответ и проверить его. Всё это делается в ближайшем терминале нужных размеров (у меня их три — «на весь экран», «на половину экрана по ширине» — обычно заняты под проекты — и «на 40% экрана по высоте» (yakuake) для сиюминутных нужд, но в последнем не всё удобно проверять из?за размера).
А для PHPStorm и IntelliJ IDEA я дополнений не пишу и исходный код их не трогаю.Delphinum Автор
11.06.2015 22:02Затем, чтобы что?то проверить
Ну так открываете Vim и проверяете. Я повторюсь, vim_prj не загружает сессию вне проекта. То есть, если вы открываете Vim в каталоге, в котором нет проекта, никакой сессии загружается не будет.
А для PHPStorm и IntelliJ IDEA я дополнений не пишу и исходный код их не трогаю
То есть, если вы будите писать под PHPStorm и IntelliJ IDEA дополнения и трогать исходные коды, вы попросите от разработчиков отключения принудительного использования проектов? В отличии от PHPStorm и IntelliJ IDEA, vim_prj работает как с проектами, так и без них.ZyXI
11.06.2015 22:13Ну так открываете Vim и проверяете. Я повторюсь, vim_prj не загружает сессию вне проекта. То есть, если вы открываете Vim в каталоге, в котором нет проекта, никакой сессии загружается не будет.
Особенно это актуально если я проверяю что?то, связанное с проектом и мне не нужны ни сессия, ни каталог без проекта (последнее — в первую очередь по «идеологическому» соображению «всё, связанное с проектом — в одном месте»).
То есть, если вы будите писать под PHPStorm и IntelliJ IDEA дополнения и трогать исходные коды, вы попросите от разработчиков отключения принудительного использования проектов? В отличии от PHPStorm и IntelliJ IDEA, vim_prj работает как с проектами, так и без них.
Я могу приспособится к такому поведению, но скорее я просто не буду под них ничего писать. Хотя и по другим причинам.Delphinum Автор
11.06.2015 22:23Особенно это актуально если я проверяю что?то, связанное с проектом и мне не нужны ни сессия, ни каталог без проекта
Не сталкивался еще с такой ситуацией, когда нужно было проверить что-то, связанное с проектом, и загрузка сессии этому бы помешала. Отключите плагин vim_prj на время проверки и включите его снова.
Я могу приспособится к такому поведению, но скорее я просто не буду под них ничего писать
Я к тому, что все среды разработки работают только с проектами, загружая автоматом сессию и так далее, а вы придирайтесь к vim_prj, который можно в любой момент отключить и который работает, только внутри проекта )ZyXI
11.06.2015 23:06Не сталкивался еще с такой ситуацией, когда нужно было проверить что-то, связанное с проектом, и загрузка сессии этому бы помешала. Отключите плагин vim_prj на время проверки и включите его снова.
Загрузка сессии помешает, в первую очередь, сообщением «этот файл уже открыт в другом Vim». Во?вторую, тем, что vim_prj ещё и сохранит потом сессию и в ней будет что?то ненужное. А «отключение» плохо тем, что для того, чтобы «безопасно» запустить Vim нужно что?то сделать. Гораздо лучше вариант, когда нужно «опасно» включить vim_prj: например, отключить загрузку и сохранение сессий вообще (такая настройка у вас, как вижу есть), а загружать по команде (а такого нет) и после загрузки включить сохранение.
Кстати, я рекомендую сделать в дополнении автосохранение сессий: у меня, к примеру, довольно длительное время Vim «аварийно завершался» из?за того, что после hibernate и чего?то ещё отваливалась файловая система с /home (т.е. Vim я закрыть?то мог, но vim_prj ничего никуда бы при этом не сохранил), а не из?за того, что я закрыл проект. Даже не представляю, что это было, но выглядело как ошибка в модуле XFS. Обычно такое делают на основеCursorHoldиCursorHoldIсобытий.Delphinum Автор
11.06.2015 23:30Загрузка сессии помешает, в первую очередь, сообщением «этот файл уже открыт в другом Vim» ...
Не совсем понимаю о чем вы, так как с такими проблемами не сталкивался, хотя и работаю с vim_prj уже довольно долго.
Кстати, я рекомендую сделать в дополнении автосохранение сессий
У меня для этого отдельный плагин vim_write, который автосохраняет проект каждые n секунд, как это делают многие современные IDE.ZyXI
12.06.2015 13:22Не совсем понимаю о чем вы, так как с такими проблемами не сталкивался, хотя и работаю с vim_prj уже довольно долго.
Просто откройте один проект два раза. Предварительно включите в vimrc swap файлы — это обязательное условие.
У меня для этого отдельный плагин vim_write, который автосохраняет проект каждые n секунд, как это делают многие современные IDE.
Он сохраняет файлы, а не сессию.Delphinum Автор
12.06.2015 13:46Просто откройте один проект два раза. Предварительно включите в vimrc swap файлы — это обязательное условие.
Такая эзотерика случается в реальной жизни, или это вакуум и сферический конь?
Он сохраняет файлы, а не сессию
Что гораздо важнее.ZyXI
12.06.2015 13:56Такая эзотерика случается в реальной жизни, или это вакуум и сферический конь?
Если отключить автозагрузку сессии, то — вакуум и сферический конь. Если не отключать и пользоваться Vim как я говорю — для быстрой проверки чего?то в каталоге проекта, — то такое будет постоянно.
Что гораздо важнее.
Так лучше сохранять и то, и то.Delphinum Автор
12.06.2015 16:19для быстрой проверки чего?то в каталоге проекта
Так если у вас проект уже открыт и вам нужно что то в нем проверить, зачем открывать его еще раз?ZyXI
12.06.2015 16:29Проект — дополнение к Vim. В него внесены изменения после открытия. Вопрос: какая версия проекта будет проверена в уже открытом Vim? Вопрос 2: нафига мне в «проектном» Vim буферы чисто для тестирования?
Delphinum Автор
12.06.2015 17:13Вопрос: какая версия проекта будет проверена в уже открытом Vim?
О какой «версии» проекта и о какой «проверке» идет речь?
нафига мне в «проектном» Vim буферы чисто для тестирования?
Даже предположить не могу, зачем вам буферы чисто для тестирования.ZyXI
12.06.2015 21:56О какой «версии» проекта
Представьте себе файл~/.vim/autoload/test.vimс содержимым
Вы запустилиfunction test#version() return '0.0' endfunctionecho test#version(), убедились, что Vim выводит0.0и изменили0.0на0.1. Что выведетecho test#version(), если Vim вы не перезапускали?
и о какой «проверке» идет речь?
У вас в дополнениях есть тесты. Возьмите любой. Иногда перед тем, как писать набор тестов (в основном, функциональные), я проверяю дополнение на общую корректность «вручную» на одном?двух тестах из запланированного набора. А если на моём тесте написано «regression test», то можно быть практически уверенным, что я его сначала точно проверил именно вручную (или не его, но что?то, вызывающее ту же ошибку).
Даже предположить не могу, зачем вам буферы чисто для тестирования.
Это странно. У вас есть дополнение vim_notepad, неужели вы не писали заметки вида «Test test test»? Обычно такие буферы можно легко закрыть и всё упирается в первую проблему, но, к примеру,AuVimDiffможет открыть до (2 ? число файлов в репозитории) буферов и, если что?то в процессе сломалось, то ещё и не дать закрыть их одним клавиатурным сочетанием.
Кстати, недописанные дополнения могут создавать огромные проблемы при редактировании. Поэтому я практически никогда не используюpython powerline.reload()для тестирования powerline в уже открытом Vim, а открываю новый. Конкретно powerline при наличии неотловленной ошибки в новом коде может просто забить Vim Traceback’ами до фактической невозможности использования Vim для редактирования. И это несмотря на то, что в отличие от вашей vim_lib мой frawor изначально предполагает возможность «перезагрузки» дополнений, написанных на его основе, да и в powerline я добавил такую же функциональность.Delphinum Автор
13.06.2015 12:45Вы запустили echo test#version(), убедились, что Vim выводит 0.0 и изменили 0.0 на 0.1. Что выведет echo test#version(), если Vim вы не перезапускали?
Конечно 0.0. Если мне нужны эти изменения в проекте прямо сейчас, я перезапущу проект, а не открою его занаво. Объясню как я тестирую плагины:
- Предположим у меня открыты пару проектов, с которыми я сталкиваюсь по работе. Они никак не связаны с разрабатываемым плагином, но не помешало бы использовать плагин и в них тоже
- Я пишу плагин
- Я открываю Vim в каталоге ~/tmp/test_vim, там у меня создан проект спецом для тестирования плагинов. Никакой разницы нет, в каком каталоге я открою редактор (часто я делаю это в ~/), просто ~/tmp/test_vim подготовлен так, чтобы с его помощью было легко тестировать новые плагины с учетом проектного уровня загрузки
- Если что то не так в плагине, я его правлю и перезапускаю проект в ~/tmp/test_vim
- Повторяю правки и перезапуск
- Когда плагин готов я лью его на GitHub и перезапускаю те запущенные проекты, в которых этот плагин мне нужен
Не вижу смысла запускать один и тот же проект по нескольку раз.
Кстати, недописанные дополнения могут создавать огромные проблемы при редактировании
Недописанные дополнения у меня глобально не подключены (их нет в ~/.vimrc). Если я их тестирую, я просто подключаю их на уровне ~/tmp/test_vim/.vimrc и работаю с ними там. Другие мои проекты даже не знаю о их существовании.
Простите конечно, но я даже в упор не вижу проблем, о которых вы говорите.ZyXI
13.06.2015 13:23Я открываю Vim в каталоге ~/tmp/test_vim, там у меня создан проект спецом для тестирования плагинов. Никакой разницы нет, в каком каталоге я открою редактор (часто я делаю это в ~/), просто ~/tmp/test_vim подготовлен так, чтобы с его помощью было легко тестировать новые плагины с учетом проектного уровня загрузки
Вот эта часть. Я не держу специальный каталог для тестирования, т.к. в том же терминале, где я делаю «быстрые» тесты я запускаю вещи вроде git rebase или какие?нибудь перестановки файлов. (Нет, делать это в терминале с открытым проектом неудобно.)
И ещё у меня всегда подключены даже недописанные дополнения: это хорошая гарантия того, что я их?таки допишу до сколько?нибудь приличного состояния — просто, чтобы не получать ошибки во время работы.Не вижу смысла запускать один и тот же проект по нескольку раз.
Я не запускаю один и тот же проект несколько раз. Я запускаю несколько Vim в одном каталоге. И мне очень не нравиться идея отказа от работающего workflow.Delphinum Автор
13.06.2015 14:09Так vim_prj не мешает вам запускать хоть сотню раз Vim в некотором каталоге, главное чтоб в нем не было проектного .vim. Или вам нужно именно сотню раз запустить Vim в одном из проектов?
И ещё у меня всегда подключены даже недописанные дополнения: это хорошая гарантия того, что я их?таки допишу до сколько?нибудь приличного состояния
Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )ZyXI
13.06.2015 14:12Так vim_prj не мешает вам запускать хоть сотню раз Vim в некотором каталоге, главное чтоб в нем не было проектного .vim. Или вам нужно именно сотню раз запустить Vim в одном из проектов?
Да, именно в проектном каталоге. Я же ясно написал, что из одного терминала я запускаю и git, и Vim для тестов.
Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )
Покажите, где я удивлялся? У меня всё нормально работает. Но если бы не такая привычка, то некоторые ошибки я бы пропускал в релиз точно.Delphinum Автор
13.06.2015 14:24Да, именно в проектном каталоге. Я же ясно написал, что из одного терминала я запускаю и git, и Vim для тестов.
Я не могу представить как у вас это работает. То есть запускаю я значит мой /var/www/work/ok, пишу там пару контроллеров для учета платежей пользователей, затем (внезапно) переключаюсь к написанию нового плагина под Vim. Когда плагин, на мой взгляд, дописан, я возвращаюсь к открытому редактору в /var/www/work/ok, открываю новый буфер (или в том же буфере, или открываю новый редактор в том же каталоге?) и тестирую новый плагин? Честно говоря, считаю это проблемой подхода к разработке плагинов и использованию Vim, нежели проблемой плагина vim_prj.
Ок, вам понравится, если функцию автозагрузки сессии можно будет отключить?
Покажите, где я удивлялся?
Согласен, не те слова подобрал.ZyXI
13.06.2015 14:36«Проект» — это дополнение для Vim. При чём тут /var/www/work/ok?
У меня открыт, к примеру Vim со всеми файлами из bitbucket.org/ZyX_I/frawor в каталоге ~/.vim/dev/frawor на рабочем столе 3. На том же столе открыт терминал в том же каталоге с tmux с двумя окнами: в правом запускаются автоматические тесты, в левом — ручные тесты и git. Т.к. frawor всегда включён и всегда используется именно разрабатываемая версия, то открытый где бы то ни было Vim позволяет его тестировать. Поэтому используется именно каталог ~/.vim/dev/frawor для тестов по двум причинам: git и лёгкость использования файлов от автоматических тестов для ручного тестирования.
Ок, вам понравится, если функцию автозагрузки сессии можно будет отключить?
Её же и так можно. Просто сделайте команду «загрузить сессию и установить автокоманду для её сохранения».Delphinum Автор
13.06.2015 14:41«Проект» — это дополнение для Vim. При чём тут /var/www/work/ok?
Ну для вас это дополнение для Vim, для меня это любой каталог.
Просто сделайте команду «загрузить сессию и установить автокоманду для её сохранения».
Тогда мне будет не удобно постоянно, открывая некоторый проект, выполнять эту команду. Может сойдемся на флаге, который определяет — загружать ли сессию при открытии проекта автоматом или нет?ZyXI
13.06.2015 14:43Я имею ввиду, что всё остальное уже есть. Я могу отключить автозагрузку уже имеющейся настройкой, но я не могу потом загрузить сессию и включить автосохранение. Отключать автозагрузку вообще я не предлагаю: для проектов?не?дополнений так, наоборот, удобнее.
Delphinum Автор
13.06.2015 14:46То есть вы хотите открыть проект без загрузки сессии, потом руками загрузкить сессию и включить автосохранение при выходе из проекта?
ZyXI
13.06.2015 14:47Да.
Delphinum Автор
13.06.2015 14:52Ну вы и извращуга я вам скажу ))
Я добавлю новый флаг vim_prj#.loadsession, который будет определять, загружать ли сессию автоматом или нет. Вы в вашем плагине просто создадите ./.vimrc и добавите в него:
let g:vim_prj#options = {'savesession': 1, 'loadsession': 0}
При этом при открытии вашего плагина сессия загружаться не будет, но будет сохраняться (загрузить ее можно будет с помощью команды VimPrjLoadSession, которую я добавлю). Одновременно все остальные ваши проекты будут загружать сессию автоматически. Пойдет?
poxu
11.06.2015 15:47Чувак, ты достучался до моего сердца! Сам очень медленно начинаю добавлять в вим возможности по поддержке проектов и пока что как раз дошёл до необходимости иметь свой .vimrc в директории проекта. У меня там всякие настройки, чтобы пускать сборку и тесты нажатием одной клавиши. Для навигации по файлам пользую CtrlP. Ничего лучше по моему придумать нельзя.
А до сохранения сессий я ещё не дорос.Delphinum Автор
11.06.2015 17:16В будущих статьях расскажу как одной кнопкой не только тестить проект, но и конкретный файл или тест, а так же удобная сборка имеется.
poxu
11.06.2015 17:35У меня сборка и запуск тестов исчерпываются асинхронным запуском консольной команды. Выхлоп смотрю в отдельном окне с запущенным tail. Посмотрим как можно ещё.
Но идея держать набор плагинов для каждого проекта реально очень совпадает с тем, что подсказывает мне внутренний голос.Delphinum Автор
11.06.2015 17:37А зачем еще как то, когда и этот вариант вполне приемлим? )
poxu
11.06.2015 20:13Ну запуск консольной команды асинхронен, но отвязан от вима. Поэтому к месту возникновения ошибки автоматом не перейти, упавший тест не открыть.
Delphinum Автор
11.06.2015 22:03Я еще не реализовал возможность автоматического перехода к упавшим тестам, просто смотрю выхлоп xUnit и открываю нужный файл.
ZyXI
11.06.2015 18:37Кстати, у меня вопрос: а что в коде делает
silent!? Особенно с восклицательным знаком и передso…session.vim. Перемещает ошибки из разряда «увидел — исправил» (или, хотя бы, удалил файл с сессией) в разряд «чё это за х*ня и как её исправить» (хотя, скорее, «vim_prj незаметно потерял буфер с документацией, удалю?ка я его»: мне сложно представить более критичные ошибки в файле сессии)?
Кстати, s:File.slash практически во всех случаях абсолютно бесполезная вещь. Vim воспринимает / как разделитель компонентов пути всегда. Единственный вариант, когда вам нужен именно «родной» разделитель — передача аргументов в оболочку.
И ещё: это совершенно не дело игнорировать пользовательскую настройку &sessionoptions. Особенно отсутствие в списке globals: некоторые дополнения явно сделали свои настройки сохраняемыми в таком виде.Delphinum Автор
11.06.2015 18:40Перемещает ошибки из разряда «увидел — исправил» в разряд «чё это за х*ня и как её исправить»
Предполагается, что файл сессии создается и восстанавливается Vim без ошибок. Почему там silent! я уже, если честно, не помню.
Кстати, s:File.slash практически во всех случаях абсолютно бесполезная вещь
Сомневался на счет этого, потому таки решил использовать такое решение.
И ещё: это совершенно не дело игнорировать пользовательскую настройку &sessionoptions. Особенно отсутствие в списке globals: некоторые дополнения явно сделали свои настройки сохраняемыми в таком виде
Тут согласен. Поправлю.ZyXI
11.06.2015 18:46Я чаще всего слышал об ошибках при открытии из Vim другой версии либо с другими настройками компиляции (точнее, видел в issue tracker’е NeoVim, т.к. NeoVim имеет несколько другой набор настроек: часть из них просто удалена). Предполагаю (но это не подтверждено), что популярной ошибкой может быть буфер вроде
http://example.com(т.е. открываемый с помощью BufRead* команд, не присутствующий в файловой системе). Больше ничего в голову не приходит.
ZyXI
11.06.2015 22:31Заметил ещё одну вещь:
getcwd() != $HOME. Сравнение строк с помощью операторов[!=<>]=,is(not)?и[<>]делать нельзя никогда, потому что результат сравнения, за некоторыми исключениями, непредсказуем на этапе написания кода: результат использования всех указанных операторов зависит от значения пользовательской настройкиignorecase. «Безопасные» версии — это те же операторы, но с суффиксом#(регистр не игнорируется) или?(регистр игнорируется). Я лично использую всегда- Функцию
emptyвместо сравнения с пустой строкой. is#илиisnot#для сравнения строки со строкой
У последнего случая своя специфика: во?первых, данные операторы безопасны тем, что0 ==# "abc", но0 isnot# "abc". Во?вторых,[] !=# "abc"— ошибка,[] isnot# "abc"— 1. Первая часть позволяет использовать 0 в ряде случаев вместо отсутствующего значения None. Вторая часть иногда нужна для типов вродеenum {Ignore, Raise, Callback(fn())}(пример показывает тип для выбора между двумя стандартными действиями и вызовом своей функции).
Хорошей привычкой является писать безопасные операторы всегда, даже если строка на одной стороне «безопасна» (т.е. не содержит букв, которые имеют uppercase и lowercase варианты): так не нужно думать о том, какой оператор поставить именно здесь. Сравнение с $HOME, которое я нашёл, кстати, таким случаем не является.ZyXI
11.06.2015 22:40VimL вообще имеет массу таких случаев, когда «стандартный» вариант использовать небезопасно или использование которого приведёт к неудобству пользователя:
*map/*menu/*abbrev(нужно*nore*, можно ещё добавить<special>, если кого?то волнуют странные люди в совместимом режиме (set compatible)),normal(нужен восклицательный знак),match*(string, 'regexp')(нужна\cили\Cвнутри регулярного выражения, это очень характерно практически для всех функций, принимающих регулярные выражения),command(за очень редкими исключениями нужно добавлять-bar), …
- Функцию
ZyXI
Для открытия файлов, но не для манипуляций с ними, лучше использовать что?то вроде Command-T, а не NERDTree. Переход между файлами в этом случае осуществляется гораздо быстрее. Он также отдельно умеет переходить по тёгам (а, если вы знаете Ruby, то и по чему угодно, с помощью очевидных и понятных, но хаков: PR со стандартным интерфейсом для дополнений почему?то висит; более расширяемой альтернативой является CtrlP, но его исходный код меня ужасает).
Delphinum Автор
Что вы имеете в виду под «манипуляциями с файлами»?
Он работает с использованием Ruby?
ZyXI
Как минимум, переименование/перемещение, удаление. Файловый менеджер, как правило, добавляет ещё много своих пунктов вроде создания нового файла, создания архива с выделенным(и) файлом(ами) или создания письма с файлом(ами).
Теоретически, дополнения а?ля Command-T можно допилить до полноценного файлового менеджера. Но так почему?то никто не делает.
Delphinum Автор
NerdTree умеет перемещать, переименовывать, создавать и удалять файлы. К сожалению в нем нет API, позволяющего связать его, на пример, с Git
ZyXI
Я как?то начал создавать дополнение с более расширяемым API. Только забросил из?за его бесполезности для меня: zsh удобнее.
// Да, NERDTree это умеет. Но я говорил не о том, что (не) умеет NERDTree, а о том, что для открытия файлов хорошо бы найти что?то другое, и это что?то — не файловый менеджер.
ZyXI
И ещё: Command-T не для просмотра структуры проекта и не может быть для него допилен. Всё обозначенное (включая просмотр структуры) я делаю из оболочки.
Т.е., по?моему, нужны отдельно два дополнения: «быстрый переход» (Command-T) и «файловый менеджер» (тот же NERDTree). Первый также с радостью возьмёт на себя «переход по (примерно) известному имени класса» (но не «переход на определение сущности (класса/переменной/…) под курсором»), «открытие файла в другой программе» (к примеру, в браузере) и вообще любой поиск по любыми примерно известным идентификаторам, полный список которых известен, и любого рода открытие найденных идентификаторов. Если, конечно, нормально расширяем.