Comments 53
Для открытия файлов, но не для манипуляций с ними, лучше использовать что‐то вроде Command-T, а не NERDTree. Переход между файлами в этом случае осуществляется гораздо быстрее. Он также отдельно умеет переходить по тёгам (а, если вы знаете Ruby, то и по чему угодно, с помощью очевидных и понятных, но хаков: PR со стандартным интерфейсом для дополнений почему‐то висит; более расширяемой альтернативой является CtrlP, но его исходный код меня ужасает).
Что вы имеете в виду под «манипуляциями с файлами»?
Он работает с использованием Ruby?
Он работает с использованием Ruby?
Как минимум, переименование/перемещение, удаление. Файловый менеджер, как правило, добавляет ещё много своих пунктов вроде создания нового файла, создания архива с выделенным(и) файлом(ами) или создания письма с файлом(ами).
Теоретически, дополнения а‐ля Command-T можно допилить до полноценного файлового менеджера. Но так почему‐то никто не делает.
Теоретически, дополнения а‐ля Command-T можно допилить до полноценного файлового менеджера. Но так почему‐то никто не делает.
И ещё: Command-T не для просмотра структуры проекта и не может быть для него допилен. Всё обозначенное (включая просмотр структуры) я делаю из оболочки.
Т.е., по‐моему, нужны отдельно два дополнения: «быстрый переход» (Command-T) и «файловый менеджер» (тот же NERDTree). Первый также с радостью возьмёт на себя «переход по (примерно) известному имени класса» (но не «переход на определение сущности (класса/переменной/…) под курсором»), «открытие файла в другой программе» (к примеру, в браузере) и вообще любой поиск по любыми примерно известным идентификаторам, полный список которых известен, и любого рода открытие найденных идентификаторов. Если, конечно, нормально расширяем.
Т.е., по‐моему, нужны отдельно два дополнения: «быстрый переход» (Command-T) и «файловый менеджер» (тот же NERDTree). Первый также с радостью возьмёт на себя «переход по (примерно) известному имени класса» (но не «переход на определение сущности (класса/переменной/…) под курсором»), «открытие файла в другой программе» (к примеру, в браузере) и вообще любой поиск по любыми примерно известным идентификаторам, полный список которых известен, и любого рода открытие найденных идентификаторов. Если, конечно, нормально расширяем.
Я не работаю с проектами в vim, но некоторое время назад пробовал реализовать в нём концепцию проекта. Оказалось, в vim действительно для этого всё уже есть. Только вы как-то переусложнили, мне вполне хватало описанного здесь: paul.elms.pro/blog/2014/05/06/vim-projects
Т.е. сессии это и так отдельные конфиги, которые могут и корневую директорию задать, и настройки поменять, и открыть все нужные вкладки и инструменты. Остаётся только добавить удобный способ перечитывать файлы сессий в vim.
Т.е. сессии это и так отдельные конфиги, которые могут и корневую директорию задать, и настройки поменять, и открыть все нужные вкладки и инструменты. Остаётся только добавить удобный способ перечитывать файлы сессий в vim.
На самом деле vim_prj работает точно так же, только запускает сессию не с помощью ключа -S редактора, а с помощью команды :source.
На самом деле ключ -S запускает команду
source, причём даже без экранирования: попробуйте vim -u NONE -i NONE -S '/dev/null | echomsg 123': данная команда отличается от vim -u NONE -i NONE -c 'so /dev/null | echomsg 123' на несколько условных переходов и одно выделение памяти.Я верю, но какая разница, как там все это дело внутри работает? В результате получаем загрузку сессии при открытии проекта с помощью простой команды vim, а не vim -S ~/.vim/sessions/myLastSession.vim
Просто механизмы не отличаются и можно делать тот же source из живой сессии, как vim_prj, но без vim_prj. Вопрос‐то в том, есть в Vim всё, что нужно, или нет.
К тому же, автоматическое открытие последней сесии при запуске Vim без аргументов — очень плохая идея для многих разработчиков дополнений для Vim. Я могу открыть Vim для тестов в любом каталоге, что‐то проверить и потом закрыть. А у вас даже настройки на отключение такого поведения нет.
К тому же, автоматическое открытие последней сесии при запуске Vim без аргументов — очень плохая идея для многих разработчиков дополнений для Vim. Я могу открыть Vim для тестов в любом каталоге, что‐то проверить и потом закрыть. А у вас даже настройки на отключение такого поведения нет.
Просто механизмы не отличаются и можно делать тот же source из живой сессии, как vim_prj, но без vim_prj
Конечно можно, но для этого нужно разобраться, как работают сессии в Vim и как их восстанавливать с помощью source. Думаете все хотят в этом разбираться, вместо того, чтобы установить один плагин? Да и сохранение/восстановление сессии это не единственная задача vim_prj.
А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге, протестировать что-то и потом закрыть? Возможно вы не совсем правильно поняли идею. Сессия восстанавливается плагином только в том случае, если в текущем каталоге есть файл ./.vim/sessions.vim.
Конечно можно, но для этого нужно разобраться, как работают сессии в Vim и как их восстанавливать с помощью source. Думаете все хотят в этом разбираться, вместо того, чтобы установить один плагин? Да и сохранение/восстановление сессии это не единственная задача vim_prj.Ни в чём не нужно разбираться: в
:h :mksession что представляет из себя файл сессии кратко написано прямо в первой строке. А восемь строчек ниже об использовании :source написано уже в явном виде.А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге, протестировать что-то и потом закрыть?Зачем?
Ни в чём не нужно разбираться: в :h :mksession что представляет из себя файл сессии кратко написано прямо в первой строке. А восемь строчек ниже об использовании :source написано уже в явном виде
Но программисты, это ленивые люди, не забывайте об этом ;)
Я могу открыть Vim для тестов в любом каталоге
А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге
Зачем?
Вот и мне интересно, зачем?
Затем, чтобы что‐то проверить. Вот сказал кто‐то в vim-dev, что есть в Vim ошибка, надо проверить. Или в моём дополнении ошибка. Или в vim-use задали интересный вопрос, надо бы написать ответ и проверить его. Всё это делается в ближайшем терминале нужных размеров (у меня их три — «на весь экран», «на половину экрана по ширине» — обычно заняты под проекты — и «на 40% экрана по высоте» (yakuake) для сиюминутных нужд, но в последнем не всё удобно проверять из‐за размера).
А для PHPStorm и IntelliJ IDEA я дополнений не пишу и исходный код их не трогаю.
А для PHPStorm и IntelliJ IDEA я дополнений не пишу и исходный код их не трогаю.
Затем, чтобы что‐то проверить
Ну так открываете Vim и проверяете. Я повторюсь, vim_prj не загружает сессию вне проекта. То есть, если вы открываете Vim в каталоге, в котором нет проекта, никакой сессии загружается не будет.
А для PHPStorm и IntelliJ IDEA я дополнений не пишу и исходный код их не трогаю
То есть, если вы будите писать под PHPStorm и IntelliJ IDEA дополнения и трогать исходные коды, вы попросите от разработчиков отключения принудительного использования проектов? В отличии от PHPStorm и IntelliJ IDEA, vim_prj работает как с проектами, так и без них.
Ну так открываете Vim и проверяете. Я повторюсь, vim_prj не загружает сессию вне проекта. То есть, если вы открываете Vim в каталоге, в котором нет проекта, никакой сессии загружается не будет.Особенно это актуально если я проверяю что‐то, связанное с проектом и мне не нужны ни сессия, ни каталог без проекта (последнее — в первую очередь по «идеологическому» соображению «всё, связанное с проектом — в одном месте»).
То есть, если вы будите писать под PHPStorm и IntelliJ IDEA дополнения и трогать исходные коды, вы попросите от разработчиков отключения принудительного использования проектов? В отличии от PHPStorm и IntelliJ IDEA, vim_prj работает как с проектами, так и без них.Я могу приспособится к такому поведению, но скорее я просто не буду под них ничего писать. Хотя и по другим причинам.
Особенно это актуально если я проверяю что‐то, связанное с проектом и мне не нужны ни сессия, ни каталог без проекта
Не сталкивался еще с такой ситуацией, когда нужно было проверить что-то, связанное с проектом, и загрузка сессии этому бы помешала. Отключите плагин vim_prj на время проверки и включите его снова.
Я могу приспособится к такому поведению, но скорее я просто не буду под них ничего писать
Я к тому, что все среды разработки работают только с проектами, загружая автоматом сессию и так далее, а вы придирайтесь к vim_prj, который можно в любой момент отключить и который работает, только внутри проекта )
Не сталкивался еще с такой ситуацией, когда нужно было проверить что-то, связанное с проектом, и загрузка сессии этому бы помешала. Отключите плагин vim_prj на время проверки и включите его снова.Загрузка сессии помешает, в первую очередь, сообщением «этот файл уже открыт в другом Vim». Во‐вторую, тем, что vim_prj ещё и сохранит потом сессию и в ней будет что‐то ненужное. А «отключение» плохо тем, что для того, чтобы «безопасно» запустить Vim нужно что‐то сделать. Гораздо лучше вариант, когда нужно «опасно» включить vim_prj: например, отключить загрузку и сохранение сессий вообще (такая настройка у вас, как вижу есть), а загружать по команде (а такого нет) и после загрузки включить сохранение.
Кстати, я рекомендую сделать в дополнении автосохранение сессий: у меня, к примеру, довольно длительное время Vim «аварийно завершался» из‐за того, что после hibernate и чего‐то ещё отваливалась файловая система с /home (т.е. Vim я закрыть‐то мог, но vim_prj ничего никуда бы при этом не сохранил), а не из‐за того, что я закрыл проект. Даже не представляю, что это было, но выглядело как ошибка в модуле XFS. Обычно такое делают на основе
CursorHold и CursorHoldI событий.Загрузка сессии помешает, в первую очередь, сообщением «этот файл уже открыт в другом Vim» ...
Не совсем понимаю о чем вы, так как с такими проблемами не сталкивался, хотя и работаю с vim_prj уже довольно долго.
Кстати, я рекомендую сделать в дополнении автосохранение сессий
У меня для этого отдельный плагин vim_write, который автосохраняет проект каждые n секунд, как это делают многие современные IDE.
Не совсем понимаю о чем вы, так как с такими проблемами не сталкивался, хотя и работаю с vim_prj уже довольно долго.Просто откройте один проект два раза. Предварительно включите в vimrc swap файлы — это обязательное условие.
У меня для этого отдельный плагин vim_write, который автосохраняет проект каждые n секунд, как это делают многие современные IDE.Он сохраняет файлы, а не сессию.
Просто откройте один проект два раза. Предварительно включите в vimrc swap файлы — это обязательное условие.
Такая эзотерика случается в реальной жизни, или это вакуум и сферический конь?
Он сохраняет файлы, а не сессию
Что гораздо важнее.
Такая эзотерика случается в реальной жизни, или это вакуум и сферический конь?Если отключить автозагрузку сессии, то — вакуум и сферический конь. Если не отключать и пользоваться Vim как я говорю — для быстрой проверки чего‐то в каталоге проекта, — то такое будет постоянно.
Что гораздо важнее.Так лучше сохранять и то, и то.
для быстрой проверки чего‐то в каталоге проекта
Так если у вас проект уже открыт и вам нужно что то в нем проверить, зачем открывать его еще раз?
Проект — дополнение к Vim. В него внесены изменения после открытия. Вопрос: какая версия проекта будет проверена в уже открытом Vim? Вопрос 2: нафига мне в «проектном» Vim буферы чисто для тестирования?
Вопрос: какая версия проекта будет проверена в уже открытом Vim?
О какой «версии» проекта и о какой «проверке» идет речь?
нафига мне в «проектном» Vim буферы чисто для тестирования?
Даже предположить не могу, зачем вам буферы чисто для тестирования.
О какой «версии» проектаПредставьте себе файл
~/.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 я добавил такую же функциональность.Вы запустили 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 и работаю с ними там. Другие мои проекты даже не знаю о их существовании.
Простите конечно, но я даже в упор не вижу проблем, о которых вы говорите.
Я открываю Vim в каталоге ~/tmp/test_vim, там у меня создан проект спецом для тестирования плагинов. Никакой разницы нет, в каком каталоге я открою редактор (часто я делаю это в ~/), просто ~/tmp/test_vim подготовлен так, чтобы с его помощью было легко тестировать новые плагины с учетом проектного уровня загрузкиВот эта часть. Я не держу специальный каталог для тестирования, т.к. в том же терминале, где я делаю «быстрые» тесты я запускаю вещи вроде git rebase или какие‐нибудь перестановки файлов. (Нет, делать это в терминале с открытым проектом неудобно.)
И ещё у меня всегда подключены даже недописанные дополнения: это хорошая гарантия того, что я их‐таки допишу до сколько‐нибудь приличного состояния — просто, чтобы не получать ошибки во время работы.
Не вижу смысла запускать один и тот же проект по нескольку раз.Я не запускаю один и тот же проект несколько раз. Я запускаю несколько Vim в одном каталоге. И мне очень не нравиться идея отказа от работающего workflow.
Так vim_prj не мешает вам запускать хоть сотню раз Vim в некотором каталоге, главное чтоб в нем не было проектного .vim. Или вам нужно именно сотню раз запустить Vim в одном из проектов?
Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )
И ещё у меня всегда подключены даже недописанные дополнения: это хорошая гарантия того, что я их‐таки допишу до сколько‐нибудь приличного состояния
Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )
Так vim_prj не мешает вам запускать хоть сотню раз Vim в некотором каталоге, главное чтоб в нем не было проектного .vim. Или вам нужно именно сотню раз запустить Vim в одном из проектов?Да, именно в проектном каталоге. Я же ясно написал, что из одного терминала я запускаю и git, и Vim для тестов.
Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )Покажите, где я удивлялся? У меня всё нормально работает. Но если бы не такая привычка, то некоторые ошибки я бы пропускал в релиз точно.
Да, именно в проектном каталоге. Я же ясно написал, что из одного терминала я запускаю и git, и Vim для тестов.
Я не могу представить как у вас это работает. То есть запускаю я значит мой /var/www/work/ok, пишу там пару контроллеров для учета платежей пользователей, затем (внезапно) переключаюсь к написанию нового плагина под Vim. Когда плагин, на мой взгляд, дописан, я возвращаюсь к открытому редактору в /var/www/work/ok, открываю новый буфер (или в том же буфере, или открываю новый редактор в том же каталоге?) и тестирую новый плагин? Честно говоря, считаю это проблемой подхода к разработке плагинов и использованию Vim, нежели проблемой плагина vim_prj.
Ок, вам понравится, если функцию автозагрузки сессии можно будет отключить?
Покажите, где я удивлялся?
Согласен, не те слова подобрал.
«Проект» — это дополнение для Vim. При чём тут /var/www/work/ok?
У меня открыт, к примеру Vim со всеми файлами из bitbucket.org/ZyX_I/frawor в каталоге ~/.vim/dev/frawor на рабочем столе 3. На том же столе открыт терминал в том же каталоге с tmux с двумя окнами: в правом запускаются автоматические тесты, в левом — ручные тесты и git. Т.к. frawor всегда включён и всегда используется именно разрабатываемая версия, то открытый где бы то ни было Vim позволяет его тестировать. Поэтому используется именно каталог ~/.vim/dev/frawor для тестов по двум причинам: git и лёгкость использования файлов от автоматических тестов для ручного тестирования.
У меня открыт, к примеру Vim со всеми файлами из bitbucket.org/ZyX_I/frawor в каталоге ~/.vim/dev/frawor на рабочем столе 3. На том же столе открыт терминал в том же каталоге с tmux с двумя окнами: в правом запускаются автоматические тесты, в левом — ручные тесты и git. Т.к. frawor всегда включён и всегда используется именно разрабатываемая версия, то открытый где бы то ни было Vim позволяет его тестировать. Поэтому используется именно каталог ~/.vim/dev/frawor для тестов по двум причинам: git и лёгкость использования файлов от автоматических тестов для ручного тестирования.
Ок, вам понравится, если функцию автозагрузки сессии можно будет отключить?Её же и так можно. Просто сделайте команду «загрузить сессию и установить автокоманду для её сохранения».
«Проект» — это дополнение для Vim. При чём тут /var/www/work/ok?
Ну для вас это дополнение для Vim, для меня это любой каталог.
Просто сделайте команду «загрузить сессию и установить автокоманду для её сохранения».
Тогда мне будет не удобно постоянно, открывая некоторый проект, выполнять эту команду. Может сойдемся на флаге, который определяет — загружать ли сессию при открытии проекта автоматом или нет?
Я имею ввиду, что всё остальное уже есть. Я могу отключить автозагрузку уже имеющейся настройкой, но я не могу потом загрузить сессию и включить автосохранение. Отключать автозагрузку вообще я не предлагаю: для проектов‐не‐дополнений так, наоборот, удобнее.
То есть вы хотите открыть проект без загрузки сессии, потом руками загрузкить сессию и включить автосохранение при выходе из проекта?
Да.
Ну вы и извращуга я вам скажу ))
Я добавлю новый флаг vim_prj#.loadsession, который будет определять, загружать ли сессию автоматом или нет. Вы в вашем плагине просто создадите ./.vimrc и добавите в него:
При этом при открытии вашего плагина сессия загружаться не будет, но будет сохраняться (загрузить ее можно будет с помощью команды VimPrjLoadSession, которую я добавлю). Одновременно все остальные ваши проекты будут загружать сессию автоматически. Пойдет?
Я добавлю новый флаг vim_prj#.loadsession, который будет определять, загружать ли сессию автоматом или нет. Вы в вашем плагине просто создадите ./.vimrc и добавите в него:
let g:vim_prj#options = {'savesession': 1, 'loadsession': 0}
При этом при открытии вашего плагина сессия загружаться не будет, но будет сохраняться (загрузить ее можно будет с помощью команды VimPrjLoadSession, которую я добавлю). Одновременно все остальные ваши проекты будут загружать сессию автоматически. Пойдет?
Чувак, ты достучался до моего сердца! Сам очень медленно начинаю добавлять в вим возможности по поддержке проектов и пока что как раз дошёл до необходимости иметь свой .vimrc в директории проекта. У меня там всякие настройки, чтобы пускать сборку и тесты нажатием одной клавиши. Для навигации по файлам пользую CtrlP. Ничего лучше по моему придумать нельзя.
А до сохранения сессий я ещё не дорос.
А до сохранения сессий я ещё не дорос.
В будущих статьях расскажу как одной кнопкой не только тестить проект, но и конкретный файл или тест, а так же удобная сборка имеется.
У меня сборка и запуск тестов исчерпываются асинхронным запуском консольной команды. Выхлоп смотрю в отдельном окне с запущенным tail. Посмотрим как можно ещё.
Но идея держать набор плагинов для каждого проекта реально очень совпадает с тем, что подсказывает мне внутренний голос.
Но идея держать набор плагинов для каждого проекта реально очень совпадает с тем, что подсказывает мне внутренний голос.
Кстати, у меня вопрос: а что в коде делает
Кстати, s:File.slash практически во всех случаях абсолютно бесполезная вещь. Vim воспринимает / как разделитель компонентов пути всегда. Единственный вариант, когда вам нужен именно «родной» разделитель — передача аргументов в оболочку.
И ещё: это совершенно не дело игнорировать пользовательскую настройку &sessionoptions. Особенно отсутствие в списке globals: некоторые дополнения явно сделали свои настройки сохраняемыми в таком виде.
silent!? Особенно с восклицательным знаком и перед so…session.vim. Перемещает ошибки из разряда «увидел — исправил» (или, хотя бы, удалил файл с сессией) в разряд «чё это за х*ня и как её исправить» (хотя, скорее, «vim_prj незаметно потерял буфер с документацией, удалю‐ка я его»: мне сложно представить более критичные ошибки в файле сессии)?Кстати, s:File.slash практически во всех случаях абсолютно бесполезная вещь. Vim воспринимает / как разделитель компонентов пути всегда. Единственный вариант, когда вам нужен именно «родной» разделитель — передача аргументов в оболочку.
И ещё: это совершенно не дело игнорировать пользовательскую настройку &sessionoptions. Особенно отсутствие в списке globals: некоторые дополнения явно сделали свои настройки сохраняемыми в таком виде.
Перемещает ошибки из разряда «увидел — исправил» в разряд «чё это за х*ня и как её исправить»
Предполагается, что файл сессии создается и восстанавливается Vim без ошибок. Почему там silent! я уже, если честно, не помню.
Кстати, s:File.slash практически во всех случаях абсолютно бесполезная вещь
Сомневался на счет этого, потому таки решил использовать такое решение.
И ещё: это совершенно не дело игнорировать пользовательскую настройку &sessionoptions. Особенно отсутствие в списке globals: некоторые дополнения явно сделали свои настройки сохраняемыми в таком виде
Тут согласен. Поправлю.
Я чаще всего слышал об ошибках при открытии из Vim другой версии либо с другими настройками компиляции (точнее, видел в issue tracker’е NeoVim, т.к. NeoVim имеет несколько другой набор настроек: часть из них просто удалена). Предполагаю (но это не подтверждено), что популярной ошибкой может быть буфер вроде
http://example.com (т.е. открываемый с помощью BufRead* команд, не присутствующий в файловой системе). Больше ничего в голову не приходит.Заметил ещё одну вещь:
У последнего случая своя специфика: во‐первых, данные операторы безопасны тем, что
Хорошей привычкой является писать безопасные операторы всегда, даже если строка на одной стороне «безопасна» (т.е. не содержит букв, которые имеют uppercase и lowercase варианты): так не нужно думать о том, какой оператор поставить именно здесь. Сравнение с $HOME, которое я нашёл, кстати, таким случаем не является.
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, которое я нашёл, кстати, таким случаем не является.
VimL вообще имеет массу таких случаев, когда «стандартный» вариант использовать небезопасно или использование которого приведёт к неудобству пользователя:
*map/*menu/*abbrev (нужно *nore*, можно ещё добавить <special>, если кого‐то волнуют странные люди в совместимом режиме (set compatible)), normal (нужен восклицательный знак), match*(string, 'regexp') (нужна \c или \C внутри регулярного выражения, это очень характерно практически для всех функций, принимающих регулярные выражения), command (за очень редкими исключениями нужно добавлять -bar), …Sign up to leave a comment.
Vim по полной: Уровень проекта и файловая система