Плюсую. Если надо поковырять сложный скрипт или конфиг на удаленном сервере, где из дружественного интерфейса только терминал, знание vi очень спасает. К тому же никто не заставляет в vi серьезно кодить (а если кто заставляет, это, простите, проблема заставляющих, а не vi).
Пример №1: что делать, если ваш редактор не умеет сгенерировать объявление и тело метода одной атомарной командой.
Пример №2: что делать, если ваш редактор не имеет рефакторинга «выделить локальную переменную», который вызывается одной горячей клавишей.
Пример №3: что делать, если в вашем редакторе нет семантического выделения блоков CST-дерева.
Ну серьёзно. Я понимаю, что изучить vi может быть полезно, мало ли где окажешься. Я понимаю, что некоторые просто фанатеют от vi. Но заявлять «Или продолжайте использовать никудышный редактор кода своей IDE» просто глупо. В нормальных IDE (IDEA, Eclipse) всё из этой статьи можно сделать быстрее, удобнее и надёжнее.
Собственно, с использованием клавиатурных модификаторов в большинстве нормальных текстовых редакторов тоже можно быстро перемещаться по тексту при помощи «стрелок» — Ctrl+вправо/влево — «прыгаем» по словам, CTRL+вверх/вниз — «прыгаем» между абзацами, ctrl+PgUp/PgDwn — «бегаем» по страницам. и т.д. Таки не обязательно пользовать мышку, а ситуацию когда набор текста/кода постоянно и непрерывно был совмещен с навигацией по нему, даже в кодинге, я не представляю. Обычно либо то либо то, и передвинуть правую руку на стрелки для быстрой навигации, сделать переход и продолжить набор текста не так уж сложно.
Другое дело, что для этого хорошо бы иметь нормальную полноразмерную клавиатуру с полноценным командным блоком, ибо современные «дизайнеры» любят то блок со стрелками сделать в микроформате, то экспериментируют с расположением и наличием Insert/Delete и прочих допклавиш, а то и вовсе выстраивая их столбиком. (Отчасти я понимаю такие извраты в ноутбучном формате, когда нужно «впихнуть невпихуемое», но не понимаю как перенос данной концепции в десктопные клавы, так и использования ноутбучной клавиатуры при постоянном и объемном наборе, вместо того, чтобы подключить полноценную USB-клавиатуру).
Вообще же стенания поклонников VI/VIM о том, что их и VI не понимают, мне напоминают возмущения веганов.
«Вы просто десятипальцевым методом не владеете, вот и беситесь».
Ну и дискуссию по поводу удобства использования VI/VIM в качестве IDE можно закончить сразу, вспомнив основной аргумент, что VI легко превращается в IDE. Нужно всего-то: почитать доку, привыкнуть к стилю командному (!) редактирования, поставить пару десятков плагинов и написать под себя конфиг. Лично меня такой gentoo-style не устраивает.
Если мне нужен текстовый редактор — мне нужен именно текстовый редактор, а не коммандный процессор с функциями редактирования текста. Если IDE — значит полноценна IDE. Со всеми плюшками, которая она дает.
Абсолютно согласен. У меня доведено до автоматизма и то и другое, и могу сказать что есть моменты где мышкой пользоваться удобнее, но фишка еще в том, что ваш мозг (неосознанно) переключается в оптимальный режим что способствует невероятной продуктивности.
тоже самое можно сказать и о адептах vi — как только вы научитесь переносить руки с клавиатуры на мышку — вам откроется разнообразие мира (редакторов) а доведя это до автоматизма вы узнаете что некоторые вещи можно делать быстрее с мышкой нежели с hjkl
1. Потому, что эта парадигма эффективнее. Вим — это интегрированный опыт поколений лучших программеров в различных окружениях и проектах.
2. Команды эффективны. Вам все это было не надо, т.к. вим для вас был вторичным инструментом, или по другим причинам. Я вам не смогу объяснить, почему для меня он лучше. Все, что я написал — мой субъективный опыт, у вас он другой.
3. Если используете firefox — поставьте vimium, поймете разницу между мышиным интерфейсом и командами, и увидите, что быстрее.
1. Ну если так, то можно вообще не выходить из режима редактирования, а по тексту перемещаться стрелками.
2. Все вим команды через 3 месяца выполняются спинным мозгом не отвлекая и не создавая проблем в этом и есть смысл вима и это именно так и должно работать и работает у тех, кто вим освоил. Остальные жалуются.
В том и проблема, что Vim не масштабируется. На малых файлах это прикольное и «эффективное» (а скорее, «эффектное») копошение уровня «смотрите, как я умею!», на чём-то более крупном и сложном уже борьба с инструментом. Фанатизм и привычка использовать один инструмент мешают более конкретно очерчивать круг применимости, и это вполне естественно для большинства, ибо лень переучиваться или просто пробовать что-то новое, где не хватает чего-то привычного (а любые плюсы уже не ощущаются после этого).
Попробовать и освоить Vim однозначно стоит, особенно, если вы используете Linux. Для удалённого редактирования или локального в tmux/screen/tty, например, ничего лучше не найти. Просто это не замена для IDE, а совершенно отдельный параллельный инструмент для других задач, слабо связанных с программированием.
а для чего-то типа Python/JS/HTML/CSS или конфигов, конечно, он подходит лучше.
Спорное утверждение. На мой взгляд, тут вопрос не в языке, а в масштабах проекта. Пока это пара файлов, может быть, вим удобен тем кто уже потратил время чтобы его изучить, но учить его ради 10 файлов — странно. Но если проект развесист и имеет много внутренних связей — нужна IDE.
В идеале, чтобы дискутировать в этой теме адекватно, надо иметь хорошее знание и опыт Вим и ИДЕ. И даже пару раз в подобных темах возникало желание вим-таки освоить. Но потом понимаешь что это все эмоции и тратить время просто чтобы попытаться кому-то что-то доказать уже по возрасту не подходит.
Это больше похоже на хвост, виляющий собакой. Может, логичнее в существующие мощные IDE, которые синтаксически и семантически «понимают», что в них пишут программный код, а не набор букв и слов, так вот, в эти IDE прикрутить Vim-like управление? Собственно, это уже сделано, о чём и сам автор статьи упоминает. Всё ж как ни обвешивай текстовый редактор плагинами, он от этого IDE не станет. Будет просто редактор с кучей костылей, потому что он работает не с языком, а с текстом, не с проектом, а с набором файлов.
К слову, буквально на днях обнаружил, что Eclipse CDT понимает даже перегруженные операторы, и по F3 позволяет перейти к их определению. Учитывая, что выбор правильной реализации оператора жёстко привязан к типам аргументов, я не представляю, как эту задачу можно выполнить в Vim. Ну вот есть конструкция вида cout << someObj << endl;. В эклипсе я встаю курсором на << и жму F3, попадаю на реализацию этого оператора, могу прочитать и понять, что там не так. Этот оператор может быть реализован в стандартной библиотеке (за пределами проекта вообще), в сторонней библиотеке, в моём коде; может быть внутри класса, может быть свободной функцией. Выглядит он везде одинаково, <<, как же найти искомый? QtCreator, например, не умеет (пока) находить такие определения. В результате, перегрузки для Qt'шных типов найти либо сложно, либо нереально. А ведь возможность быстрой навигации по коду — это именно то, к чему апеллирует автор. И для программиста Vim именно эту возможность не предоставляет. Он даёт лишь быструю навигацию по тексту, которая довольно бесполезна, ведь программа состоит из множества файлов, классов, функций и библиотек, которые Vim не понимает.
Я пишу все эти аргументы уже не первый раз, потому что в каждой статье от Vim-евангелистов пишется про рай для программистов, тогда как по факту это является неслабым таким преувеличением, мягко говоря. Стоило бы говорить о редактировании небольших текстов типа конфигов или ридмишек, тогда совершенно с этим соглашусь, ибо везде у меня Vim стоит редактором по умолчанию, и это первое, что я ставлю на минимальную систему. Пробовал и Emacs около года (даже как Jabber-клиент!), но в итоге надоело аккорды наигрывать. А фанатичность вообще до добра не доводит.
Для статически типизированных языков к Vim можно, к примеру, прикрутить внешние средства рефакторинга, хотя в случае, собственно, Java, где невозможно непредсказумое изменение синтаксиса и идеоматики языка, а IDE — тщательно «вылизаны» на предмет соответствия практике кодирования и рефакторинга, за ними уже не угнаться. В случае C/C++ — уже сомневаюсь.
Первый пример неубедительный. Например, чтобы в Eclipse CDT сгенерировать реализацию методов (в любом количестве) по заголовочному файлу, мне достаточно нажать Alt+Shift+S, Up (Implement Method...), Enter, Enter. При этом, в примере не раскрыта тема C++, где простого копирования мало, надо ещё дописать название класса.
Второй пример также проигрывает эклипсу, выделяем код, который хотим извлечь в переменную, нажимаем Alt+Shift+L, пишем название новой переменной. Тип выводится автоматически, название переменной подставляется в место извлечения. Аналогично можно вытащить фрагмент кода в функцию с автовыводом типов входных параметров и результата.
бывают такие моменты, когда после 30 секундного "взрывного" редактирования вы как-будто "просыпаетесь"
Со стороны это больше похоже на имитацию бурной деятельности, ничего не понятно, грохот клавиш, текст скачет туда-сюда, и вообще всё выглядит круто и по-хакерски. Может, в каких-то случаях именно такое и нужно. В своей практике не встречал.
Мне кажется, именно в примерах со статически типизированными языками Vim наиболее наглядно проигрывает хорошим IDE, а для чего-то типа Python/JS/HTML/CSS или конфигов, конечно, он подходит лучше. С развеиванием разоблачения №5 я лично не согласен: программирование происходит в голове, а написание кода — это лишь небольшая промежуточная стадия между придумыванием кода и запуском его. Улучшать стоит то, что занимает основную часть времени. Если удалось ускорить какую-то операцию в 10 раз, это здорово! Но если она выполняется, скажем, раз в час и занимала 100 мс, а теперь 10 мс, тогда как непосредственно алгоритм отрабатывает по полминуты… это больше похоже на преждевременную оптимизацию ради оптимизации. Вот к скорости набора кода у меня такое же отношение.
Мышь — это интуитивный инструмент, в этом его плюс. Но он не быстрый. В любом редакторе нормальные профи (не только в vi/vim) используют «горячие клавишы» и минимизируют использование мыши.
вы правы, тремя кнопками (с настройками по-умолчанию) не обойтись. Вот последовательность
:37 enter
v$hy
:12 enter
27lp
Если вы новичок в виме, то да, над каждой командой нужно думать, уйдет много времени. Если все в пальцах, то получается быстрее (тем более, если визуально 28 символ не сильно отделен). Опять же, я не призываю пользоваться вимом, пользуйтесь чем угодно. Но клавиатура в подобных задачах быстрее. Другой вопрос нужны ли эти выигрыши в скорости (вопрос почти как про преждевременную оптимизацию). За себя я могу сказать, что мне просто нравится работать таким образом.
Вот мне тоже хотелось бы линк на исследование. То, что кинул Evengard, извините не исследование, а такое же ИМХО автора, нет ни метода исследования, ни характеристики групп, не количества испытуемых, ничего (насколько я понял их контекста, они набирали рандомных людей, так я и так вам скажу, что по-началу мышка интуитивнее и быстрее).
Я вот ни разу вам не поверю, что, например, вам мышкой будет быстрее выделить строчку, нажать пр. кнопку мыши, нажать скопировать, передвинуть на новое место, нажать вставить, чем мне нажать 3 клавиши в виме.
ps. Я не утверждаю, что все должны пользоваться вимом, пользуйтесь чем вам удобнее. Но говорить, что мышка быстрее клавиатуры, это, извините, нонсенс.
> Ведь если нужно переместить на пять строчек вверх и 30 символов влево достаточно нажать клавиши вверх и влево по одному разу.
Это как?
Насколько я помню, в Виме можно собрать команду в командном режиме, которая уведёт курсор на пять строчек вверх и на 30 символов влево. Но это точно будет не «вверх и влево по разу». Это будет само по себе уже медленнее, чем дотянуться до мышки и обратно. Плюс к тому еще понадобится время на обдумывание, на сколько именно строк ты хочешь вверх и на сколько именно символов влево. Выше в комментариях товарищи пишут, как их «выкидывает из потока» необходимость тянуться за мышкой — а меня вот, например, начисто вышибает из потока как раз необходимость переключаться с раздумий о коде, который я пишу, на очередную заковыристую команду вима, а потом обратно. Возможно, к этому привыкаешь и, привыкнув, выполняешь на автомате — не знаю, я не смог.
И в этом вообще была моя главная проблема с Вимом, да и с Емаксом, до некоторой степени. Как редакторы-то они мощные и легко уделают любое IDE, без дураков. Более того, ниже товарищ пишет, что-де вот то да сё в Эклипсе удобнее чем в Виме — да, вполне может быть, что конкретное «то» и «се» действительно удобнее в IDE, но это только для каких-то совершенно определенных вещей, которые предусмотрели разработчики данного IDE, а в Виме из стандартного набора можно что хочешь собрать, о чем разработчики, возможно, и в страшном сне не помышляли. Но проблема в том, что эти преимущества Вима проявятся в полной мере только на какой-то нетривиальной задаче редактирования, возникающей раз в месяц, а то и реже. Допустим, я подумал, загуглил, еще подумал и нашёл способ, как сделать это в Виме супер-пупер-эффективно. С учётом времени на раздумья и гугление, я бы давно уже сделал то же самое в IDE, потыкав куда надо мышкой, конечно. Но теперь-то я уже умею в Виме и в следующий раз сразу быстро и эффективно сделаю, да? Нет. Ибо задача нетривиальна и понадобится её решать опять через месяц, за который я благополучно забуду своё нынешнее решение начисто. В результате опять думать, опять гуглить, и опять быстрее было бы потыкать мышкой в иде. Та же картина, кстати, и для ещё одной иконы опенсорса, написанной много лет назад, но до сих пор превосходящей и затмевающей — системы TeX. Всякий знает — ну или хотя бы слышал — что набирать формулы в TeX гораздо быстрее, чем в Word, и это факт. Вот только мало кто сидит и день за днём, час за часом долбит одни и те же формулы — прежде надо эксперименты поставить, расчёты провести, тексты написать, синтаксис формул опять успеешь забыть, опять гугль, опять дотянулся проклятый Кнут… (TeX крут, тем не менее, просто его истинная крутизна в другом.)
Клавиши перемещения курсора прямо на буквах — руки не нужно переносить. Можно возразить, что курсором медленно позиционировать. Но учитывая время перемещения рук до мышки, позиционирование курсора и обратно на клавиатуру, перемещение сразу с клавиатуры может быть более быстрым. Ведь если нужно переместить на пять строчек вверх и 30 символов влево достаточно нажать клавиши вверх и влево по одному разу. А можно еще и через слова прыгать! А время нажатия определяет перемещение. Кажется удивительным, но после тренировки точность перемещения за одиночное нажатие клавиши управления курсором достаточно высока.
А как вы позиционируете текстовый курсор в нужное место? Вопрос без сарказма, мне правда интересно. Вот я вижу точку на экране, в которую ткнул бы мышью — что вместо этого я должен сделать в виме/емаксе? Самый быстрый способ, до кторого я пока додумался — вызвать поиск и набрать сочетание символов из этого места, уповая, что оно уникально. Но даже если оно таки уникально, выходит, по-моему, не быстрее тычка мышкой, а если их таких оказалось несколько — так и тем более.
Хочу переименовать названия.
Пример №1: что делать, если ваш редактор не умеет сгенерировать объявление и тело метода одной атомарной командой.
Пример №2: что делать, если ваш редактор не имеет рефакторинга «выделить локальную переменную», который вызывается одной горячей клавишей.
Пример №3: что делать, если в вашем редакторе нет семантического выделения блоков CST-дерева.
Ну серьёзно. Я понимаю, что изучить vi может быть полезно, мало ли где окажешься. Я понимаю, что некоторые просто фанатеют от vi. Но заявлять «Или продолжайте использовать никудышный редактор кода своей IDE» просто глупо. В нормальных IDE (IDEA, Eclipse) всё из этой статьи можно сделать быстрее, удобнее и надёжнее.
Другое дело, что для этого хорошо бы иметь нормальную полноразмерную клавиатуру с полноценным командным блоком, ибо современные «дизайнеры» любят то блок со стрелками сделать в микроформате, то экспериментируют с расположением и наличием Insert/Delete и прочих допклавиш, а то и вовсе выстраивая их столбиком. (Отчасти я понимаю такие извраты в ноутбучном формате, когда нужно «впихнуть невпихуемое», но не понимаю как перенос данной концепции в десктопные клавы, так и использования ноутбучной клавиатуры при постоянном и объемном наборе, вместо того, чтобы подключить полноценную USB-клавиатуру).
Вообще же стенания поклонников VI/VIM о том, что их и VI не понимают, мне напоминают возмущения веганов.
«Вы просто десятипальцевым методом не владеете, вот и беситесь».
Ну и дискуссию по поводу удобства использования VI/VIM в качестве IDE можно закончить сразу, вспомнив основной аргумент, что VI легко превращается в IDE. Нужно всего-то: почитать доку, привыкнуть к стилю командному (!) редактирования, поставить пару десятков плагинов и написать под себя конфиг. Лично меня такой gentoo-style не устраивает.
Если мне нужен текстовый редактор — мне нужен именно текстовый редактор, а не коммандный процессор с функциями редактирования текста. Если IDE — значит полноценна IDE. Со всеми плюшками, которая она дает.
На вкус и цвет…
2. Команды эффективны. Вам все это было не надо, т.к. вим для вас был вторичным инструментом, или по другим причинам. Я вам не смогу объяснить, почему для меня он лучше. Все, что я написал — мой субъективный опыт, у вас он другой.
3. Если используете firefox — поставьте vimium, поймете разницу между мышиным интерфейсом и командами, и увидите, что быстрее.
2. Все вим команды через 3 месяца выполняются спинным мозгом не отвлекая и не создавая проблем в этом и есть смысл вима и это именно так и должно работать и работает у тех, кто вим освоил. Остальные жалуются.
В том и проблема, что Vim не масштабируется. На малых файлах это прикольное и «эффективное» (а скорее, «эффектное») копошение уровня «смотрите, как я умею!», на чём-то более крупном и сложном уже борьба с инструментом. Фанатизм и привычка использовать один инструмент мешают более конкретно очерчивать круг применимости, и это вполне естественно для большинства, ибо лень переучиваться или просто пробовать что-то новое, где не хватает чего-то привычного (а любые плюсы уже не ощущаются после этого).
Попробовать и освоить Vim однозначно стоит, особенно, если вы используете Linux. Для удалённого редактирования или локального в tmux/screen/tty, например, ничего лучше не найти. Просто это не замена для IDE, а совершенно отдельный параллельный инструмент для других задач, слабо связанных с программированием.
Спорное утверждение. На мой взгляд, тут вопрос не в языке, а в масштабах проекта. Пока это пара файлов, может быть, вим удобен тем кто уже потратил время чтобы его изучить, но учить его ради 10 файлов — странно. Но если проект развесист и имеет много внутренних связей — нужна IDE.
В идеале, чтобы дискутировать в этой теме адекватно, надо иметь хорошее знание и опыт Вим и ИДЕ. И даже пару раз в подобных темах возникало желание вим-таки освоить. Но потом понимаешь что это все эмоции и тратить время просто чтобы попытаться кому-то что-то доказать уже по возрасту не подходит.
Это больше похоже на хвост, виляющий собакой. Может, логичнее в существующие мощные IDE, которые синтаксически и семантически «понимают», что в них пишут программный код, а не набор букв и слов, так вот, в эти IDE прикрутить Vim-like управление? Собственно, это уже сделано, о чём и сам автор статьи упоминает. Всё ж как ни обвешивай текстовый редактор плагинами, он от этого IDE не станет. Будет просто редактор с кучей костылей, потому что он работает не с языком, а с текстом, не с проектом, а с набором файлов.
К слову, буквально на днях обнаружил, что Eclipse CDT понимает даже перегруженные операторы, и по F3 позволяет перейти к их определению. Учитывая, что выбор правильной реализации оператора жёстко привязан к типам аргументов, я не представляю, как эту задачу можно выполнить в Vim. Ну вот есть конструкция вида
cout << someObj << endl;. В эклипсе я встаю курсором на<<и жму F3, попадаю на реализацию этого оператора, могу прочитать и понять, что там не так. Этот оператор может быть реализован в стандартной библиотеке (за пределами проекта вообще), в сторонней библиотеке, в моём коде; может быть внутри класса, может быть свободной функцией. Выглядит он везде одинаково,<<, как же найти искомый? QtCreator, например, не умеет (пока) находить такие определения. В результате, перегрузки для Qt'шных типов найти либо сложно, либо нереально. А ведь возможность быстрой навигации по коду — это именно то, к чему апеллирует автор. И для программиста Vim именно эту возможность не предоставляет. Он даёт лишь быструю навигацию по тексту, которая довольно бесполезна, ведь программа состоит из множества файлов, классов, функций и библиотек, которые Vim не понимает.Я пишу все эти аргументы уже не первый раз, потому что в каждой статье от Vim-евангелистов пишется про рай для программистов, тогда как по факту это является неслабым таким преувеличением, мягко говоря. Стоило бы говорить о редактировании небольших текстов типа конфигов или ридмишек, тогда совершенно с этим соглашусь, ибо везде у меня Vim стоит редактором по умолчанию, и это первое, что я ставлю на минимальную систему. Пробовал и Emacs около года (даже как Jabber-клиент!), но в итоге надоело аккорды наигрывать. А фанатичность вообще до добра не доводит.
Первый пример неубедительный. Например, чтобы в Eclipse CDT сгенерировать реализацию методов (в любом количестве) по заголовочному файлу, мне достаточно нажать Alt+Shift+S, Up (Implement Method...), Enter, Enter. При этом, в примере не раскрыта тема C++, где простого копирования мало, надо ещё дописать название класса.
Второй пример также проигрывает эклипсу, выделяем код, который хотим извлечь в переменную, нажимаем Alt+Shift+L, пишем название новой переменной. Тип выводится автоматически, название переменной подставляется в место извлечения. Аналогично можно вытащить фрагмент кода в функцию с автовыводом типов входных параметров и результата.
Со стороны это больше похоже на имитацию бурной деятельности, ничего не понятно, грохот клавиш, текст скачет туда-сюда, и вообще всё выглядит круто и по-хакерски. Может, в каких-то случаях именно такое и нужно. В своей практике не встречал.
Мне кажется, именно в примерах со статически типизированными языками Vim наиболее наглядно проигрывает хорошим IDE, а для чего-то типа Python/JS/HTML/CSS или конфигов, конечно, он подходит лучше. С развеиванием разоблачения №5 я лично не согласен: программирование происходит в голове, а написание кода — это лишь небольшая промежуточная стадия между придумыванием кода и запуском его. Улучшать стоит то, что занимает основную часть времени. Если удалось ускорить какую-то операцию в 10 раз, это здорово! Но если она выполняется, скажем, раз в час и занимала 100 мс, а теперь 10 мс, тогда как непосредственно алгоритм отрабатывает по полминуты… это больше похоже на преждевременную оптимизацию ради оптимизации. Вот к скорости набора кода у меня такое же отношение.
:37 enter
v$hy
:12 enter
27lp
Если вы новичок в виме, то да, над каждой командой нужно думать, уйдет много времени. Если все в пальцах, то получается быстрее (тем более, если визуально 28 символ не сильно отделен). Опять же, я не призываю пользоваться вимом, пользуйтесь чем угодно. Но клавиатура в подобных задачах быстрее. Другой вопрос нужны ли эти выигрыши в скорости (вопрос почти как про преждевременную оптимизацию). За себя я могу сказать, что мне просто нравится работать таким образом.
Я вот ни разу вам не поверю, что, например, вам мышкой будет быстрее выделить строчку, нажать пр. кнопку мыши, нажать скопировать, передвинуть на новое место, нажать вставить, чем мне нажать 3 клавиши в виме.
ps. Я не утверждаю, что все должны пользоваться вимом, пользуйтесь чем вам удобнее. Но говорить, что мышка быстрее клавиатуры, это, извините, нонсенс.
В vim можно использовать easymotion
А в emacs или avy или ace-jump-mode.
Все они работают на похожем принципе:
Так можно за 3-4 нажатия клавиш переместиться в любое место на экране.
Разумеется можно переходить не только к началу слова, но и в произвольное место.
Это как?
Насколько я помню, в Виме можно собрать команду в командном режиме, которая уведёт курсор на пять строчек вверх и на 30 символов влево. Но это точно будет не «вверх и влево по разу». Это будет само по себе уже медленнее, чем дотянуться до мышки и обратно. Плюс к тому еще понадобится время на обдумывание, на сколько именно строк ты хочешь вверх и на сколько именно символов влево. Выше в комментариях товарищи пишут, как их «выкидывает из потока» необходимость тянуться за мышкой — а меня вот, например, начисто вышибает из потока как раз необходимость переключаться с раздумий о коде, который я пишу, на очередную заковыристую команду вима, а потом обратно. Возможно, к этому привыкаешь и, привыкнув, выполняешь на автомате — не знаю, я не смог.
И в этом вообще была моя главная проблема с Вимом, да и с Емаксом, до некоторой степени. Как редакторы-то они мощные и легко уделают любое IDE, без дураков. Более того, ниже товарищ пишет, что-де вот то да сё в Эклипсе удобнее чем в Виме — да, вполне может быть, что конкретное «то» и «се» действительно удобнее в IDE, но это только для каких-то совершенно определенных вещей, которые предусмотрели разработчики данного IDE, а в Виме из стандартного набора можно что хочешь собрать, о чем разработчики, возможно, и в страшном сне не помышляли. Но проблема в том, что эти преимущества Вима проявятся в полной мере только на какой-то нетривиальной задаче редактирования, возникающей раз в месяц, а то и реже. Допустим, я подумал, загуглил, еще подумал и нашёл способ, как сделать это в Виме супер-пупер-эффективно. С учётом времени на раздумья и гугление, я бы давно уже сделал то же самое в IDE, потыкав куда надо мышкой, конечно. Но теперь-то я уже умею в Виме и в следующий раз сразу быстро и эффективно сделаю, да? Нет. Ибо задача нетривиальна и понадобится её решать опять через месяц, за который я благополучно забуду своё нынешнее решение начисто. В результате опять думать, опять гуглить, и опять быстрее было бы потыкать мышкой в иде. Та же картина, кстати, и для ещё одной иконы опенсорса, написанной много лет назад, но до сих пор превосходящей и затмевающей — системы TeX. Всякий знает — ну или хотя бы слышал — что набирать формулы в TeX гораздо быстрее, чем в Word, и это факт. Вот только мало кто сидит и день за днём, час за часом долбит одни и те же формулы — прежде надо эксперименты поставить, расчёты провести, тексты написать, синтаксис формул опять успеешь забыть, опять гугль, опять дотянулся проклятый Кнут… (TeX крут, тем не менее, просто его истинная крутизна в другом.)