26 августа 2015 в 10:05

Vim как не IDE из песочницы

Очень давно хотел написать что-нибудь полезное, но не знал, чем можно поделится, и тут наткнулся на очередную статью про рассуждения, что же все-таки лучше — vim, emacs или IDE? Сначала я хотел написать сравнение IDE и vim, но слишком мало пользовался IDE и боюсь быть необъективным. Поэтому просто опишу причины, по которым использую vim. Просто чтобы показать, что редакторы занимают свою нишу. Также попробую рассказать о проблемах, с которыми я столкнулся, используя vim, и как я их решал.

Как я встретил Vim


Я поклонник *nix-like систем и слышал, что в каждой такой системе по умолчанию всегда есть vi (хотя, бывает, что не всегда). И однажды мне нужно было написать программу на си для известного linux-дистрибутива, вопрос про использованию IDE не стоял — я просто открыл vi и частенько открывая шпаргалку начал писать код. Сразу замечу, что тогда пользовался vim как обычным редактором и не пользовался всей силой командного режима.

Время мелких программ прошло, теперь все по серьёзному


То было прекрасное время студенчества, теперь я инженер. Так сложилось, что технологический стек выбирать не приходилось и писать я стал на php. Всем прекрасно известно, что одной из лучших IDE для php является PHPStorm, хотя есть еще много других, в том числе и бесплатных. Однако все мои коллеги как один рекомендовали мне PHPStorm и я не стал пропускать мимо ушей советы более опытных разработчиков. Эта IDE действительно хороша, в ней есть все, что нужно web-разработчику, но была проблема: IDE очень медленно работала.

Скорость работы никуда не годилась. В моем распоряжении был ноутбук с intel core 2 duo (2 ядра по 2.4 Ghz, если я правильно помню) 3 GB RAM и HDD. Денег на новое железо нет, зарплата у junior'а не высокая и кредиты брать не хочется, да и вряд ли дадут.

Проект состоял из ~1,5 GB исходников, БД на Oracle и использовал некоторые специфичные библиотеки. А так же имел очень большие ресурсные файлы (XML), которые приходилось править руками.

PHPStorm ужасно лагал, он долго запускался, долго производил поиск, даже повисал когда я просто редактировал текст, больше XML он просто не мог открыть.

И снова Vim


Первое что стоит сказать о vim, что без написания конфига и дополнительных плагинов программировать в нем нормально нельзя. Но если все настроить, то жить можно. И второе, vim — это не IDE и делать из него IDE не стоит. Даже если прикрутить сотню плагинов, то он не будет таким же как PHPStorm или <твоя IDE могла быть здесь>.

Редактор для редактирования, но...

Но разработка — это не только редактирование кода, это анализ, рефакторинг, отладка, перемещение по файлам и прочее.

Итак, проблемы

Мне хотелось видеть файлы проекта в виде древовидной структуры

Эту проблему я решил плагином (NERDTree), в нем можно видеть дерево файлов, производить манипуляции над ними и прочее, но так же в vim есть и встроенный файловый менеджер.

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

Статический анализ кода и отображение его результатов в редактор оказалось тоже простой задачей, так же решаемой плагином, причем для любого известного мне ЯП.

Иметь быстрый поиск файлов и иметь быстрый поиск по файлам

Для поиска по файлам я использую vimgrep или ack, может быть это не так эффективно, как в IDE, но даже в огромном проекте работают довольно шустро. Поиск самих файлов и их открытие на редактирование так же можно делать связкой команд find или grep + vim или прямо в vim через плагин (например, ctrlp).

Запускать отладчик из редактора

С отладчиком мне подружить vim так и не удалось. Вернее есть плагин для связи с xdebug, но пользоваться им не очень удобно, однако ценность этого инструмента у меня сводилась к минимуму, callstack и так посмотреть можно, а остальное дело техники. Сейчас я уже не пишу на php и в качестве отладчиков использую консольные инструменты (аналоги gdb) и их хватает.

Иметь инструмент инспекции кода

Инспекция кода вещь не такая нужная как может казаться, у меня есть плагин (tagbar), но я крайне редко его использую.

Перемещаться к определению метода или класса

Нормальное перемещение к определение работает только с си и его производными, для php, ruby, python и т.д. у меня не получилось настроить, но я очень быстро привык использовать ack и vimgrep.

Иметь автокомплит привязанный к проекту

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

Поддержка нескольких языков

Включение поддержки нового языка обычно решается подключением соответствующего плагина, к примеру, для golang достаточно подключить один плагин, который умеет все (от подсветки до статического анализа и автоформатирования).

Работа с очень большими файлами

Vim хорошо работает с большими файлами из коробки, но для гигантских файлов тоже есть плагин (LargeFile), при его использовании можно даже гигабайтные файлы открывать и ничего не зависнет.

Автоформатирование кода

Автоформатирование кода есть из коробки и оно автоматические подцепляет настройки из плагинов для разных языков.

Интеграция систем контроля версий

Я использую git и делаю я это в bash, но для кое-каких операций поставил пару плагинов (vim-fugitive, nerdtree-git-plugin).

Редактирование как оно есть

Самая важная особенность vim это режимы. Их много, но самый главный — это normal, или командный режим. После какого-то времени, пусть и продолжительного (2-3 месяца) я практически полностью редактирую код в командном режиме. Конечно, перехожу в режим вставки, когда надо что-то написать, но в остальном я использую команды. Это позволяет не отрывать руки от клавиатуры и через какое-то время ты перестаешь думать о том, как тебе редактировать код и полностью можешь сосредоточится на том, какие изменения требуется внести. Пожалуй, самый удачный пример — это рояль, когда ты научишься на нем играть, ты начинаешь думать только о музыке, а не о том, на какие клавиши жать. И я точно могу сказать, что горячие клавиши не дадут такой результат (очень долго пытался — не получилось).

Подводя итог


В тех условиях, в которых я работал, со слабым железом и огромным проектом, пользоваться IDE было мукой, но связка стандартных *nix-инструментов и vim позволила решать все задачи, которые вставали передо мной. Сейчас я так же работаю в vim, но уже из-за того, что не хочу переучиваться и менять привычную среду, которая себя хорошо показала. С течением времени я работаю все более и более эффективно, т.к. vim и *nix-системы — это вещи, которые можно изучать очень долго и постоянно находить новые методы решения тех или иных проблем.

И если вам не хочется использовать IDE или нет денег на крутую платную версию, я рекомендую вам попробовать поработать в редакторах, таких как vim и emacs. Если вы поймете их идеологию и она окажется вам близка, то вы не будете испытывать никаких проблем с работой над кодом.

Но надо сказать, что это все актуально для меня как для backend-разработчика, возможно, для разработки GUI-приложений или frontend, редактором ограничится не получится.
@rutaka_n
карма
6,0
рейтинг 0,0
software engineer
Похожие публикации
Самое читаемое Разработка

Комментарии (80)

  • +7
    В свое время тоже мучился от тормознутости IDE. Но вместо настройки и поиска плагинов для текстового редактора потратил 100$ на память. А позже и на новый ноут. Мне кажется, что если вы способны справиться с vim, то подобные затраты для вас не должны быть проблемой. Хотя с другой стороны, подозреваю, что все это доставило вам немало удовольствия.
    • +1
      Не забывайте еще, что vim-ом удобно пользоваться удаленно, даже на тощем канале и он есть практически на любой *nix-машине, и тогда достаточно только вытащить на неё свой конфиг (я еще беру питоновский файл, который вытаскивает все нужные плагины), и уже работаешь в удобном и комфортном окружении.
      • –1
        А резве кто-то занимается разработкой удаленно на сервере? Да еще и на медленном канале?
        Если уже очень надо, то в IDE есть выгрузка изменений на сервер. И даже удаленная отладка.

        Мы все правки вносим через git. Если очень надо что-то попробовать на тестовом сервере, то у меня всегда подмонтирована его веб-директория и есть gedit. В крайнем случае ssh + nano либо mc.
        И да, на наших серверах нет vim ;)
        • 0
          Кроме разработки, есть еще куча разных операций, которые приходится делать удаленно, это раз.

          Два — иногда приходится работать из не самых удачных точек, например я как-то работал из паба на Мальте :) Или из чайной в Китае.

          IDE с выгрузкой на сервер — это лишние действия и потерянное время…

          Гит вы вообще непонятно к чему приплели, или вы и при отладке на тестовом окружении все коммитите в общий гит? :)

          А мне вот не надо этих крайних случаев с неудобными редакторами, у меня есть vim :)

          Сочуствую тем кому приходится работать «на ваших серверах» :)
          • –1
            В статье сравнивается vim с IDE, значит речь о разработке. Или вы используете IDE для правки конфигов?

            По поводу работы из неудачных точек, то по своему опыту скажу, что править файл через ssh даже хуже чем локальным редактором из подмонтированного раздела (задержки на переводе курсора не слишком располагают к работе). Ну и в конце концов — это крайний случай.

            По поводу git — рабработка фич ведется в отдельных ветках, все правки можно коммитить, а перед слитием в девелоп объеденить их в один. Хотя на самом деле все делается локально, а на один из тестовых серверов выгружается только для тестов готового функционала. Выгрузка производиться из git-a. Правка чего либо прямо на сервере — крайний случай для которого годятся описанные мной варианты (и не требуют недель на изучение редактора).

            На сколько я понимаю, vim хорош если вы ведете разработку прямо на сервере через медленный инет. Сочувствую.
            • –1
              Мда, вам похоже лишь бы поборцевать. Не вижу смысла в дальнейшей беседе.
  • +2
    Да, по большому счёту, если сравнивать с IDE, то в Vim нет возможности удобно подключить отладчик и нет действительно умного и качественного автодополнения для динамических языков. Первое не так актуально, как кажется (можно запускать отладчик в отдельном окне, да и вообще лично я необходимость запустить отладчик чувствую примерно один раз в год — в остальных сложных случаях я нахожу баг print-ами за пару минут), второе неплохо компенсируется простым автодополнением по тем словам которые уже встречались в текущем файле или всём проекте.

    Но главное в Vim вовсе не то, есть проверка синтаксиса и быстрый переход на определение функции или нет! В соседнем топике любители IDE издевались над фразами вроде «3 месяца настраивал Vim», рассказывая как у них на настройку IDE уходит несколько минут… Но фишка в том, что Vim и Emacs можно настроить под себя. Да, на это может уйти куча времени, но редактор — это один из основных рабочих инструментов, и время потраченное на затачивание его под себя окупается сторицей.
    • +9
      Однажды на даче я нанял мастера, чтобы он построил забор. Когда приехал через неделю, обнаружил, что он напильником выпиливает себе молоток.
      • +3
        IDE порой тоже доставляет ряд неудобств. Как-то из-за обновления стороннего плагина у меня перестала запускаться IDE, переустановка не помогала. Целый день мне пришлось использовать vim, поскольку саппорт не мог сразу поставить диагноз и помочь решить проблему.

        Вот например сейчас, я не могу переименовать файл, поскольку идет переиндексация проекта:

        • +1
          Данная операция происходит примерно секунду при переключении ветки в проекте на ~100мб.
          При первом запуске проекта и установке зависимостей, конечно, подольше, но данную операцию вы навряд ли будете делать чаще раза в месяц.
          • 0
            У меня эта операция занимает не меньше 5-10 минут и происходит это регулярно!
            И да, проблема в том, что проект монтируется, а не лежит локально (нет технической возможности).
            • +1
              Нет технической возможности держать исходники проекта локально? Это как?
              Я бывал в ситуации, когда не было возможности исполнять код локально, проблема решалась авто-загрузкой файлов при изменении, на скорость индексации это не влияло, само-собой.
              • –1
                Исходники лежат на удаленной машине, потому что их файловая структура и зависимости завязаны на окружение конкретной машины.
                Проект монтируется по smb или sshfs. Подключить другим способом пока не удалось, поскольку мы используем сессионный токен.
                • +1
                  Кажется, если можно монтировать по sshfs, то и просто по ssh доступ должен быть, или я ошибаюсь?
                  • –1
                    Доступ по ssh конечно есть, но проект приходится монтировать, из-за этого скорость индексации сильно снижается.
                    • +2
                      Вот, можно же не монтировать, а скачать исходники на локальную машину и настроить в IDE подключение по ssh, чтобы она сама измененные файлы закачивала на сервер.
                      • –1
                        Мы пробовали, ничего не вышло. :D
                        Если мне не изменяет память, регулярно пропадал коннект и требовалось заново ввести сессионный ключ в настройках. В общем еще больше мучений.
                        • +2
                          Понятно, странно.
                          • 0
                            Кажется, что работа с удалённым хранилищем это действительно тот случай, когда лучше пользоваться редакторами, а не IDE, и это отнюдь не камень в сторону IDE. Это просто не область его применения.
                            • 0
                              Наверное, все зависит от личного опыта. У меня не было проблем с IDE в такой же ситуации, поэтому другое мнение про область применения.
      • +4
        Вас обманули, это оказался не мастер!
      • +7
        Однажды на даче я нанял мастера, чтобы он устранил утечки тепла, тк дом быстро промерзал.

        Когда приехал через неделю, обнаружил, что он решил проблему установкой трёх дополнительных обогревателей.
        • +2
          Однажды на даче я нанял мастера, чтобы он заштукатурил мне стены.

          Когда приехал через неделю, мастер попросил купить новую дачу, так как в этой было мало места и ему было не удобно работать.
        • 0
          Ну так ведь создание собственной модели тепловизора для обнаружения утечек дело не простое и долгое. Надо же как-то греться все это время ;)
          • 0
            Я думаю Cheater намекает вот на это:
            немного ностальгии

      • –1
        Вам не повезло. Вы у него первый. В следующих заказах у него уже будет идеальный молоток.
        • 0
          Золотой молоток, который умеет смешивать раствор? )
          • 0
            Зависит от умений мастера. =)
  • 0
    Про рефакторинг кода забыли упомянуть.
    Например, в следующем примере делать шаблонную автозамену строки во всем файле будет безрассудством, а если править руками, то тоже можно что-то пропустить.

    Было:
    std::string string (const std::string &string) {
        return string;
    }
    
    string("test");
    


    Стало:

    std::string text (const std::string &value) {
        return value;
    }
    
    text("test");
    
    • +2
      Зависит от языка. Например, для Go такое работает (плагин vim-go, команда :GoRename). А для динамических языков — да, только ручками и внимательно, делать массовый search&replace стрёмно. Но наличие автоматической проверки синтаксиса и юнит-тестов обычно делает эту задачу не такой сложной.
      • +3
        А я собственно не являюсь сторонником ни IDE, ни редакторов.
        Глупо даже обсуждать, что лучше использовать. Если у меня не работает IDE я открываю Vim.
        Мои предпочтения зависят от ситуации.
  • +1
    Первое время, когда начинал работать с рельсами, то использовал RubyMine, но потом «старшие парни» показали Vim. Я потратил много времени на его настройку под себя, но сейчас не могу перейти на какую-то IDE, я просто влюбился в него. Очень приятно, что при работе с рельсами даже консоль не обязательно открывать. Почти все фичи можно прикрутить к нему. Сейчас даже на хабре перемещаюсь используя навигационные кнопки Vim'а.
  • 0
    И второе, vim — это не IDE и делать из него IDE не стоит.

    Почему вы так считаете?
    • 0
      Идеологически IDE — Integrated Development Environment, то есть «всё включено», а vim эффективен вместе с другими *nix-инструментами и интегрировать их в него особо нет смысла, т.к. они уже под рукой.
      • 0
        vim эффективен вместе с другими *nix-инструментами

        То есть Vim для Windows вы хороните сразу? )) А как же горячие клавиши для работы с этими инструментами?
        Идеологически IDE — Integrated Development Environment, то есть «всё включено»

        Таки IDE это еще и синтаксический анализатор, который встроен в редактор.
        • 0
          В WinNT-системы портирован bash и большая часть(если не все) core-utils, однако лично мне в windows не удобно и я им не пользуюсь, т.к. пишу ПО только под *nix-системы.
          А горячие клавиши для работы с инструментами это лишь один из вариантов использования, другой это команды.

          Кому как удобнее — у разных вещей, методов, идеологий разные приверженцы.
          • 0
            А горячие клавиши для работы с инструментами это лишь один из вариантов использования, другой это команды

            Ну редачить файл тоже можно командами, только это дольше.
            • 0
              Ну редачить файл тоже можно командами, только это дольше.

              Дольше, если делать это не в vim.
              • 0
                А как Vim ускоряет набор команд?
                • 0
                  А как Vim ускоряет набор команд?

                  Имею в виду командный режим(normal mode)
                  • 0
                    Тогда возвращаюсь к вашему коменту:
                    А горячие клавиши для работы с инструментами это лишь один из вариантов использования, другой это команды

                    и говорю, что для нормального использования сторонних *nix-утилит нужно настраивать эти самые команды (которые есть горячие клавиши). Так что без интегрирования некоторых утилит прямо в Vim (через горячие клавиши, плагины и т.д.), использовать его становится не так удобно.
                    • 0
                      Команды <> горячие клавиши.
                      А утилиты можно вызывать из оболочки, т.е. никакой интеграции производить не надо.
                      • 0
                        Команды <> горячие клавиши.

                        Почему же?
                        А утилиты можно вызывать из оболочки, т.е. никакой интеграции производить не надо.

                        Вы про: :!command?
                        • 0
                          Команды <> горячие клавиши.


                          Почему же?

                          Потому что команды можно выстривать в различные комбинации и сочетания и их удобнее вводить.

                          Вы про: :!command?

                          Да, как вариант. Но я обычно использую screen.
                          • 0
                            Потому что команды можно выстривать в различные комбинации и сочетания и их удобнее вводить

                            Не совсем вас понимаю, ну да ладно.
                            Да, как вариант. Но я обычно использую screen.

                            Мне не очень удобно ими пользоваться. Но каждому свое, как известно.
  • 0
    Vim хорош прежде всего идеологией своих клавиатурных комбинаций. Какие бы там проблемы с высокоуровневыми средствами в нём ни были, переход на vim keybindings в любом редакторе/IDE — это огромный прирост скорости. У меня у самого основное средство — это emacs со включенным режимом эмуляции vim («Evil mode»).
    • 0
      Я emacs'ом не пользовался, но само наличие «Evil mode» мне всегда казалось странным. Зачем нужно эмулировать Vim?
      • 0
        Чтобы оставаться на своей среде разработки со всеми её фичами и при этом редактировать чистый текст со скоростью Vim.
        • 0
          Т.е. emacs не слишком удобен при наборе текста?
          • 0
            У emacs набор текста аналогичен современным текстовым редакторам (сочетания основанные на Ctrl+ и Alt+)
            • 0
              Это многое объясняет. Я лично Vim пользуюсь на постоянной основе.
  • +4
    Я долгое время брезговал IDE, а какое-то время мне хватало gedit и far'а в windows. Собственно gedit'а хватало бы и дальше если бы однажды не встала задача отредактировать текстовый документ весом 10 мегабайт. Для решения задачи я нашел себе SublimeText. Потом долгое время использовал SublimeText (обожаю его множественные курсоры).

    Потом я перешел на Мак и первым делом решил отказаться от проприетарного SublimeText'а, тогда я считал, что не по христиански это платить $60 за текстовый редактор. И встал вопрос что использовать: на мак есть разные редакторы, но все они не могли дать привычную функциональность, которая была в gedit. Я даже пытался gedit поставить на мак, но это не элегантное решение. Потом решил, что мне нужен редактор, который будет на любой системе и который даст мне необходимую функциональность.

    Выбор тут был не очень богатый: Vim OR Emacs. Я их и до этого смотрел, но они всегда казались какими-то неповоротливыми и уж слишком сложными для текстовых редакторов. Тут решил, что буду воевать до последнего пока не овладею по нормальному. Начал с Emacs, настраивал и изучал его пару дней и уже под конец решил сделать любимую функцию множественных курсоров (как в SublimeText) и прочитал, что архитектурно это сделать в Emacs нельзя, потому что он не поддерживает множество курсоров, а вот на Vim всё это делается.

    Перешел на Vim и 2 года пользовался исключительно им. Он шустрый, расширяемый, открывает большие файлы. Но! Командный интерфейс Vim это 30-летний выкидыш пользовательских интерфейсов. Это кошмарный пережиток прошлого. И когда приходится писать текст на русском, Vim, в этом случае, постоянно заставляет переключать раскладку, что в итоге я опять вернулся на SublimeText. Ну и за это время я конечно осознал, что для крупных проектов нужно использовать среды разработки и, на мой взгляд, это среды от JetBrains.
    • 0
      И когда приходится писать текст на русском, Vim, в этом случае, постоянно заставляет переключать раскладку

      Таки вроде переключение раскладки придумано для переключения раскладки?
      • 0
        Неудобно переключать раскладку для ввода команд Vim'а. Ну и режимы ввода Vim'а тоже бесят — ещё один пережиток прошлого.
        • 0
          В Vim есть встроенный механизм (lmap), позволяющий автоматически переходить на нужную раскладку при переключении режимов (почитать о нем можно тут habrahabr.ru/post/98393). Удобная штука. Я от нее отказался, так как не смог настроить переключение раскладки на CapsLock (видите ли сигнал этой клавиши не обрабатывается Vim'ом).
          Ну и режимы ввода Vim'а тоже бесят — ещё один пережиток прошлого

          А вы точно пользовались Vim?
          • 0
            Я настраивал lmap в Vim'e (настраивал 3 года назад, а не использую его уже год, поэтому сейчас не вспомню; а конфигов под рукой нет). И там были какие-то свои проблемы, но я уже не помню, к сожалению.

            Ну это был MacVim.
            • 0
              И там были какие-то свои проблемы, но я уже не помню, к сожалению

              Я его настроил себе и проблем не было (кроме описаных выше). Вполне удобный инструмент.
              Ну это был MacVim

              Странно что вы считаете режимы ввода Vim'а пережитком прошлого )
    • 0
      В emacs есть плагин для поддержки нескольких курсоров, так и называется — multiple-cursors.

      Его ещё демонстрировали в Emacs Rocks: http://emacsrocks.com/e13.html.

      Но он, к сожалению, не без глюков, сам щупал, в том же sublime text эта фича значительно более стабильна.
      • 0
        В Scintilla тоже наконец-то добавили множественные курсоры, работающие подобно таковым в Sublime Text, т.е. теперь их можно перемещать стрелками: sourceforge.net/p/scintilla/feature-requests/1085

        Это очень здорово. Скоро во многих редакторах… :)
  • 0
    Почитав все это решил еще раз попробовать подружиться с vim. Прикольно, конечно, но все же моей любимой командой в нем остается :q!
    • +1
      Почитав все это решил еще раз попробовать подружиться с vim

      А зачем? Если вам нравится используемый вами редактор/IDE, пользуйтесь им и не обращайте внимание на других.
      • +2
        А зачем? Если вам нравится используемый вами редактор/IDE, пользуйтесь им и не обращайте внимания на других.
        Не соглашусь с этим утверждением. Всему нужно дать шанс. Может понравиться, а может и нет. Я бы основывался именно на этом.
        • +1
          Давать шанс нужно тогда, когда используемое средство начинает чем то не устраивать.
          • 0
            Ну, моя точка зрения связана с любопытством («А вдруг не зря говорят что это лучшее, что есть?»).
            • 0
              К сожалению и к счастью программисты очень ленивый народ. Эта лень как двигает прогресс, так и тормозит его.
              • 0
                Как всегда, дело в правильном балансе.
  • 0
    Я админствовал 10+ лет. vi/vim знаю/умею.
    Но когда потребовалось стать разрабом и писать сразу на: Perl, JavaScript, SQL, HTML, CSS = Sublime rocks!
    unix way = нужно выбирать правильный инструмент под задачу
    • 0
      Я админствовал 10+ лет. vi/vim знаю/умею

      А как это связано?
      • 0
        В vi/vim'e удобно править конфиги. Я примерно так же сделал, но у меня было vim -> TextMate (быстро наскучил) -> MacVim -> RubyMine -> vim сейчас на NeoVim перехожу.
      • 0
        У vim есть преимущество, попадая на любой новый сервер ты знаешь, что там есть vim и он будет работать так же как и везде. Причём у тебя есть ограничения: ssh + консоль.
        Для разработки ПО — это преимущество не актуально, т.к. разработка ведётся обычно на 1-2 ПК где ты можешь настроить себе окружение. В vim для нормальной разработки требуется намного больше телодвижений, чем в заточеном для разработку редакторе/IDE.
        Не нужно гвозди забивать микроскопом.
        • 0
          Ясно, спасибо.
        • 0
          Проверил, на наших серверах нет vim. Так что "почти на всех".
          • 0
            Учитывайте еще то, что на всех серверах версия этого самого Vim'а может отличаться, а на некоторых так вообще стоит какая нить другая реализация vi, так что аргумент типа — в любом месте, в любое время — не очень уместем (еще один аргумент в вашу копилку «Против Vim») ;)
            • 0
              Вим не настолько менялся, чтобы было невозможно пользоваться даже старыми версиями :) Посмотрел свой конфиг — даже для версий ниже 7 «отвалятся» только табы из удобных фич, остальное будет работать.

              Могут отвалиться разлапистые плагины, требующие поддержки перла или питона, но их не так много, да и не всегда они нужны.
              • 0
                Частенько чту исходники различных популярных плагинов, и у всех имеются жесткие ограничения на версию Vim и его расширения. Так что не скажите )
                Могут отвалиться разлапистые плагины, требующие поддержки перла или питона, но их не так много, да и не всегда они нужны.

                Плагины не нужны? Без плагинов я прекрасно отредачу и с помощью какого нить ed.
                • 0
                  Покажите где я написал что плагины не нужны? :)
                  • 0
                    Вим не настолько менялся, чтобы было невозможно пользоваться даже старыми версиями :)

                    Как же пользоваться старыми версиями без плагинов?
  • +1
    Все-таки попробуйте вместо ack использовать ag, он же silver searcher, а вместо них обоих ctags — благо интеграция с vim у него была еще в те времена когда компании Jetbrains еще не было.
    • 0
      Кстати, если используется плагин ack.vim, то для его использования с ag можно просто добавить настройку:

      let g:ackprg = 'ag --nogroup --nocolor --column'
  • 0
    Иронично использую vim в cygwin. Рейт ми.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.