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

    Оглавление


    1. Введение (vim_lib)
    2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
    3. Уровень проекта и файловая система (vim_prj, nerdtree)
    4. Snippets и шаблоны файлов (UltiSnips, vim_template)
    5. Компиляция и выполнение чего угодно (vim-quickrun)
    6. Работа с Git (vim_git)
    7. Деплой (vim_deploy)
    8. Тестирование с помощью xUnit (vim_unittest)
    9. Библиотека, на которой все держится (vim_lib)
    10. Другие полезные плагины


    Проекты, это то, чего очень не хватает редактору 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).
    Пример создаваемого .vimrc
    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 для использования другими плагинами.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 53

      0
      Для открытия файлов, но не для манипуляций с ними, лучше использовать что‐то вроде Command-T, а не NERDTree. Переход между файлами в этом случае осуществляется гораздо быстрее. Он также отдельно умеет переходить по тёгам (а, если вы знаете Ruby, то и по чему угодно, с помощью очевидных и понятных, но хаков: PR со стандартным интерфейсом для дополнений почему‐то висит; более расширяемой альтернативой является CtrlP, но его исходный код меня ужасает).
        0
        Что вы имеете в виду под «манипуляциями с файлами»?

        Он работает с использованием Ruby?
          0
          Как минимум, переименование/перемещение, удаление. Файловый менеджер, как правило, добавляет ещё много своих пунктов вроде создания нового файла, создания архива с выделенным(и) файлом(ами) или создания письма с файлом(ами).

          Теоретически, дополнения а‐ля Command-T можно допилить до полноценного файлового менеджера. Но так почему‐то никто не делает.
            0
            NerdTree умеет перемещать, переименовывать, создавать и удалять файлы. К сожалению в нем нет API, позволяющего связать его, на пример, с Git
              0
              Я как‐то начал создавать дополнение с более расширяемым API. Только забросил из‐за его бесполезности для меня: zsh удобнее.

              // Да, NERDTree это умеет. Но я говорил не о том, что (не) умеет NERDTree, а о том, что для открытия файлов хорошо бы найти что‐то другое, и это что‐то — не файловый менеджер.
            0
            И ещё: Command-T не для просмотра структуры проекта и не может быть для него допилен. Всё обозначенное (включая просмотр структуры) я делаю из оболочки.

            Т.е., по‐моему, нужны отдельно два дополнения: «быстрый переход» (Command-T) и «файловый менеджер» (тот же NERDTree). Первый также с радостью возьмёт на себя «переход по (примерно) известному имени класса» (но не «переход на определение сущности (класса/переменной/…) под курсором»), «открытие файла в другой программе» (к примеру, в браузере) и вообще любой поиск по любыми примерно известным идентификаторам, полный список которых известен, и любого рода открытие найденных идентификаторов. Если, конечно, нормально расширяем.
          0
          Я не работаю с проектами в vim, но некоторое время назад пробовал реализовать в нём концепцию проекта. Оказалось, в vim действительно для этого всё уже есть. Только вы как-то переусложнили, мне вполне хватало описанного здесь: paul.elms.pro/blog/2014/05/06/vim-projects

          Т.е. сессии это и так отдельные конфиги, которые могут и корневую директорию задать, и настройки поменять, и открыть все нужные вкладки и инструменты. Остаётся только добавить удобный способ перечитывать файлы сессий в vim.
            0
            На самом деле vim_prj работает точно так же, только запускает сессию не с помощью ключа -S редактора, а с помощью команды :source.
              0
              На самом деле ключ -S запускает команду source, причём даже без экранирования: попробуйте vim -u NONE -i NONE -S '/dev/null | echomsg 123': данная команда отличается от vim -u NONE -i NONE -c 'so /dev/null | echomsg 123' на несколько условных переходов и одно выделение памяти.
                0
                Я верю, но какая разница, как там все это дело внутри работает? В результате получаем загрузку сессии при открытии проекта с помощью простой команды vim, а не vim -S ~/.vim/sessions/myLastSession.vim
                  0
                  Просто механизмы не отличаются и можно делать тот же source из живой сессии, как vim_prj, но без vim_prj. Вопрос‐то в том, есть в Vim всё, что нужно, или нет.

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

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

                    А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге, протестировать что-то и потом закрыть? Возможно вы не совсем правильно поняли идею. Сессия восстанавливается плагином только в том случае, если в текущем каталоге есть файл ./.vim/sessions.vim.
                      0
                      Конечно можно, но для этого нужно разобраться, как работают сессии в Vim и как их восстанавливать с помощью source. Думаете все хотят в этом разбираться, вместо того, чтобы установить один плагин? Да и сохранение/восстановление сессии это не единственная задача vim_prj.
                      Ни в чём не нужно разбираться: в :h :mksession что представляет из себя файл сессии кратко написано прямо в первой строке. А восемь строчек ниже об использовании :source написано уже в явном виде.

                      А вы можете открыть, скажем PHPStorm или IntelliJ IDEA в любом каталоге, протестировать что-то и потом закрыть?
                      Зачем?
                        0
                        Ни в чём не нужно разбираться: в :h :mksession что представляет из себя файл сессии кратко написано прямо в первой строке. А восемь строчек ниже об использовании :source написано уже в явном виде

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

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

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

                        Зачем?

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

                          А для PHPStorm и IntelliJ IDEA я дополнений не пишу и исходный код их не трогаю.
                            0
                            Затем, чтобы что‐то проверить

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

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

                            То есть, если вы будите писать под PHPStorm и IntelliJ IDEA дополнения и трогать исходные коды, вы попросите от разработчиков отключения принудительного использования проектов? В отличии от PHPStorm и IntelliJ IDEA, vim_prj работает как с проектами, так и без них.
                              0
                              Ну так открываете Vim и проверяете. Я повторюсь, vim_prj не загружает сессию вне проекта. То есть, если вы открываете Vim в каталоге, в котором нет проекта, никакой сессии загружается не будет.
                              Особенно это актуально если я проверяю что‐то, связанное с проектом и мне не нужны ни сессия, ни каталог без проекта (последнее — в первую очередь по «идеологическому» соображению «всё, связанное с проектом — в одном месте»).
                              То есть, если вы будите писать под PHPStorm и IntelliJ IDEA дополнения и трогать исходные коды, вы попросите от разработчиков отключения принудительного использования проектов? В отличии от PHPStorm и IntelliJ IDEA, vim_prj работает как с проектами, так и без них.
                              Я могу приспособится к такому поведению, но скорее я просто не буду под них ничего писать. Хотя и по другим причинам.
                                0
                                Особенно это актуально если я проверяю что‐то, связанное с проектом и мне не нужны ни сессия, ни каталог без проекта

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

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

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

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

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

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

                                    У меня для этого отдельный плагин vim_write, который автосохраняет проект каждые n секунд, как это делают многие современные IDE.
                                      0
                                      Не совсем понимаю о чем вы, так как с такими проблемами не сталкивался, хотя и работаю с vim_prj уже довольно долго.
                                      Просто откройте один проект два раза. Предварительно включите в vimrc swap файлы — это обязательное условие.
                                      У меня для этого отдельный плагин vim_write, который автосохраняет проект каждые n секунд, как это делают многие современные IDE.
                                      Он сохраняет файлы, а не сессию.
                                        0
                                        Просто откройте один проект два раза. Предварительно включите в vimrc swap файлы — это обязательное условие.

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

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

                                        Что гораздо важнее.
                                          0
                                          Такая эзотерика случается в реальной жизни, или это вакуум и сферический конь?
                                          Если отключить автозагрузку сессии, то — вакуум и сферический конь. Если не отключать и пользоваться Vim как я говорю — для быстрой проверки чего‐то в каталоге проекта, — то такое будет постоянно.
                                          Что гораздо важнее.
                                          Так лучше сохранять и то, и то.
                                            0
                                            для быстрой проверки чего‐то в каталоге проекта

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

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

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

                                                Даже предположить не могу, зачем вам буферы чисто для тестирования.
                                                  0
                                                  О какой «версии» проекта
                                                  Представьте себе файл ~/.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 я добавил такую же функциональность.
                                                    0
                                                    Вы запустили 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 и работаю с ними там. Другие мои проекты даже не знаю о их существовании.

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

                                                      И ещё у меня всегда подключены даже недописанные дополнения: это хорошая гарантия того, что я их‐таки допишу до сколько‐нибудь приличного состояния — просто, чтобы не получать ошибки во время работы.
                                                      Не вижу смысла запускать один и тот же проект по нескольку раз.
                                                      Я не запускаю один и тот же проект несколько раз. Я запускаю несколько Vim в одном каталоге. И мне очень не нравиться идея отказа от работающего workflow.
                                                        0
                                                        Так vim_prj не мешает вам запускать хоть сотню раз Vim в некотором каталоге, главное чтоб в нем не было проектного .vim. Или вам нужно именно сотню раз запустить Vim в одном из проектов?

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

                                                        Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )
                                                          0
                                                          Так vim_prj не мешает вам запускать хоть сотню раз Vim в некотором каталоге, главное чтоб в нем не было проектного .vim. Или вам нужно именно сотню раз запустить Vim в одном из проектов?
                                                          Да, именно в проектном каталоге. Я же ясно написал, что из одного терминала я запускаю и git, и Vim для тестов.
                                                          Может стоит таки дописать плагины, а не подключать кучу недописанного и удивляться, что Vim как то не очень работает? )
                                                          Покажите, где я удивлялся? У меня всё нормально работает. Но если бы не такая привычка, то некоторые ошибки я бы пропускал в релиз точно.
                                                            0
                                                            Да, именно в проектном каталоге. Я же ясно написал, что из одного терминала я запускаю и git, и Vim для тестов.

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

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

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

                                                            Согласен, не те слова подобрал.
                                                              0
                                                              «Проект» — это дополнение для Vim. При чём тут /var/www/work/ok?

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

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

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

                                                                Тогда мне будет не удобно постоянно, открывая некоторый проект, выполнять эту команду. Может сойдемся на флаге, который определяет — загружать ли сессию при открытии проекта автоматом или нет?
                                                                  0
                                                                  Я имею ввиду, что всё остальное уже есть. Я могу отключить автозагрузку уже имеющейся настройкой, но я не могу потом загрузить сессию и включить автосохранение. Отключать автозагрузку вообще я не предлагаю: для проектов‐не‐дополнений так, наоборот, удобнее.
                                                                    0
                                                                    То есть вы хотите открыть проект без загрузки сессии, потом руками загрузкить сессию и включить автосохранение при выходе из проекта?
                                                                      0
                                                                      Да.
                                                                        0
                                                                        Ну вы и извращуга я вам скажу ))

                                                                        Я добавлю новый флаг vim_prj#.loadsession, который будет определять, загружать ли сессию автоматом или нет. Вы в вашем плагине просто создадите ./.vimrc и добавите в него:
                                                                        let g:vim_prj#options = {'savesession': 1, 'loadsession': 0}
                                                                        

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

                                                                            Автосохранение сессии со временем реализую в vim_write.
            0
            Чувак, ты достучался до моего сердца! Сам очень медленно начинаю добавлять в вим возможности по поддержке проектов и пока что как раз дошёл до необходимости иметь свой .vimrc в директории проекта. У меня там всякие настройки, чтобы пускать сборку и тесты нажатием одной клавиши. Для навигации по файлам пользую CtrlP. Ничего лучше по моему придумать нельзя.
            А до сохранения сессий я ещё не дорос.
              0
              В будущих статьях расскажу как одной кнопкой не только тестить проект, но и конкретный файл или тест, а так же удобная сборка имеется.
                0
                У меня сборка и запуск тестов исчерпываются асинхронным запуском консольной команды. Выхлоп смотрю в отдельном окне с запущенным tail. Посмотрим как можно ещё.
                Но идея держать набор плагинов для каждого проекта реально очень совпадает с тем, что подсказывает мне внутренний голос.
                  0
                  А зачем еще как то, когда и этот вариант вполне приемлим? )
                    0
                    Ну запуск консольной команды асинхронен, но отвязан от вима. Поэтому к месту возникновения ошибки автоматом не перейти, упавший тест не открыть.
                      0
                      Я еще не реализовал возможность автоматического перехода к упавшим тестам, просто смотрю выхлоп xUnit и открываю нужный файл.
                        0
                        Уже реализовал:
                        Пример

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

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

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

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

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

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

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

                  Тут согласен. Поправлю.
                    0
                    Я чаще всего слышал об ошибках при открытии из Vim другой версии либо с другими настройками компиляции (точнее, видел в issue tracker’е NeoVim, т.к. NeoVim имеет несколько другой набор настроек: часть из них просто удалена). Предполагаю (но это не подтверждено), что популярной ошибкой может быть буфер вроде http://example.com (т.е. открываемый с помощью BufRead* команд, не присутствующий в файловой системе). Больше ничего в голову не приходит.
                  0
                  Заметил ещё одну вещь: 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, которое я нашёл, кстати, таким случаем не является.
                    0
                    VimL вообще имеет массу таких случаев, когда «стандартный» вариант использовать небезопасно или использование которого приведёт к неудобству пользователя: *map/*menu/*abbrev (нужно *nore*, можно ещё добавить <special>, если кого‐то волнуют странные люди в совместимом режиме (set compatible)), normal (нужен восклицательный знак), match*(string, 'regexp') (нужна \c или \C внутри регулярного выражения, это очень характерно практически для всех функций, принимающих регулярные выражения), command (за очень редкими исключениями нужно добавлять -bar), …
                      0
                      Спасибо за замечание.

                  Only users with full accounts can post comments. Log in, please.