Comments 72
Vim должен быть против Emacs, вот это была бы топ-статья.
Топовая, но бессмысленная :-)
Т.е. у вас есть ответ на вопрос что же лучше - Вим или Емакс? Тогда поделитесь! А то я например и тот и другой использую, и всё не могу определиться. Ощущаю прям раздвоение личности.
что же лучше - Вим или Емакс?
Да.
А после того, как я узнал, что у Столлмана давний RSI, который плохо совместим с подобными тяжёлыми комбинациями и длинными последовательностями… уже не знаю, что и думать. Я, скорее всего, RSI не подвержен, но со стороны всё это попахивает странным мазохизмом…
То есть ни у кого не будет объективного ответа, потому что у них очень разные культуры использования.
Соответственно, такая статья может привести только к холивару.
Следовательно, она будет топовой из-за срача, но малополезной.
В IDE, благодаря умному анализу кода, ничего особенного не предпринимая, мы сразу увидим какие переменные не используются, какие циклы окажутся вечными, какие условия никогда не изменятся, а значит мы увидим большинство проблемных мест, просто открыв файл. Vim же предлагает нам внимательно вникать в каждую строчку и и выискивать все самостоятельно, проявляя весь свой талант разработчика.
Сам пользуюсь вскодом, вим использую только как простой консольный редактор, но то что вы пишете неверно от слова совсем. Монолитная модель закончилась, мы потихоньку переходим на language server которые работают независимо от редактора: https://microsoft.github.io/language-server-protocol/
Вот так это работает в виме: https://youtu.be/h4RkCyJyXmM?t=3362
Сомневаюсь, что вы работаете со скоростью парня из видео.
Следующим шагом логично посмотреть в дебагере как ведет себя приложение
Вы ошибочно полагаете, что разработка через отладку — самый эффективный способ разработки.
А что если мы разрабатываем интерфейс API и нам нужно покидать на него запросы и посмотреть какие приходят ответы?
Пользуюсь Stoplight Studio. https://stoplight.io/studio/
Вы ошибочно полагаете, что разработка через отладку — самый эффективный способ разработки.
Расскажите поподробнее, пожалуйста, про то, что в данном контексте значит "способ разработки". Вы говорите о, например, TDD vs. debugging или о чем-то другом? Мне было бы интересно узнать ваше мнение об эффективных способах разработки.
Сомневаюсь, что вы работаете со скоростью парня из видео.
Плюс/минус так же.
В общем и целом со статьей согласен, но вот тут хочу добавить комментарий к следующему утверждению:
>>Просто вместо вменяемого Text User Interface в vim применяется шаманская клавиатурная магия, возникшая стихийно на заре программирования, когда самого понятия «User Interface» еще существовало."
Шаманство вима имеет вполне определенную логику, оно возникло не стихийно. После vi был vim, а теперь эстафету подхватил neovim, и все эти редакторы исповедуют один и тот же подход. Если бы это было "шаманством", то было бы сомнительно почему эти более современные версии vi имеют такую же логику. А логика простая - сократить кол-во интерактивных прорисовок UI и нажатий на клавиши при работе с текстом на удаленном сетевом терминале, в условиях сетевых тормозов, слабого канала связи. Например, курсор находится на позиции X:
Xsome.property.value="abc 123"
Юзеру нужно заменить abc 123 на другое значение. Работая скажем в нано, придется сначала переводить курсор к началу слова abc, затем стирать abc 123, каждое действие требует отправки команд на удаленный сервер, перерисовки курсора и текста, что занимает сетевой трафик и время. Шаманство вима в данном случае позволяет обойтись всего 3 нажатиями:
Перемещаем курсор в начало значения проперти нажатием f" (мнемонически команда запоминается как "find символ")
Одной командой удаляем внутреннее содержимое нажатием ci" (мнемонически это запоминается как change inside парный_символ_кавычка)
Как видно, действий на порядок меньше (буквально 2 действия против десятка в нано или прочем "обычном" редакторе), потребленного сетевого трафика на порядки меньше, отсюда скорость работы с текстом - на порядки быстрее. И это удобно при точечном редактировании каких-то настроечных файлов на удаленном сервере. А в IDE наверное да, не очень удобно, вим все же не для этого придумывали.
А шаманством команды вима кажутся только пока не увидишь, что многие из них имеют вполне конкретные мнемоники, типа f - это find, с - это change, и т.д.
Хоть я и нежно люблю vim, у меня от него глубокая детская травма и стокгольмский синдром, но в «обычном редакторе» вы выполняете простые механические действия, участвует почти исключительно мышечная память, в то время как в vim надо постонно думать — «так, мы находимся в каком режиме? Редактирование, надо перейти в командный, так, где именно у нас курсор? ага, в этой синтаксическо-семантической позиции у нас работае механика №15, вызываемая волшебным сочетанием C+A+D, ой, лишний символ стёрся, ничего, сейчас поправим, всего-то десяток легко запоминаемых клавиш, и мы вызвали историю последних правок и теперь совершенно элементарно находим в ней...».
Ни разу не приходилось держать в голове "в каком я режиме". Режим по умолчанию один - командный, остальные включаются по мере необходимости и выключаются сразу после этого.
Думать надо только тому, кто ещё не умеет пользоваться vim.
Показывается внизу: пишет "-- INSERT --"
(Может, это не по умолчанию. У меня конфиг vim начинается с:
set nocompatible
set ruler
set showcmd
set showmode
syntax on
Но я не представляю, кому нужно без такого работать.)
> надо перейти в командный, так, где именно у нас курсор?
А зачем для перехода в командный режим — курсор?
Вообще же в любом визуальном редакторе надо видеть курсор, чтобы что-то делать. Не вижу тут отличий.
> ага, в этой синтаксическо-семантической позиции у нас работае механика №15, вызываемая волшебным сочетанием C+A+D
эээ… чего?
Вроде у него нет такого…
При этом, повторюсь, я нежно люблю vim, мне не комфортно в однорежимных редакторах. И игра на пианино в vim действительно завораживает, как и игра на обычном пианино, но если просто нужно послушать музыку, проще её включить.
А логика простая - сократить кол-во интерактивных прорисовок UI и нажатий на клавиши при работе с текстом на удаленном сетевом терминале, в условиях сетевых тормозов, слабого канала связи.
А, то есть vi-vim-neovim решают проблему, которой в общем-то почти не бывает у разработчиков.
Да, поэтому штатного редактора JetBrains разработчику средней руки должно хватить за глаза.
Ну вот, я сижу на бесплатных продуктах JetBrains уже лет 12-13, и считаю, что ничего лучше просто нет.
Да, продукты JetBrains изначально были очень хороши, но на мой взгляд последние годы стали деградировать в плане юзабилити, стабильности и keyboard-centric подхода. Я сам работаю на них давно, но сейчас постепенно перехожу на другие решения. Например, докерами и их логами управляться мне проще через tmux, less и bash, которые можно юзать даже на винде через обычную сборку msys2 которая используется для создания дистрибутива гита, и командную строку, потому что в Идее это вроде реализовано, но работает нестабильно, тормознуто и неудобно. Есть желание вообще отказаться от Идеи, lsp в этом плане мне кажется многообещающей идеей.
Кроме того, можно создать несколько конфигураций разные задачи, и в тоже время иметь под рукой легковесный редактор для правки всякой мелочевки.
А вот потом уже можно сравнить фичи, скорость, потребление памяти, и обнаружить, что уже не все так однозначно.
Для каждой задачи должен быть свой инструмент, а не один универсальный. Можно и вилкай в зубах ковырять, но для этих целей существуют зубочистки. А у вилки другие задачи.
Отличная логика. Для редактирования кода - редактор кода, для гита - git, для дебага - дебаггер, для задач - Jira... IDE тут не вилка, а швейцарский нож, и им ковырять в зубах не лучше
Раз уж Вы заговорили про швейцарский нож, то, как любитель ножей, похвастаюсь своим Victorinox в котором есть зубочистка =)
Нож
В инструмент входит и окружение
Это и работа с гитом\свн, с базой, встроенный дебагер гораздо удобнее внешнего, не говоря уже о удаленном.
Тут скорее что для плюсов, один инструмент, для пхп другой
>что файловый менеджер - он и в Африке файловый менеджер, однако в PhpStorm он уже есть, а для vim снова нужен плагин.
:Sex
:help netrw
В дальнейшем мы будем вынуждены закрывать рабочее окружение каждый раз, когда нам потребуется какой-то плагин, а требоваться они будут неприлично часто.
а для vim снова нужен плагин. И вновь мы тратим драгоценные минуты на установку необходимого функционала.
Такие вещи настраиваются один раз.
Без проблем - в IDE есть встроенный HTTP-клиент и мы можем баловаться с запросами так, как захотим, а что предлагает нам vim-комьюнити? Использовать штатный консольный клиент операционной системы? Но для этого мы вновь вынуждены покинуть рабочее окружение. И пока ведется разработка, мы так и будем скакать из одного окружения в другое.
Не вынуждены мы ничего покидать. Или вы переход в другое окно называете покиданием рабочего окружения? Лично я несколько окошек (vim, repl питона, bash) воспринимаю как целое рабочее окружение.
Если хотите, можете даже vim-плагин поставить в IDE и радоваться. Для чего нужно отказываться от остальных возможностей IDE, мне не понятно.
Я честно пытался использовать vim-плагин в vscode, но он, во-первых, тормозил, а во-вторых поддерживал не всё, что есть в vim-е. Что именно не поддерживал, уже не помню, но я постоянно "спотыкался".
Для этих же целей служат файлы .idea
Не всегда. Мне по кайфу, что при ssh-подключении к сервакам у меня vim выглядит и работает точно так же, как локальная версия.
Просто вместо вменяемого Text User Interface в vim применяется шаманская клавиатурная магия, возникшая стихийно на заре программирования, когда самого понятия «User Interface» еще существовало.
Эта самая шаманская магия vim - не динозавр, но акула.
Я честно пытался использовать vim-плагин в vscode, но он, во-первых, тормозил, а во-вторых поддерживал не всё, что есть в vim-е. Что именно не поддерживал, уже не помню, но я постоянно "спотыкался".
В JetBrains аналогично, лаги при вводе и почти неработающий undo. Если бы не это, с радостью пользовался бы их продуктами, а так приходится довольствоваться вимом.
Благо, coc даёт и удобную навигацию, и предупреждения на код высвечивает.
Эта самая шаманская магия vim - не динозавр, но акула.
Vim в целом не очень-то дружелюбен к пользователю - новичку. Ведь не зря столько мемасиков про то что из него можно выйти только с помощью reset-а )))
Ну то есть на vimtutor вас не хватило - жаль.
Когда я первый раз столкнулся с vim - никто мне про vimtutor не говорил. Чтобы его пройти - надо знать про его существование.
Да, есть какие-то общие правила типа «раз Windows, то Alt+F4», но они не абсолютны.
Tutor тут как отдельная сущность просто не нужен.
Кстати, vim при старте по умолчанию говорит про ":help".
Так что тут исключительно ваша провина.
Кстати, vim при старте по умолчанию говорит про ":help".
Это если просто запустить vim, без аргументов. Есть люди, которые попадают в vim совершенно не имея таких намерений. Например, ЕМНИП git по умолчанию именно vim открывает для всего, что требует редактирования текста. И тогда вместо дружелюбной стартовой страницы сразу открывается файл, дифф, сообщение коммита или что-то такое. Так что если пользователь не указал системную переменную EDITOR=nano или не настроил сам git использовать иной редактор, то только vim только хардкор.
Наверняка немало найдётся людей, которые именно так впервые сталкиваются с vim'ом :)
По-моему, таки редактор по умолчанию? Который в большинстве дистрибутивов — ужасный nano. Вот если ничего не выставлено — да, vim (или вообще vi).
Ну тут я согласен, что в Unix можно в vi и случайно попасть.
Если автор статьи столкнулся с такой ситуацией… да, соболезную. У меня было в первый раз так же — попал случайно и вышел только закрыв окно telnet :) но потом пошёл искать доку. Но я от этого не говорю, что редактор безусловно плохой — проблема в окружении.
Я когда-то тоже угодил в такую же ловушку :) То есть был в каком-то дистрибутиве, где дефолтным был vi/vim. Не знаю, где какой дефолт сейчас.
Помню, что какая-то утилита однажды дала мне сообщение в духе "У вас не установлено значение переменной EDITOR, мы обнаружили следующий список установленных редакторов: %список%. Выберите, какой из них вы хотите использовать сейчас". Но вообще не помню, что это было такое.
У vim два режима: Бибикать и всё портить. ;)
Не вынуждены мы ничего покидать. Или вы переход в другое окно называете покиданием рабочего окружения? Лично я несколько окошек (vim, repl питона, bash) воспринимаю как целое рабочее окружение.
Несколько окон и и единое пространство в IDE - разные вещи. До банального - как раскидать разные инструменты в vim по 2 или 3 мониторам?
А почему вы сравниваете решение для разработки на PHP, собранное на основе JetBrains IDEA (хоть и поставляемая готовым пакетом) с голым vim?
Вы уж или тоже берите готовую сборку вима, которых достаточное количество, или берите голую IDEA
Вы про IntelliJ-IDEA? Это другая IDE, если не ошибаюсь, для Java. Делать из нее средство разработки на PHP - глупое занятие. Так же как и пичкать vim всеми плагинами, для всех языков.
Так же как и пичкать vim всеми плагинами, для всех языков.
В этом и есть ваша проблема в понимании идеологии vim'a: без плагинов, это просто мощный редактор, причем по умолчанию, многие возможности ни на какие хоткеи не повешены. А вот последующая конфигурация и плагины уже позволяют навертеть все что угодно.
Причем совершенно необязательно делать универсальный комбайн в рамках одной конфигурации: можно создавать «рабочие места» под любые задачи. Например, отдельно для C/C++, отдельно для Python, отдельно для PHP/JS/HTML, а по умолчанию иметь простой и удобный редактор с табами.
Искать смысл в использовании vim vs ide это то же что и спорить какой цвет лучше - красный или зелёный. Потому что зелёный лучше, это всем известно.
Если мне не изменяет память, есть Idea. Всё остальное это набор плагинов поверх. Да, они очень глубоко интегрированы и написаны теми же разработчиками, что не отменяет факта.
И это хорошо, это модульность. Модульность == расширяемость.
Вы про IntelliJ-IDEA? Это другая IDE, если не ошибаюсь, для Java.
Вы ошибаетесь, это та же самая IDE. Различие - в наборе предустановленных плагинов и дефолтных настройках. IntelliJ IDEA Ultimate отлично работает Goland'ом, WebStorm'ом и Android Studio'ей одновременно, "просто включи плагин"
Думаю IdeaVim на Intellij Idea лучше, чем использовать их отдельно.
Автор же данной статьи, похоже, не в курсе, что современный редактор типа vim это тоже комбайн с тысячами вариантов расширенных возможностей через плагины — он воспринимает текстовый редактор как что-то в духе notepad (а в случае vim ещё и постоянно проезжается по непривычному интерфейсу). Выглядит как просто невежество и нежелание хоть как-то изучить предмет критики перед публикацией. Хотелось бы надеяться, что ошибаюсь, но пока причин к такому смягчению не вижу.
Рабочие инструменты берем в состоянии "из коробки"
Изначально не правильный подход) Все равно что сравнивать macOs и винду предполагая что вы покупаете для мака собственно мак, а для винды набор комплектующих и диск.
Вим для тех, кому настроек пхпшторма мало. Собственно я так за пару лет полюбить шторм и не смог. Он крайне приятен, у него целая куча всего очень нужного и полезного, и местами сильно удобней чем везде, но увы расширять его крайне сложно. Например хотите вы быстро фильтровать таблицы в базе, а не просто искать их. Или хотите нормальный vim мод, а то ideaVim применим разве что для печати.
Поэтому позвольте чуть-чуть пояснить кто все же выбирает вим. Вим выбирает человек заранее желающий не только настраивать плагины, но и писать их. Просто потому что. Он готов написать свой плагин для создания локальных копий, скачивания базы, или даже добавления удаления пользователей из редактора. У него уже есть куча bash скриптов, и странных привычек в оформлении кода. Т.е. у него уже есть настроенный под него годами вим. Что кстати решает часть проблем. Например как-то на старой работе появилось требование "перед любым ветвлением или циклом должен стоять комментарий", и в шторме никак нельзя без плагина добавить такой тип ошибок. Т.е. есть регулярка, но если не хочется взять джаву и дописать такой плагин, то проверяй руками. Эту регулярку проще встроить в хуки гита, чем в шторм. В общем с любым не стандартным требование шторм не справится.
Я ни в коем случае не ругаю шторм. В нем отличный поиск двойным шифтом, удобно что можно смотреть базу в нем (хоть и посредственно), можно там же работать с запросами (хоть и плохо), и достаточно приятный рефакторинг, но главное в нем есть Goto definition, который даже с intelphence работает так себе.
Из минусов шторма можно отметить то, что он приучает к работе через классы и многословно. Т.е. код получается с слишком большим уклоном в ооп ради ооп. И без шторма его читать становится проблематично.
Вим выбирает человек заранее желающий не только настраивать плагины, но и писать их. Просто потому что. Он готов написать свой плагин для создания локальных копий, скачивания базы, или даже добавления удаления пользователей из редактора.
Не согласен, я не пишу плагины и не планирую. Использую вим потому что ничего удобнее для редактирования кода не встречал, а для других задач меня полностью устраивает иметь отдельные программы: отдельное окно с редактором, отдельное с отладчиком, отдельное для запуска скриптов и работы с гитом.
У него уже есть куча bash скриптов
Вот это — да, у меня тоже есть.
и странных привычек в оформлении кода
Нестандартные правила оформления не люблю, ограничиваюсь стандартными для своего стека clang-format + clang-tidy.
Не согласен, я не пишу плагины и не планирую.
Очень многое теряете) Хотя можно называть плагинами кастомные сниппеты или настройки клавиатуры. Я например в саблайме настроил так, что выделив true/false и нажав "!" я получу false/true соответственно. Ну а плагин писал для создания системы файлов папок для компонентов. Ну и быстрой навигации по фреймворку.
Ну а плагин писал для создания системы файлов папок для компонентов.
Я обычно bash-скрипты для подобных целей пишу, и вызываю в отдельном окне терминала. Не очень понимаю, что мне даст возможность вызывать их по бинду из редактора.
Ну и быстрой навигации по фреймворку.
Вот это могу понять, но всерьёз изучать ради этого vimscript / Lua + Neovim API не готов.
Я обычно bash-скрипты для подобных целей пишу, и вызываю в отдельном окне терминала. Не очень понимаю, что мне даст возможность вызывать их по бинду из редактора.
В целом да, особо преобразовывать баш скрипты можно только если выделенный код уже содержит инфу полезную для создания файлов. В моем случае это названия папок.
Вот это могу понять, но всерьёз изучать ради этого vimscript / Lua + Neovim API не готов.
Тоже верно, но lua это почти js, и я его заодно знаю из плагинов к wow. Плагин я опять таки писал к саблайму, для чего узнал заодно пайтон, и честно говоря апи нужно внимательно изучать, только для каких-то оптимизаций. В противном случае можно просто знать положение курсора, а дальше обойтись уже внешними средствами. А для быстрой навигации вообще fzf подойдет)
… плевал в него, недовольно бормоча про то, что...Когда человек плюется и кидает банновые шкурки в молчащего меня, заявляя, что это я плююсь и кидаю банановые шкурки в него — это вызывает недоумение на грани негодования.
Когда человек самостоятельно придумывает мифы, а потом доблестно, успешно, безжалостно и сокрушительно разносит их в клочья — это вызывает усмешку и заставляет вспомнить слово «демагогия».
По поводу заголовка статьи и несуществующего в моей реальности противопоставления я уже писал тут, кому лениво идти по ссылке, можно глянуть под
— тексты с не-WYSIWYG разметкой: LaTeX, markdown и подобное. Особенно если это надо лишь время от времени, а не 40 часов в неделю
— старые языки, например asm PDP-11. Представьте себе, он еще не помер, и процессор серийно выпускается.
— новые языки, например, ассемблер NM6403-6407.
— Чужие языки, например, надо чей-то код внезапно однажды на питоне посмотреть и поправить, хотя по работе питон не нужен от слова абсолютно.
— огромные по размеру таблицы данных в виде plain text, которые завесят наглухо практически любой другой редактор. Причем, с прекрасной возможностью поиска по этим данным путем регулярок, а также выборки нужной пачки этих данных.
— сложные и регулярные манипуляции с текстом, например, периодически необходимое преобразование опять же данных, полученных в текстовом виде (результаты записи контрольных приборов, полученных от сторонней организации, повлиять на формат записи нельзя), с выборкой и заменой части этих данных по какому-то (не буду слишком подробно) правилу, тут скрипты vim влегкую уделывают любые макросы. Причем, макросы там тоже есть.
— необходимость работать с зоопарком кодировок с перебросом текста на кириллице из одних кодировок в другую — vim удивительно всеяден и позволяет делать это настолько легко, что не надо совсем задумываться над процессом и последовательностью операций.
Некоторые из этих вопросов решаются настройкой любимой IDE под использование постороннего компилятора, но это потратить изрядно времени на такую настройку, потом, однозначного соответствия, скажем, сишным операциям в питоне или асме не будет, все равно боль, а в vim привычно, быстро и легко.
Некоторые вопросы решаются другими средствами. Но зачем? Если есть инструмент, который перекрывает этот спектр с запасом (я еще не все вспомнил, за что люблю vim).
Это кое-что из того, что в моей повседневной работе встречается более-менее регулярно. И VIM здесь великолепен портясающей настраиваемостью, подсветкой синтаксиса под все, что надо (и очень легко добавить еще), скриптуемостью, всеядностью по кодировкам, форматам конца строки и размерам, кучей возможностей редактирования, поиска и замены из коробки, переносимостью между кучей ОС (забрал свой vimrc — и на чужой машине ты как дома), встраиваемостью сторонних утилит в процесс редактирования и поиска (типа ctags из простого), и, черт побери, ругаемой всеми модальностью, которая поначалу кажется чем-то диким, а потом не понимаешь, как без нее другие обходятся. Многое из этого (и еще много чего не перечисленного) есть и в других редакторах, но все это есть в одном месте. Наверное, emaсs не хуже. Говорят, в принципе, такой же, я не пробовал. Но nano, mcedit и тому подобное… Конфиги править — может быть.
Да, для шарпа я буду пользоваться студией, для явы — идеей, благо теперь есть и бесплатные версии, возможностей которых для меня хватает. Но IDE для LaTeX? Для PDP-11? Или вспоминать, как работает iconv (передаваемы параметры и все такое), и где-то добывать ее под винду, когда интернета на рабочей машине нет, и вообще он далеко?
Я не знаю, кто хуже — веган, который всех остальных при каждом удобном случае брезгливо честит трупоедами, или любитель шашлыка, пытающийся перепрошить вегана. Не надо так.
Притчу ответную тоже написал, иллюстрирующую обратную точку зрения (это не мешки ворочать), но очень уж длинно получилось, так что стер.
P.S. Для песочницы выбирать настолько холиварную тему — это, как сейчас принято говорить, такое себе… Чес-слово, светодиодик на ардуинке смотрелся бы лучше.
P.S. Для песочницы выбирать настолько холиварную тему — это, как сейчас принято говорить, такое себе… Чес-слово, светодиодик на ардуинке смотрелся бы лучше.
Ну если и открывать какие-то двери, то с ноги =) Я много лет просто читал хабр, и побаивался что-то писать. Думал что мое мнение никому не интересно, что на хабре пишут только настоящие крутые дядьки, которые уж точно гораздо компетентнее меня, но тема зацепила и появилась мысль о том что в целом-то я ничего не теряю. Ну заминусят - так просто останусь вечным читателем. А если будет хотя бы небольшой положительный отклик - можно будет подумать о том, чтобы написать что-то еще.
А со светодиодиками на ардуинке я не умею, хотя все время вспоминаю о том, что стоило бы выделить на это время.
Вот тут кстати да. Не отнять. Открыть на винде гигабайтный лог и ещё и работать в нём — никаких проблем, волшебное совершенно чувство.
Закинул два файла .tmux и .vimrc и я уже там как дома. Правда плагины vim'овские пришлось снести так как какой-то из них тормозил.
То есть я мог комфортно изменять файлы и даже компилировать в привычной среде.
Vim хорош, когда нужно открывать проект на нескольких языках программирования и сверх больших. Из 20+ библиотек раскиданных по разным местам на диске. Через ctags сделать общую навигацию до желаемого уровня, вплоть до сишных функций компилятора. Везде будет подсветка синтаксиса и привычные тебе настройки.
Есть отдельная боль как портирование библиотек. Иногда это занимает недели. Там не нужно писать, а нужна быстрая навигация, чтение и точечное исправление.
Vim хорош когда требуется удаленная работа, работа на системном уровне, чтение конфигов и прочего.
Морально-психологическая радость в том что vim принадлежит тебе и ты управляешь изменениями, когда IDE может радикально измениться по воле одной из корпораций. Нет выученной беспомощности.
Для тех кто использует один язык программирования и узкую сферу деятельности, преимуществ никаких с VIMом не будет.
О полноценной разработке, мой случай.
Работал в vim (потом neovim) с Clojure.
Доп плагинов всего два:
LSP (+ clojure_lsp сервер) - линтер, статанализ, дополнение. Строго говоря, в nvim это уже не плагин, но упоминаю так как в одной строчке конфигурации и доустановке сервера нуждается.
fireplace - интеграция с REPL, контекстный хелп, eval, display source, stacktrace.
Решил перейти на IntelliJ Idea, так как не хватало полноценного go-to-definition. То есть gd в пределах файта работает и в голом виме, и [d из fireplace хорошо находит и показывает реализацию, gf открывает файл по ns, но хотелось чтоб открыть файл с реализацией и прыгнуть на нее ([d показывает ее просто внизу, файл не открывает). Да и просто если честно все вокруг в идее, хотелось глянуть что такое полноценное IDE.
В идее скачал Clojure плагин который в поиске топ-1 с большим отрывом. Он платный, но я рассудил что наверное самый продвинутый. Подключился замечательно к обоим своим REPL.
На этом проекте есть особенность - REPL у меня как правило открыто два:
один локальный, в тестовом env. Здесь можно запускать тесты, но нет реальных данных.
второй запущен на сервере и проброшен через ssh. Здесь реальные данные, но нельзя запускать тесты.
Получается такой воркфлоу: работаю с реальными данными, сохраняя файл удаленно и синкая с удаленным реплом, а когда нужно запустить тест - сохраняю и синкаю соответственно с локальным. В виме это реализовано двумя макросами, каждый 2 нажатия:
autocmd BufNewFile,BufRead *.clj,*.edn :let @r = ":w\n:Connect 55555 .\ncpr"
autocmd BufNewFile,BufRead *.clj,*.edn :let @s = ":w\n:silent !scp % research:/home/me/repos/%\n:redraw!\n:Connect 44444 .\ncpr"
Где 55555 и 44444 - порты соотв. локального и удаленного реплов, cpr - REPL reload. То есть нажимая две кнопки, я сохраняю куда нужно и синхронизирую. @ и r - все это локально, @ и s - удаленно. Или дабл @ для повтора последнего варианта.
Где осталась последняя версия файла - легко увидеть гитом, ну и @s @r сделать перед закрытием не сложно, чтоб сбросить туда и туда. Секундной задержки и вывода scp в строке статуса при @s достаточно, чтобы не перепутать.
Понятно что это все как правило не для одного и не для двух файлов, буферов открыто много, благо в неовиме навигация по ним уже наглядная с дополнением списками.
Вот эту фичу я не смог реализовать в идее. То есть можно открыть проект по scp, или примонтировать локально (уже не айс), но это будет отдельный проект. Я не смогу, работая над одним файлом, запускать его то тут то там, не персохраняя его явно с кучей кликов мышей.
По поводу остальных преимуществ: go-to-definition в проекте в идее так и не получил, только локальный. Может быть плохо искал.
Анализатор в идее откровенно тупее чем clojure_lsp (не недостаток т к наверное это того плагина анализатор и можно было подключиться к тому же LSP что и вим).
Дебагер кложе не нужен) Все остальное есть в виме в той конфигурации что я описал.
Вернулся в вим.
IDE против Vim для разработки