Vim по полной: Уровень проекта и файловая система

[@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). Первый также с радостью возьмёт на себя «переход по (примерно) известному имени класса» (но не «переход на определение сущности (класса/переменной/…) под курсором»), «открытие файла в другой программе» (к примеру, в браузере) и вообще любой поиск по любыми примерно известным идентификаторам, полный список которых известен, и любого рода открытие найденных идентификаторов. Если, конечно, нормально расширяем.

[@Vyazovoi]

Я не работаю с проектами в vim, но некоторое время назад пробовал реализовать в нём концепцию проекта. Оказалось, в vim действительно для этого всё уже есть. Только вы как-то переусложнили, мне вполне хватало описанного здесь: paul.elms.pro/blog/2014/05/06/vim-projects

Т.е. сессии это и так отдельные конфиги, которые могут и корневую директорию задать, и настройки поменять, и открыть все нужные вкладки и инструменты. Остаётся только добавить удобный способ перечитывать файлы сессий в vim.

[@Delphinum]

На самом деле vim_prj работает точно так же, только запускает сессию не с помощью ключа -S редактора, а с помощью команды :source.

[@ZyXI]

На самом деле ключ -S запускает команду source, причём даже без экранирования: попробуйте vim -u NONE -i NONE -S '/dev/null | echomsg 123': данная команда отличается от vim -u NONE -i NONE -c 'so /dev/null | echomsg 123' на несколько условных переходов и одно выделение памяти.

[@Delphinum]

Я верю, но какая разница, как там все это дело внутри работает? В результате получаем загрузку сессии при открытии проекта с помощью простой команды vim, а не vim -S ~/.vim/sessions/myLastSession.vim

[@ZyXI]

Просто механизмы не отличаются и можно делать тот же source из живой сессии, как vim_prj, но без vim_prj. Вопрос‐то в том, есть в Vim всё, что нужно, или нет.

К тому же, автоматическое открытие последней сесии при запуске Vim без аргументов — очень плохая идея для многих разработчиков дополнений для Vim. Я могу открыть Vim для тестов в любом каталоге, что‐то проверить и потом закрыть. А у вас даже настройки на отключение такого поведения нет.

[@Delphinum]

Просто механизмы не отличаются и можно делать тот же source из живой сессии, как vim_prj, но без vim_prj

Конечно можно, но для этого нужно разобраться, как работают сессии в Vim и как их восстанавливать с помощью source. Думаете все хотят в этом разбираться, вместо того, чтобы установить один плагин? Да и сохранение/восстановление сессии это не единственная задача vim_prj.

А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге, протестировать что-то и потом закрыть? Возможно вы не совсем правильно поняли идею. Сессия восстанавливается плагином только в том случае, если в текущем каталоге есть файл ./.vim/sessions.vim.

[@ZyXI]

Конечно можно, но для этого нужно разобраться, как работают сессии в Vim и как их восстанавливать с помощью source. Думаете все хотят в этом разбираться, вместо того, чтобы установить один плагин? Да и сохранение/восстановление сессии это не единственная задача vim_prj.

Ни в чём не нужно разбираться: в :h :mksession что представляет из себя файл сессии кратко написано прямо в первой строке. А восемь строчек ниже об использовании :source написано уже в явном виде.

А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге, протестировать что-то и потом закрыть?

Зачем?

[@Delphinum]

Ни в чём не нужно разбираться: в :h :mksession что представляет из себя файл сессии кратко написано прямо в первой строке. А восемь строчек ниже об использовании :source написано уже в явном виде

Но программисты, это ленивые люди, не забывайте об этом ;)

Я могу открыть Vim для тестов в любом каталоге

А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге

Зачем?

Вот и мне интересно, зачем?

[@ZyXI]

Затем, чтобы что‐то проверить. Вот сказал кто‐то в vim-dev, что есть в Vim ошибка, надо проверить. Или в моём дополнении ошибка. Или в vim-use задали интересный вопрос, надо бы написать ответ и проверить его. Всё это делается в ближайшем терминале нужных размеров (у меня их три — «на весь экран», «на половину экрана по ширине» — обычно заняты под проекты — и «на 40% экрана по высоте» (yakuake) для сиюминутных нужд, но в последнем не всё удобно проверять из‐за размера).

А для PHPStorm и IntelliJ IDEA я дополнений не пишу и исходный код их не трогаю.

[@Delphinum]

Затем, чтобы что‐то проверить

Ну так открываете Vim и проверяете. Я повторюсь, vim_prj не загружает сессию вне проекта. То есть, если вы открываете Vim в каталоге, в котором нет проекта, никакой сессии загружается не будет.

А для PHPStorm и IntelliJ IDEA я дополнений не пишу и исходный код их не трогаю

То есть, если вы будите писать под PHPStorm и IntelliJ IDEA дополнения и трогать исходные коды, вы попросите от разработчиков отключения принудительного использования проектов? В отличии от PHPStorm и IntelliJ IDEA, vim_prj работает как с проектами, так и без них.

[@ZyXI]

Ну так открываете Vim и проверяете. Я повторюсь, vim_prj не загружает сессию вне проекта. То есть, если вы открываете Vim в каталоге, в котором нет проекта, никакой сессии загружается не будет.

Особенно это актуально если я проверяю что‐то, связанное с проектом и мне не нужны ни сессия, ни каталог без проекта (последнее — в первую очередь по «идеологическому» соображению «всё, связанное с проектом — в одном месте»).

То есть, если вы будите писать под PHPStorm и IntelliJ IDEA дополнения и трогать исходные коды, вы попросите от разработчиков отключения принудительного использования проектов? В отличии от PHPStorm и IntelliJ IDEA, vim_prj работает как с проектами, так и без них.

Я могу приспособится к такому поведению, но скорее я просто не буду под них ничего писать. Хотя и по другим причинам.

[@Delphinum]

Особенно это актуально если я проверяю что‐то, связанное с проектом и мне не нужны ни сессия, ни каталог без проекта

Не сталкивался еще с такой ситуацией, когда нужно было проверить что-то, связанное с проектом, и загрузка сессии этому бы помешала. Отключите плагин vim_prj на время проверки и включите его снова.

Я могу приспособится к такому поведению, но скорее я просто не буду под них ничего писать

Я к тому, что все среды разработки работают только с проектами, загружая автоматом сессию и так далее, а вы придирайтесь к vim_prj, который можно в любой момент отключить и который работает, только внутри проекта )

[@ZyXI]

Не сталкивался еще с такой ситуацией, когда нужно было проверить что-то, связанное с проектом, и загрузка сессии этому бы помешала. Отключите плагин vim_prj на время проверки и включите его снова.

Загрузка сессии помешает, в первую очередь, сообщением «этот файл уже открыт в другом Vim». Во‐вторую, тем, что vim_prj ещё и сохранит потом сессию и в ней будет что‐то ненужное. А «отключение» плохо тем, что для того, чтобы «безопасно» запустить Vim нужно что‐то сделать. Гораздо лучше вариант, когда нужно «опасно» включить vim_prj: например, отключить загрузку и сохранение сессий вообще (такая настройка у вас, как вижу есть), а загружать по команде (а такого нет) и после загрузки включить сохранение.

Кстати, я рекомендую сделать в дополнении автосохранение сессий: у меня, к примеру, довольно длительное время Vim «аварийно завершался» из‐за того, что после hibernate и чего‐то ещё отваливалась файловая система с /home (т.е. Vim я закрыть‐то мог, но vim_prj ничего никуда бы при этом не сохранил), а не из‐за того, что я закрыл проект. Даже не представляю, что это было, но выглядело как ошибка в модуле XFS. Обычно такое делают на основе CursorHold и CursorHoldI событий.

[@Delphinum]

Загрузка сессии помешает, в первую очередь, сообщением «этот файл уже открыт в другом Vim» ...

Не совсем понимаю о чем вы, так как с такими проблемами не сталкивался, хотя и работаю с vim_prj уже довольно долго.

Кстати, я рекомендую сделать в дополнении автосохранение сессий

У меня для этого отдельный плагин vim_write, который автосохраняет проект каждые n секунд, как это делают многие современные IDE.

[@ZyXI]

Не совсем понимаю о чем вы, так как с такими проблемами не сталкивался, хотя и работаю с vim_prj уже довольно долго.

Просто откройте один проект два раза. Предварительно включите в vimrc swap файлы — это обязательное условие.

У меня для этого отдельный плагин vim_write, который автосохраняет проект каждые n секунд, как это делают многие современные IDE.

Он сохраняет файлы, а не сессию.

[@Delphinum]

Просто откройте один проект два раза. Предварительно включите в vimrc swap файлы — это обязательное условие.

Такая эзотерика случается в реальной жизни, или это вакуум и сферический конь?

Он сохраняет файлы, а не сессию

Что гораздо важнее.

[@ZyXI]

Такая эзотерика случается в реальной жизни, или это вакуум и сферический конь?

Если отключить автозагрузку сессии, то — вакуум и сферический конь. Если не отключать и пользоваться Vim как я говорю — для быстрой проверки чего‐то в каталоге проекта, — то такое будет постоянно.

Что гораздо важнее.

Так лучше сохранять и то, и то.

[@Delphinum]

для быстрой проверки чего‐то в каталоге проекта

Так если у вас проект уже открыт и вам нужно что то в нем проверить, зачем открывать его еще раз?

[@ZyXI]

Проект — дополнение к Vim. В него внесены изменения после открытия. Вопрос: какая версия проекта будет проверена в уже открытом Vim? Вопрос 2: нафига мне в «проектном» Vim буферы чисто для тестирования?

[@Delphinum]

Вопрос: какая версия проекта будет проверена в уже открытом Vim?

О какой «версии» проекта и о какой «проверке» идет речь?

нафига мне в «проектном» Vim буферы чисто для тестирования?

Даже предположить не могу, зачем вам буферы чисто для тестирования.

[@ZyXI]

О какой «версии» проекта

Представьте себе файл ~/.vim/autoload/test.vim с содержимым

function test#version()
    return '0.0'
endfunction

Вы запустили echo 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]

Вы запустили echo test#version(), убедились, что Vim выводит 0.0 и изменили 0.0 на 0.1. Что выведет echo test#version(), если Vim вы не перезапускали?

Конечно 0.0. Если мне нужны эти изменения в проекте прямо сейчас, я перезапущу проект, а не открою его занаво. Объясню как я тестирую плагины:

1. Предположим у меня открыты пару проектов, с которыми я сталкиваюсь по работе. Они никак не связаны с разрабатываемым плагином, но не помешало бы использовать плагин и в них тоже
2. Я пишу плагин
3. Я открываю Vim в каталоге ~/tmp/test_vim, там у меня создан проект спецом для тестирования плагинов. Никакой разницы нет, в каком каталоге я открою редактор (часто я делаю это в ~/), просто ~/tmp/test_vim подготовлен так, чтобы с его помощью было легко тестировать новые плагины с учетом проектного уровня загрузки
4. Если что то не так в плагине, я его правлю и перезапускаю проект в ~/tmp/test_vim
5. Повторяю правки и перезапуск
6. Когда плагин готов я лью его на GitHub и перезапускаю те запущенные проекты, в которых этот плагин мне нужен

Не вижу смысла запускать один и тот же проект по нескольку раз.

Кстати, недописанные дополнения могут создавать огромные проблемы при редактировании

Недописанные дополнения у меня глобально не подключены (их нет в ~/.vimrc). Если я их тестирую, я просто подключаю их на уровне ~/tmp/test_vim/.vimrc и работаю с ними там. Другие мои проекты даже не знаю о их существовании.

Простите конечно, но я даже в упор не вижу проблем, о которых вы говорите.

[@ZyXI]

Я открываю Vim в каталоге ~/tmp/test_vim, там у меня создан проект спецом для тестирования плагинов. Никакой разницы нет, в каком каталоге я открою редактор (часто я делаю это в ~/), просто ~/tmp/test_vim подготовлен так, чтобы с его помощью было легко тестировать новые плагины с учетом проектного уровня загрузки

Вот эта часть. Я не держу специальный каталог для тестирования, т.к. в том же терминале, где я делаю «быстрые» тесты я запускаю вещи вроде git rebase или какие‐нибудь перестановки файлов. (Нет, делать это в терминале с открытым проектом неудобно.)

И ещё у меня всегда подключены даже недописанные дополнения: это хорошая гарантия того, что я их‐таки допишу до сколько‐нибудь приличного состояния — просто, чтобы не получать ошибки во время работы.

Не вижу смысла запускать один и тот же проект по нескольку раз.

Я не запускаю один и тот же проект несколько раз. Я запускаю несколько Vim в одном каталоге. И мне очень не нравиться идея отказа от работающего workflow.

[@Delphinum]

Так vim_prj не мешает вам запускать хоть сотню раз Vim в некотором каталоге, главное чтоб в нем не было проектного .vim. Или вам нужно именно сотню раз запустить Vim в одном из проектов?

И ещё у меня всегда подключены даже недописанные дополнения: это хорошая гарантия того, что я их‐таки допишу до сколько‐нибудь приличного состояния

Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )

[@ZyXI]

Так vim_prj не мешает вам запускать хоть сотню раз Vim в некотором каталоге, главное чтоб в нем не было проектного .vim. Или вам нужно именно сотню раз запустить Vim в одном из проектов?

Да, именно в проектном каталоге. Я же ясно написал, что из одного терминала я запускаю и git, и Vim для тестов.

Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )

Покажите, где я удивлялся? У меня всё нормально работает. Но если бы не такая привычка, то некоторые ошибки я бы пропускал в релиз точно.

[@Delphinum]

Да, именно в проектном каталоге. Я же ясно написал, что из одного терминала я запускаю и git, и Vim для тестов.

Я не могу представить как у вас это работает. То есть запускаю я значит мой /var/www/work/ok, пишу там пару контроллеров для учета платежей пользователей, затем (внезапно) переключаюсь к написанию нового плагина под Vim. Когда плагин, на мой взгляд, дописан, я возвращаюсь к открытому редактору в /var/www/work/ok, открываю новый буфер (или в том же буфере, или открываю новый редактор в том же каталоге?) и тестирую новый плагин? Честно говоря, считаю это проблемой подхода к разработке плагинов и использованию Vim, нежели проблемой плагина vim_prj.

Ок, вам понравится, если функцию автозагрузки сессии можно будет отключить?

Покажите, где я удивлялся?

Согласен, не те слова подобрал.

[@ZyXI]

«Проект» — это дополнение для Vim. При чём тут /var/www/work/ok?

У меня открыт, к примеру Vim со всеми файлами из bitbucket.org/ZyX_I/frawor в каталоге ~/.vim/dev/frawor на рабочем столе 3. На том же столе открыт терминал в том же каталоге с tmux с двумя окнами: в правом запускаются автоматические тесты, в левом — ручные тесты и git. Т.к. frawor всегда включён и всегда используется именно разрабатываемая версия, то открытый где бы то ни было Vim позволяет его тестировать. Поэтому используется именно каталог ~/.vim/dev/frawor для тестов по двум причинам: git и лёгкость использования файлов от автоматических тестов для ручного тестирования.

Ок, вам понравится, если функцию автозагрузки сессии можно будет отключить?

Её же и так можно. Просто сделайте команду «загрузить сессию и установить автокоманду для её сохранения».

[@Delphinum]

«Проект» — это дополнение для Vim. При чём тут /var/www/work/ok?

Ну для вас это дополнение для Vim, для меня это любой каталог.

Просто сделайте команду «загрузить сессию и установить автокоманду для её сохранения».

Тогда мне будет не удобно постоянно, открывая некоторый проект, выполнять эту команду. Может сойдемся на флаге, который определяет — загружать ли сессию при открытии проекта автоматом или нет?

[@ZyXI]

Я имею ввиду, что всё остальное уже есть. Я могу отключить автозагрузку уже имеющейся настройкой, но я не могу потом загрузить сессию и включить автосохранение. Отключать автозагрузку вообще я не предлагаю: для проектов‐не‐дополнений так, наоборот, удобнее.

[@Delphinum]

То есть вы хотите открыть проект без загрузки сессии, потом руками загрузкить сессию и включить автосохранение при выходе из проекта?

[@ZyXI]

Да.

[@Delphinum]

Ну вы и извращуга я вам скажу ))

Я добавлю новый флаг vim_prj#.loadsession, который будет определять, загружать ли сессию автоматом или нет. Вы в вашем плагине просто создадите ./.vimrc и добавите в него:

let g:vim_prj#options = {'savesession': 1, 'loadsession': 0}

При этом при открытии вашего плагина сессия загружаться не будет, но будет сохраняться (загрузить ее можно будет с помощью команды VimPrjLoadSession, которую я добавлю). Одновременно все остальные ваши проекты будут загружать сессию автоматически. Пойдет?

[@ZyXI]

Спасибо!

[@Delphinum]

Реализовал.

Автосохранение сессии со временем реализую в vim_write.

[@poxvuibr]

Чувак, ты достучался до моего сердца! Сам очень медленно начинаю добавлять в вим возможности по поддержке проектов и пока что как раз дошёл до необходимости иметь свой .vimrc в директории проекта. У меня там всякие настройки, чтобы пускать сборку и тесты нажатием одной клавиши. Для навигации по файлам пользую CtrlP. Ничего лучше по моему придумать нельзя.
А до сохранения сессий я ещё не дорос.

[@Delphinum]

В будущих статьях расскажу как одной кнопкой не только тестить проект, но и конкретный файл или тест, а так же удобная сборка имеется.

[@poxvuibr]

У меня сборка и запуск тестов исчерпываются асинхронным запуском консольной команды. Выхлоп смотрю в отдельном окне с запущенным tail. Посмотрим как можно ещё.
Но идея держать набор плагинов для каждого проекта реально очень совпадает с тем, что подсказывает мне внутренний голос.

[@Delphinum]

А зачем еще как то, когда и этот вариант вполне приемлим? )

[@poxvuibr]

Ну запуск консольной команды асинхронен, но отвязан от вима. Поэтому к месту возникновения ошибки автоматом не перейти, упавший тест не открыть.

[@Delphinum]

Я еще не реализовал возможность автоматического перехода к упавшим тестам, просто смотрю выхлоп xUnit и открываю нужный файл.

[@Delphinum]

Уже реализовал:

Пример

[@ZyXI]

Кстати, у меня вопрос: а что в коде делает silent!? Особенно с восклицательным знаком и перед so…session.vim. Перемещает ошибки из разряда «увидел — исправил» (или, хотя бы, удалил файл с сессией) в разряд «чё это за х*ня и как её исправить» (хотя, скорее, «vim_prj незаметно потерял буфер с документацией, удалю‐ка я его»: мне сложно представить более критичные ошибки в файле сессии)?

Кстати, s:File.slash практически во всех случаях абсолютно бесполезная вещь. Vim воспринимает / как разделитель компонентов пути всегда. Единственный вариант, когда вам нужен именно «родной» разделитель — передача аргументов в оболочку.

И ещё: это совершенно не дело игнорировать пользовательскую настройку &sessionoptions. Особенно отсутствие в списке globals: некоторые дополнения явно сделали свои настройки сохраняемыми в таком виде.

[@Delphinum]

Перемещает ошибки из разряда «увидел — исправил» в разряд «чё это за х*ня и как её исправить»

Предполагается, что файл сессии создается и восстанавливается Vim без ошибок. Почему там silent! я уже, если честно, не помню.

Кстати, s:File.slash практически во всех случаях абсолютно бесполезная вещь

Сомневался на счет этого, потому таки решил использовать такое решение.

И ещё: это совершенно не дело игнорировать пользовательскую настройку &sessionoptions. Особенно отсутствие в списке globals: некоторые дополнения явно сделали свои настройки сохраняемыми в таком виде

Тут согласен. Поправлю.

[@ZyXI]

Я чаще всего слышал об ошибках при открытии из Vim другой версии либо с другими настройками компиляции (точнее, видел в issue tracker’е NeoVim, т.к. NeoVim имеет несколько другой набор настроек: часть из них просто удалена). Предполагаю (но это не подтверждено), что популярной ошибкой может быть буфер вроде http://example.com (т.е. открываемый с помощью BufRead* команд, не присутствующий в файловой системе). Больше ничего в голову не приходит.

[@ZyXI]

Заметил ещё одну вещь: 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]

VimL вообще имеет массу таких случаев, когда «стандартный» вариант использовать небезопасно или использование которого приведёт к неудобству пользователя: *map/*menu/*abbrev (нужно *nore*, можно ещё добавить <special>, если кого‐то волнуют странные люди в совместимом режиме (set compatible)), normal (нужен восклицательный знак), match*(string, 'regexp') (нужна \c или \C внутри регулярного выражения, это очень характерно практически для всех функций, принимающих регулярные выражения), command (за очень редкими исключениями нужно добавлять -bar), …

[@Delphinum]

Спасибо за замечание.