Те, кто привык к виму, будут продолжать им пользоваться, но новых адептов он уже вряд ли завоюет. Текстовые редакторы в IDE уже давно не убогие, то же контекстное выделение по CTRL+W в IDE от jetbrains для меня во многом проще, удобнее и нагляднее, чем отсчитывать скобочки для команды vim'а (а если ошибся, отменять и заново, потому что визуально не проконтролируешь в командном режиме).
Одно время пользовался vim-плагином, но в некоторых случаях он работал некорректно, так что просто забросил его. Потом пришло понимание, что при наборе текста бонусов от vim практически нет, при редактировании с лихвой хватает возможностей IDE, и, в конечном счете, выигранные миллисекунды не сложатся в сколько-нибудь значимую разницу, все-таки программистам не за набор текста платят.
Кстати, еще постоянно забывают о том, что для выхода в командный режим (то есть довольно часто) надо нажимать Esc, который, вообще-то, находится ничуть не ближе, чем курсорные клавиши, которые так не любят адепты.
Некто Лебедев предлагал для этого клавиатуру с изменяемыми надписями, когда каждая клавиша представляет собой небольшой программируемый экранчик. И даже вроде бы удалось изготовить целую серию таких клавиатур. Но в итоге, похоже, всё почему-то заглохло.
У этой проблемы есть решение. Правда пока дорогое — командные клавиатуры. такие используют в магазинах на кассовых терминалах.
Продаются, имеют разные размеры как по количеству клавиш, так и размерам самих клавиш.
Можно с такую забить все нужные комбинации и носить с собой работая в чужих системах.
Как показала история развития техники, самыми простыми являются интерфейсы без состояния. То есть, одна и та же кнопочка всегда выполняет одну и ту же функцию. Это позволяет меньше удерживать внимание на том, в каком состоянии сейчас находится интерфейс и больше внимания уделять собственно решению конечной задачи.
Например, подумайте про интерфейсы цифровых камер, сколько тут пересудов. И поскольку по сути они все равноценны для подавляющего большинства задач, споры Canon/Nikon/Sony/etc часто сводится к обсуждению «как неудобно делать то-то и то-то на такой-то камере», т. е. к эргономике интерфейса.
А почему с этим возникают проблемы у разработчиков… Ну, в камере очень дофига разных функций, и нужно как-то обеспечить к ним доступ. Самым первым появляется отдельный режим «меню настройки», а там страницы, а ещё режим «просмотра отснятого» и так далее… и в этих режимах органы управления, которые устанавливают диафрагму, выдержку и так далее, имеют другие функции.
И вот пока ты там копался перед тобой возник кадр, ты инстинктивно ставишь выдержку, спуск… и фейл, потому, что ты был в меню и выдержка не поменялась, а ты там вместо этого что-то прокрутил! У меня было такое, это очень обидно.
Более узкоспециализированный пример — микшерные пульты. Если у цифрового пульта «аналоговое» управление, т.к. каждая ручка ответственна только за одну свою конкретную функцию — это прямо пишут одним из первых пунктов, как преимущество! Ну и всё равно тут есть проблема — часто бывает, что есть «страницы», когда условно на 32-канальном пульте всего 16 фейдеров, и ты можешь переключать, 1-16 каналы ты сейчас рулишь, или 17-32; а для тембров и сабмиксов вообще выделен один набор органов, и чтобы поменять что-то в канале, нужно его выбрать и тогда только крутить. Некоторые приёмы, которые раньше работали на аналоговых пультах, тут недоступны — например, элементарно невозможно поменять панораму сразу на двух каналах (плавно «развести» их налево-направо) — крутилка панорамы одна, приходится регулировать каналы по очереди!
Именно всё это это и является причиной того, что «старшее поколение» с таким трудом осваивает современную технику, компьютер, да и вообще того, что компьютер приходится осваивать.
У вас конечно есть предолжение, как добиться подобного в vi — как сделать так, чтобы не нужно было думать о том, какие функции у кнопок в данный момент. Это уже ближе к идеалу, но выглядит как костыль: мы должны сознательно всегда входить в особый «модальный» режим ввода и сразу по окончании не забывать из него выходить. Очевидное развитие этой идеи в направлении упрощения — чтобы отдельного режима вообще не было… и мы приходим к традиционному редактору.
Обратите внимание, самым простым интерфейсом является карандаш. Никаких состояний в нём нет!
Плюсую. Если надо поковырять сложный скрипт или конфиг на удаленном сервере, где из дружественного интерфейса только терминал, знание 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 символ не сильно отделен). Опять же, я не призываю пользоваться вимом, пользуйтесь чем угодно. Но клавиатура в подобных задачах быстрее. Другой вопрос нужны ли эти выигрыши в скорости (вопрос почти как про преждевременную оптимизацию). За себя я могу сказать, что мне просто нравится работать таким образом.
Одно время пользовался vim-плагином, но в некоторых случаях он работал некорректно, так что просто забросил его. Потом пришло понимание, что при наборе текста бонусов от vim практически нет, при редактировании с лихвой хватает возможностей IDE, и, в конечном счете, выигранные миллисекунды не сложатся в сколько-нибудь значимую разницу, все-таки программистам не за набор текста платят.
Кстати, еще постоянно забывают о том, что для выхода в командный режим (то есть довольно часто) надо нажимать Esc, который, вообще-то, находится ничуть не ближе, чем курсорные клавиши, которые так не любят адепты.
Я бы ещё сослался на книгу Джефа Раскина — Интерфейс: новые направления в проектировании компьютерных систем. Он там, в том числе, достаточно убедительно обосновывает вред модальности для удобства интерфейса.
Продаются, имеют разные размеры как по количеству клавиш, так и размерам самих клавиш.
Можно с такую забить все нужные комбинации и носить с собой работая в чужих системах.
Например, подумайте про интерфейсы цифровых камер, сколько тут пересудов. И поскольку по сути они все равноценны для подавляющего большинства задач, споры Canon/Nikon/Sony/etc часто сводится к обсуждению «как неудобно делать то-то и то-то на такой-то камере», т. е. к эргономике интерфейса.
А почему с этим возникают проблемы у разработчиков… Ну, в камере очень дофига разных функций, и нужно как-то обеспечить к ним доступ. Самым первым появляется отдельный режим «меню настройки», а там страницы, а ещё режим «просмотра отснятого» и так далее… и в этих режимах органы управления, которые устанавливают диафрагму, выдержку и так далее, имеют другие функции.
И вот пока ты там копался перед тобой возник кадр, ты инстинктивно ставишь выдержку, спуск… и фейл, потому, что ты был в меню и выдержка не поменялась, а ты там вместо этого что-то прокрутил! У меня было такое, это очень обидно.
Более узкоспециализированный пример — микшерные пульты. Если у цифрового пульта «аналоговое» управление, т.к. каждая ручка ответственна только за одну свою конкретную функцию — это прямо пишут одним из первых пунктов, как преимущество! Ну и всё равно тут есть проблема — часто бывает, что есть «страницы», когда условно на 32-канальном пульте всего 16 фейдеров, и ты можешь переключать, 1-16 каналы ты сейчас рулишь, или 17-32; а для тембров и сабмиксов вообще выделен один набор органов, и чтобы поменять что-то в канале, нужно его выбрать и тогда только крутить. Некоторые приёмы, которые раньше работали на аналоговых пультах, тут недоступны — например, элементарно невозможно поменять панораму сразу на двух каналах (плавно «развести» их налево-направо) — крутилка панорамы одна, приходится регулировать каналы по очереди!
Именно всё это это и является причиной того, что «старшее поколение» с таким трудом осваивает современную технику, компьютер, да и вообще того, что компьютер приходится осваивать.
У вас конечно есть предолжение, как добиться подобного в vi — как сделать так, чтобы не нужно было думать о том, какие функции у кнопок в данный момент. Это уже ближе к идеалу, но выглядит как костыль: мы должны сознательно всегда входить в особый «модальный» режим ввода и сразу по окончании не забывать из него выходить. Очевидное развитие этой идеи в направлении упрощения — чтобы отдельного режима вообще не было… и мы приходим к традиционному редактору.
Обратите внимание, самым простым интерфейсом является карандаш. Никаких состояний в нём нет!
Хочу переименовать названия.
Пример №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 символ не сильно отделен). Опять же, я не призываю пользоваться вимом, пользуйтесь чем угодно. Но клавиатура в подобных задачах быстрее. Другой вопрос нужны ли эти выигрыши в скорости (вопрос почти как про преждевременную оптимизацию). За себя я могу сказать, что мне просто нравится работать таким образом.