После прочтения статьи еще меньше захотелось пользоваться Vim

Не обязательно использовать сам vim. Почти в каждой популярной IDE есть vim плагин, который покрывает существенную долю функций vim. Кроме плагинов разумеется, но это скорее плюс :)

Пользуюсь vim несколько лет, сколько не пробовал vim-плагины к IDE всегда плевался.

Я пользуюсь плагином к Intelij IDEA. Не вим, конечно, но без IDE очень тяжело, а с плагином редактировать текст значительно приятнее, если привык к режимам.

Чтобы выйти из него нужно нажать эскейп, а потом :q
А через ssh удобно…
В статье об этом не говориться.
Автору так и нужно было писать: Через SSH лучше Vima нет. Это его киллер фича.
Но в статье речь о режимах.
Хотя быть может это связано, не знаю, Vim не пользуюсь.
Автору так и нужно было писать: Через SSH лучше Vima нет. Это его киллер фича.

Нет, работа через SSH киллер фичей вима не является. Многие пользуются вимом, хотя по SSH ходят дай бог раза 2 в неделю. Киллер фича вима именно режимы.

Через SSH лучше VIM только sed.
ed, он даже для телетайпа годится.
Многие пользуются вимом, хотя по SSH ходят дай бог раза 2 в неделю.

Одно совершенно не отменяет другого. Для SSH нужны другие инструменты, пользоваться IDE по медленному SSH-каналу — это обычно тоже извращение.

На самом деле — у каждого своя киллер-фича.


Я использую vim уже, наверное, лет 15, может больше. Двигать курсор через hjkl пробовал многократно — внезапно, мне это неудобно. Комбинациями вроде diw владею, но на практике тааак редко нужно делать что-то подобное, а если это нужно редко то изменить текст нужным образом не используя vim-специфичные трюки занимает ненамного больше времени, а выглядит нагляднее. Конечно, на самом деле у меня много комбинаций "в пальцах", и я просто зачастую не понимаю, что делаю какие-то vim-трюки, потому что для меня это не трюки. И только когда возникает ситуация, что я не могу внести необходимое мне изменение в текст используя обычные для других редакторов способы редактирования секунд за 10-15 — вот только тогда я останавливаюсь, нажимаю Esc, и придумываю способ сделать нужное vim-трюками.


Когда я переходил на vim киллер-фичей была подсветка синтаксиса. Не она сама, а её корректность и скорость работы. Аналогов, особенно по скорости работы, в то время не было (Emacs не пробовал, правда).


Сейчас, после многих лет работы, настройки под себя, создания нескольких плагинов для vim — для меня киллер-фичей является единообразность работы с абсолютно любыми типами файлов — не важно, это код на любом языке, или текст, или SQL, или yaml, или конфиг-файл… везде одинаково открывается контекстная помощь по F1, везде одинаково работает автодополнение, везде одинаково проверяется синтаксис при записи файла, etc… Причём работает оно примерно так же, как 15 лет назад — исключая мои собственные изменения конфига vim и установленных плагинов (а вот сколько разных IDE лично Вы сменили за 15 лет, и сколько раз приходилось привыкать к изменениям после выхода новой версии той же IDE?). И, да, как локально так и на удалённом сервере. Ну и ещё возможность допилить настройки, если что-то начинает мешаться под ногами — оно, конечно, время жрёт, но лучше такую возможность иметь и пользоваться когда на это есть время, нежели не иметь ничего кроме кучки чекбоксов в настройках IDE.

а вот сколько разных IDE лично Вы сменили за 15 лет, и сколько раз приходилось привыкать к изменениям после выхода новой версии той же IDE?

В общем-то, я как выбрал для себя Netbeans лет пят назад, так на нём и продолжаю сидеть и по сей день. Даже контрибьютить в него всё хочу начать) Поэтому, всё-таки, ide — тоже вещь неплохая.


Вим почти не знаю и просто не вижу смысла изучать его в силу того, что на своём компе использую ide, а код на своих серверах правлю через Cloud9, когда возникает нужда.

режимы вима удобны через ссш :)
ssh -X 127.0.0.1 gedit =\
У вас на всех серверах иксы?
Много какие редакторы кроме gedit умеют работать с файлом по sftp. И в таком случаи чтоб что то отредактировать на сервере через тот же gedit или gimp достаточно иметь иксы на рабочей машине а не на сервере.

На сервере не нужны иксы чтобы запустить gedit по ssh. Иксов хватит и на клиентской машине.
Но такой путь все равно костылевостью отдает (по крайней мере для текстового редактора) :-)

С большой вероятностью gedit просто не удастся установить на сервер без иксов :) Пакетный менеджер по зависимостям их притащит :)
Он может протащить набор клиентских библиотек, но (при нормальных зависимостях) никак не xorg-server и тому подобные собственно отображающие части.
А всякие libX11 может потянуть за собой тот же vim, если собран в «полном» варианте с графической мордой.
Эти клиентские библиотеки составляют примерно 90% иксов :)
«90% иксов» это DE. А либы которые подтянет текстовый редактор, достаточно мелкие, их не много, да и есть просить не будут.
на пинге хотя бы 50 мс вы должны быть очень спокойным.
Я очень спокойный.

алсо, не вижу ничего плохого в редактировании файлов, проброшенных через sshfs, если со связью всё плохо, а графики хочется.
Автору так и нужно было писать: Через SSH лучше Vima нет.
Можно в emacs через Tramp mode подключаться к удаленному терминалу и работать через него как на локальной машине ;-)
> Через SSH лучше Vima нет. Это его киллер фича.

Теперь есть micro, по SSH он работает как в нативном терминале. И даже иксовый буфер обмена пробрасывается. Он прекрасен.
Ого. Спасибо за micro!

Использую mcedit (редактор midnight commander), удобно как по ssh так и локально. Особых недостатков перед графическими IDE не вижу. Vi только там где нет возможности запустить вышеуказанный, либо где настолько плохой коннект что он лагает перерисовкой экрана.

О, я не один такой, кто mc ради mcedit ставит )
я ставлю ради того, что бы выборочно копировать/перемещать/удалять файлы — там, где однострочник-регулярку слишком долго писать или оверкилл.
mcedit не нравится :(

Как в мседит скопировать в буфер обмена выделенный блок?

Как вариант: зажать Shift и выделить мышкой кусок текста в терминале.
После этого Ctrl+Insert и можете вставлять скопированные данные в другом окне/интерфейсе.
Работа с shift для выделения текста постоянно разламывается то в самом mcedit, то в эмуляторах консолей. Смешно, когда мышкой работает, а клавишами стрелок — нет.

f3 — выделить кусок — f3 — ctrl-f — Enter — перейти в нужное место — shift-f5 — Enter

Это не копирование в буфер обмена. Это копирование внутри редактора.
Ничего не понял. Мы вроде о текстовом режиме говорим — какой-такой «буффер обмена вне редактора» вы нашли в этом режиме???

Так именно в этом и проблема всех без исключения редакторов текстового режима...

> Особых недостатков перед графическими IDE не вижу

То есть, для вас нормально в одном месте для копирования текста нажимать Ctrl-C/V, а в другом месте F3/F5? И постоянно об этом помнить и следить за тем где вы выполняете шорткат?
Ну люди же работаю как-то на Mac'е где нужно помнить в какой программе это Ctrl-C/V, а в какой — Command-C/V и ничего.

Наоборот, когда шорткаты отличаются настолько сильно это вызывает меньше когнитивного диссонанса, чем когда отличие минимально — но таки есть…
Ну люди же работаю как-то на Mac'е где нужно помнить в какой программе это Ctrl-C/V, а в какой — Command-C/V и ничего.

Что за бинарное мышление? Наличие неудобства не означает, что его невозможно терпеть. А а возможность человека привыкать к неудобствам не означает, что эти неудобства не стоит устранять.

И в какой же программе на маке это Ctrl-C/V?

А ещё есть третий вариант Ctrl-Ins, Shift-Ins, который причём есть в двух вариантах (кнопки одни и те же, логика работы чуть разная). Это не проблема редактора в любом случае, ну а для меня это не кажется проблемой вообще — всё на автомате.

А я поставил к виму плагины ale, neco-ghc, ghc-mod, idris-mode и еще парочку, и теперь писать на хаскеле или идрисе — одно удовольствие. Других аналогичных редакторов не получится, разве что, Atom по части идриса приближается.

На плюсах пишу в clion, впрочем.
Много лет назад я был на вашем месте. Я читал подобный бред и не мог понять кто вообще в здравом уме использует этот идиотский Vim. А потом я взял себя в руки и просто что бы не оказаться в неприятной ситуации решил пройти vimtutor. Тем более, что обещали, что это всего на 20 минут. И буквально через 20 минут я понял, что хоть это и самый идиотский редактор в мире он при этом еще и одни из самых лучших.

Но при этом нужно сделать одно отступление. Он хорош если вы действительно много работаете с различного рода текстом. Код- лишь малая часть этого. И если с кодом для большинства распространенных языков есть варианты, то со всем остальным- дело может быть совсем плохо. Моя основная работа- инженер-связист. У каждого производителя железа свои закидоны. Например для сетевых элементов Ericsson скрипты нужно писать на языке, у которого даже названия нет. Во всяком случая я его в документации не нашел. И если языка нет, то и подсветки синтаксиса не существует. Как собственно и IDE под него. Но состряпать ее для Vim- совсем не проблема. Или вам нужно на оборудовании Huawei поменять один параметр на базовой станции. Но на каждой. У системы можно получить их список, но каждую строку нужно будет вручную переколбасить. Что-то оставить, что-то переместить в другое место, что-то убрать. И самое страшное в том, что эту операцию нужно будет сделать для каждой из тысячи строк. Vim поддерживает регулярки. Не несчастные вайлдкарды, а по полной программе. Одна команда прямо в редакторе и все готово. Конечно это можно сделать при помощи того-же Python и когда парсинг очень сложный, то я так и делаю, но очень часто хватает просто Vim.

PS: Я не являюсь фанатиком Vim и с удовольствием пользуюсь IDE. Но как по мне IDE + Vim звучит куда лучше, чем IDE или Vim.

Всё, что вы описали умеет любой современный редактор. И подсветка синтаксиса за 10 минут и рефакторинг по регуляркам и прочие радости жизни.

Бла-бла-бла… Vim поддерживает регулярки

Все поддерживают регулярки :)
Ваш случай достаточно уникален. Возможно для вас Vim прекрасный выход. Хотя регулярки не только Vim поддерживает.
А про мой случай: Я не хочу «брать себя в руки». Инструмент должен быть удобен сразу, без «взять себя в руки».
Уникальность этого случая скорее всего в том, что большая часть телеком оборудования сделана на основе кастрированного Linux и ничего кроме vi на борту такой конструкции просто нет. Гонять туда-сюда конфиг, чтобы поправить один парамерт весьма непродуктивно.

Э. Perl, например. Или даже sed. То что вы описали, вполне подоходит под описание автоматизируемой раз и навсегда задачи.

Не холивара ради…

Что мы узнали из статьи? Что клавишу E нажать быстрее, чем Ctrl+Right. Ок.

Я хотел сказать, что это может быть и не сильно быстрее, но, для многих людей, сильно удобнее.

но, для многих людей, сильно удобнее
Дополню фразу примером, чтобы было понятнее. Вспомните печатную машинку. Когда человек умеет быстро печатать слепым десятипальцевым методом vim для него гораздо удобнее. Все эти сочетания клавиш не просто медленнее, они мешают.
Вот собственно и суть фичи — vim хорош для быстрых манипуляций с текстом. Но саму разработку он не ускоряет. Там нет такого количества манипуляций с текстом (может быть веб?). Навигация по коду, поиск, рефакторинг — не уступают и не превосходят современные IDE. Они просто делают это иначе. Для vim нужно запоминать кучу однобуквенных сочетаний, для обычных IDE — кучу горячих клавиш. Разница возникает только когда человеку хочется трогать мышь или работать по удаленке.
Там нет такого количества манипуляций с текстом


В Vim есть все, что связано с любыми манипуляциями с текстом. В нем уже реализован любой бред, который вам придет в голову. Даже если вы придумаете это под тяжелыми наркотиками или попросите что-то придумать больного на всю голову психа даже не сомневайтесь. Vim будет на вашей стороне.

Хочу из списка слов разделённых пробелами получить все варианты их перестановок, каждый на отдельной строке.


Хочу по нескольким введённым словам получить осмысленное предложение-палиндром, начинающееся с них.


Хочу по введённой строке текста получить список словосочетаний, которые рифмуются с окончанием строки.

Разработка маленько не про текст, а про логику. И если это не верстка латеха или какого-нибудь html/css/xml больших манипуляций с текстом обычно не происходит.

Я не настолько быстро думаю, чтобы десятипальцевый метод что-то ускорил. Серьёзно. Набор текста в программировании — это вообще мизер.

Слепой десятипальцевый метод в программировании реально помогает. Не из-за ускорения набора текста программы, как такового. Из-за того, что не надо отвлекаться от обдумывания программы на борьбу с клавиатурой. Понял, что должно быть на очередной строчке твоей программы — дальше пальцы сами справятся, тыц-тыц, и оно уже там. Впрочем, надо заметить, что дурацкое расположение скобок и спец-символов на клавиатуре приводит к очень частым опечаткам именно в них и портит всю картину довольно сильно.

Опечатки… вот где особенно помогает слепой метод печати, так как они исправляются сразу, а не в тот момент когда оторвал взгляд от клавиатуры...

Много вы знаете людей, печатающих не слепым методом, но тупящих в клавиатуру не отрываясь?

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

Есть статистика с пруфами?

Нет, есть только личный субъективный опыт. Правда, большого количества людей. Найду статистику, обязательно поделюсь.

Я часто опечатываюсь с десятипальцевым методом, и часто знаю, что я опечатался и чуть реже, как именно я опечатался, даже не смотря на результат. Правда т.к. я на него обычно всё‐таки смотрю, то такая способность относится в первую очередь к паролям.

Достаточно, что бы их останавливать когда они пытаются в другой раскладке сообщение печатать...

Меня удивляют такие люди. Почему-то у меня нет "борьбы с клавиатурой" и алгоритм пользования мышью я не обдумываю(ну, знаете, вот этот типичный пример про "снять руку с клавиатуры, найти мышь взглядом, перевести руку на мышь, найти курсор взглядом, перевести курсор, кликнуть, снять руку с мыши, положить руку на клавиатуру").

Да кто вообще обдумывает алгоритм работы с мышью? У нормальных программистов сразу под клавиатурой находится маковский тачпад ;)

Вот ниже в комментах есть такие. И в любой теме про вим это всплывает.

Это у хипстеров маковский тачпад, а у нормальных программистов айбеэмовский трекпоинт прямо по среди клавиатуры.

Печатаю 300+ знаков в минуту, на vim-е работал с 1999 по 2004, потом пересел на emacs, ибо emacs удобнее.

Почему режимы суть гавно плюс-минус нормально написано у Раскина в его Интерфейсе.

А киллер-фича емакса (и такая фича очень мало у кого есть, что-то подобное есть в Atom/Visual Studio Code, но у них это очень примитивно) — это elisp, то есть возможность работать с кодом не через клавиши, а через команды (как командная строка). У vim-а его язык расширения очень примитивен, поэтому такой метод работы в нём неудобен.
Читаете вы тоже быстро :) Семантику моего комментария вы увидели, но не поняли смысл. Я писал не столько о скорости, сколько об удобстве для определенной группы людей, владеющей определенными навыками. Десятипальцевым можно и медленно набирать текст, но использовать сочетания клавиш при этом все равно неудобно. Другая техника.

Вообще, я уже давно не пытаюсь никого ни в чем убеждать в подобных спорах. Начинал с K52 для RSX-11M, а сейчас давно уже нахожусь в комфортном для себя балансе между vim и ide, а эту дисуссию посматриваю скорее из ностальгии. Десятки лет проходят, а темы холиваров не меняются :)
Я прочитал про удобство, и сразу в первом же предложении написал, что емакс удобнее.

Впрочем, тупо холиварить действительно скучно. Удобство в данном случае есть вкусовщина, тут действительно кому что любо, пусть то и юзает.
Ну тогда давайте вспомним vi-подобный EDT в том же RSX.
Почему режимы суть гавно плюс-минус нормально написано у Раскина в его Интерфейсе.

У Раскина написано, что плохие режимы это такие режимы, при которых пользователь не может чётко понимать в каком режиме он находится на данный момент. К виму это не относится, там забыть в каком режиме ты сейчас находишься достаточно трудно.


Пример плохого переключения режимов — циклическое переключение языков.

> К виму это не относится, там забыть в каком режиме ты сейчас находишься достаточно трудно.

Это, мягко говоря, неправда. В виме регулярно люди путаются, в каком именно режиме они находятся. Шутки про тройной долбёж по кнопке esc не на пустом месте, да и внезапно появившийся символ i в странном месте в пулл-реквесте тоже.
Это, мягко говоря, неправда. В виме регулярно люди путаются, в каком именно режиме они находятся.

Поначалу да, путаются.


Шутки про тройной долбёж по кнопке esc не на пустом месте

Во-первых, esc надо нажать не три раза, а два :). А во-вторых это нужно для того, чтобы гарантировано попасть в нормальный режим, в каком бы режиме ты не находился сейчас. Паник кнопка для новичков, которые могут не знать, в каком режиме находятся и для тех, кто отошёл от компа и не помнит что он делал.


О проблемах с символом i в пулл реквесте я не слышал.

> забыть в каком режиме ты сейчас находишься достаточно трудно.

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

Так же не понимаю, как можно считать редактор с режимами удобным, если постоянно приходится помнить, в каком режиме находишься. Плюс стандартные действия с текстом во всей системе осуществляются одним образом, а в vi другим. Как это может быть удобно — непонятно.
Как это может быть удобно — непонятно.
Тут вопрос не «как», а «кому». Тому, кто не путает вторую и четвёртые передачи, однако.

А профессионалов (причём не только у автогонщиков, но и у дальнобоев, коих несравнимо больше) этих передач может быть и два десятка, представляете?

Это не в упрёк вам — просто люди разные, кто-то в четырёх-пяти передачах путается, а кто-то и в 4-5 режимах VIM'а чувствует себя как «рыба в воде».
Смотрите по скорости (спидометр) и тахометру.
У каждой передачи свое соотношение.
Опередили. Вопрос ниже.
Del
Да, быстрее. Всегда быстрее набрать команды с клавиатуры, чем навести мышь.
Если привыкаешь писать код двумя руками, прерываться на то, чтобы, положить руку на мышь, найти курсор, навести его куда-то, нажать комбинацию кнопок на мыши и клавиатуре, вернуть руку на клавиатуру кажется не самой лучшей тратой времени.
Кроме того, использование только клавиатуры, а особенно если не приходится использовать сочетания, дает возможность по максимуму почти интуитивно использовать бытрые последовательности команд («мышечную память»). То есть я заранее знаю, какой набор действий надо выполнить, и могу это сделать очень быстро. С мышью такое невозможно — каждое перемещение курсора требует сосредоточенности и постоянного контроля, т.к. можно промахнуться.
Условно говоря, мышь — это аналоговый интерсфейс, постоянно требующий коррекции на основе телеметрии с экрана, а клаватура — цифровой, достаточно выбрать клавишу.
По сути IDE и Vim в равной степени позволяют писать код не отрывая рук от клавиатуры. И поддержка мыши скорее достоинство. Если вы что-то не помните вы берете таки эту гадость в руки и тыкаете в менюшку. В случае Vim-а нужно будет доки покурить.
Проблема не в использовании мыши. Проблема в подходе.

Вы не поверите В СКОЛЬКИХ местах IDE глотают нажатия клавиш, если кто-то набирает быстро и не глядя на экран. В VIM вы можете быть уверены, что набрав 100 команд не глядя на экран вы увидите то, на что рассчитывали. IDE (за исключением текстовых) в одном случае из 100 будет что-то глотать. Вроде бы немного, но это значит что ваши действия нужно контролировать после каждой команды. Иначе рано или поздно вы пропустите момент, когда какое-то окно не успело открыться (или закрыться), после чего уже все последующие команды пойдут «мимо контекста».

В том-то и дело, что на самом деле режимов у IDE в 100 раз больше, чем у VIM'а (окно редактирования свойств класса — один режим, окно открытия файла — другой, окно заливки в VCS — третий и так далее… сотни их… если не тысячи...).

Так что разница принципиальна: в IDE вы работаете с компьютером в режиме диалога, в VIM это «я сказал, компьютер сделал».

Никогда об этом не задумывался в таком ключе, хотя и сталкивался не раз. Спасибо за чёткую формулировку.

Забавно, что на самом-то деле это разница между TUI и GUI.

То есть когда я работал в каким-нибудь седом Turbo Pascal'е, то для меня не предоставляло проблемы нажать «не глядя» что-нибудь типа "<Ctrl+F7> x <Ctrl+F7> y <Ctrl+F8> <Ctrl+F9>" — всё это «не глядя», после чего я мог повернуться и что-то написать на листочке, пока комп всё это будет проделывать (у нас жётских дисков в компьютерном классе не было, а при работе с дискетки одно окно могло окрываться секунд 5). И это не вызывало ощущения «ужасающих тормозов»: думаю-то я всё равно не так быстро, так что после того, как я подал пару десятков команд могу и подумать над чем-нибудь ещё.

А вот в Clion гораздо меньшие тормоза — раздражают ужасно. Потому что я не могу «забросить» кучку команд и глотнуть кофе. Я должен за этим монстром приcматривать… и подавать команды когда он будет готов. Возникает вопрос: кто для кого работает — я для компьютера или компьютер для меня?

На машинке за $10'000 примерно, впрочем, тормозов почти нет и можно работать почти как в Turbo Pascal'е… потому что CLion успевает отреагировать на всё между двумя нажатиями клавиш… но есть ощущение какой-то неадкватности: неужели же вся эта моща нужна только, чтобы компенсировать тот факт, что мы используем GUI?

Обидно как-то…

Нет, тут разница скорее между однопоточностью и многопоточностью. То, что в однопоточной программе получается автоматически, в многопоточной (гуй — это почти всегда несколько потоков) требует намеренной реализации.

Это уже детали реализации. TUI тоже может запускать фоновые процессы, общаться с демонами и прочая, прочая, прочая. В конце-концов Vi, как бы, родился во вполне себе многозадачной системе.

А вот то, что это свойство в GUI реализовано намерено — тут вы правы на 100%. При работе с многими программами в этом даже есть какой-то смысл — действительно, не должна же моя среда тормозить из-за того, что в каком-то там браузере в фоне дизайнер навороты, грузящие одно из ядер на 100%, сделал… но почему эта беда должна наблюдаться в рамках одного процесса — мне решительно непонятно.

Потому что гуй к ним писали по тем же принципам что и сайты, там нет основного потока исполнения для формы (как было к примеру у delphi для для winforms) а если ещё и начинают использовать асинхронный js, то это же и выходит по сути страничка браузера. Меня это застало на vs от ms(большой не code) когда ты жмёшь быстро ctrl+f и текст, и первые буквы успевают попасть в файл с кодом т.к. окошко ещё не успело всплыть.
p.s. vim-ом не пользуясь, очень редко нужно писать быстро, и в основном это касается запросов к БД где ключевой ускоритель — подстановка названий полей.

Особенно подпишусь под надежностью.
Для администрирования, когда нужно быстро подправить какую-то опцию, учитывая возможности vi/vim в навигации по тексту, это особенно прекрасно в случае медленного коннекта. Например с мобильного телефона за пределами обитаемых мест.

в vim'e прекрасно то что если построить команду, то можно не запариваться что отобразится на экране секунд через 10, так как уверен что все Ок, но самое главное что это через какое то время доходит до автоматизма.

Да вы знаете, мы и в IDEA прекрасно пользуемся клавиатурой, там масса шорткатов. Есть даже режимы Find action и Search everywhere с клавиатуры — описывать не буду, посмотрите сами. Мышь используется по минимуму. Почти никогда не выделяю мышью текст — для этого есть стрелки и другие кнопки навигации с модификторами и Extend selection (Ctrl+W), Shrink selection (Ctrl+Shift+W).

Поклонники vim'а запоминили только, похоже, как выглядели IDE лет 20 назад.

Оно там тоже все есть)))
Разница между Vim и IDE…
Vim изначально рассчитан на горячие клавиши и построение команд, по этому с ходу тяжело научится этим пользоваться…
IDE позволяет постепенно уходить от мышки, меню к неудобным горячим клавишам, которые в команды не строятся.
В виме ведется работа с буферами, не важно что в них отображается, главное что они ведут себя одинаково.
В IDE каждое окно имеет свой интерфейс взаимодействия.
В виме я могу расположить информацию как угодно за счет буферов и вкладок(не только файлы) и перемещатся одними и теми же хоткеями.
В IDE я толком не могу разделить даже файлы в разном виде(горизонтально, вертикально, по 3, по 4, спрятать скрыть) конфигурации, не говоря уже о приятном интуитивном перемещении по ним.

просто +100500

Я не отрицаю, что в IDE можно работать без мыши. Но это не настолько удобно. И шорткаты в разных IDE разные, особенно Visual Studio от других отличается.

Не стоит тратить время. Они просто не понимают о чем Вы. Им нравится "не пробовал но осуждаю" и проходить vimtutor не будут.
Я им так скажу: "10 пальцевый слепой набор. VIM — руки всегда на месте, IDE — как минимум руки скачут к стрелочным кнопкам и/или мыше."
P.S. С условием что Esc на Caps Lock.

Ещё раз — зачем он нужен программисту, ваш десятипальцевый слепой набор? Ну добились вы 500 знаков в минуту, ок. И что? Я за это же время нажал 5 клавиш, а кода у меня получилось больше. В программировании набивка кода — это вообще не главное.

Ещё раз — зачем он нужен программисту, ваш десятипальцевый слепой набор?

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

По-вашему, существует два вида печати — ваш метод и "уткнулся в клавиатуру, ничего не вижу, страдаю, набираю в час по чайной ложке"?
И зачем программисту вообще переписываться с заказчиком, это работа аналитика и менеджера.

По-вашему, существует два вида печати — ваш метод и "уткнулся в клавиатуру, ничего не вижу, страдаю, набираю в час по чайной ложке"?

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


И зачем программисту вообще переписываться с заказчиком, это работа аналитика и менеджера.

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

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


Кто вам сказал, что теряется контекст при взгляде на клавиатуру? Это ваши домыслы. Программист может смотреть вообще в сторону, не на код, а в окно и не терять контекст. Если для вас контекст — это три строчки кода, у меня плохие новости.

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

Из моего комментария следует, что всем, кто владеет десятипальцевым слепым методом переписку вести удобнее, чем тем, кто не владеет.


Кто вам сказал, что теряется контекст при взгляде на клавиатуру? Это ваши домыслы.

Посмотрел на клавиатуру — потерял фокус на месте, где курсор. Когда возвращаешь взгляд надо искать курсор. Когда привык это практически не заметно, но на самом деле это и есть постоянное переключение контекста. Удобно, когда его не происходит.

Домыслы, субъективизм, проецирование личного опыта на других.
Всё, я в этой теме больше не отвечаю, сколько раз зарекался вступать в холивары с фаниатиками.

Домыслы, субъективизм, проецирование личного опыта на других.

Я хотел бы отметить, что это не только мои личные домыслы, а опыт большого количества людей. Кстати, вы умеете печатать вслепую? У вас есть такой опыт?


Всё, я в этой теме больше не отвечаю, сколько раз зарекался вступать в холивары с фаниатиками.

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

Из моего комментария следует, что всем, кто владеет десятипальцевым слепым методом переписку вести удобнее, чем тем, кто не владеет.

Нет, из него следует что всем, кто владеет слепым методом переписку вести удобнее, чем тем, кто не владеет.


Превосходство десятипальцевого метода над остальными вы не доказали.


Да и, честно говоря, потеря контекста тоже у вас вышла какая-то натянутая. Программист же не просто так набирает что-то, а ожидает после набора получить вполне конкретный результат. И в этот ожидаемый результат входит в том числе ожидаемое положение курсора.

Нет, из него следует что всем, кто владеет слепым методом переписку вести удобнее, чем тем, кто не владеет.

А я что написал?


Да и, честно говоря, потеря контекста тоже у вас вышла какая-то натянутая.

Вы умеете печатать не глядя на клавиатуру?

Вы умеете печатать не глядя на клавиатуру?

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

Я владею обоими методами слепой печати и не наблюдаю ни разницы в скорости набора, ни потерь контекста.

Меня вот, пока не научился не глядя на клавиатуру печатать, перенос фокуса с экрана на клавиатуру и обратно очень раздражал. И такие ощущения у достаточно большого количества народу. Надо опрос на хабре устроить :)

Меня вот, пока не научился не глядя на клавиатуру печатать, перенос фокуса с экрана на клавиатуру и обратно очень раздражал.

Меня тоже, и именно поэтому я сначала выучился печатать не глядя на экран. Это позволило увеличить скорость печати, в результате чего руки стали постепенно "запоминать" клавиатуру. А там уже получилось перестать на нее смотреть :-)


Но одновременно с этим меня перестал раздражать перевод фокуса между экраном и клавиатурой.

Это такой способ «застыдить»? Я вот не скажу — умею ли я печатать, не глядя на клавитуру, но таки тот факт, что на клавиатуре, на которой я набираю это сообщение нет русских букв меня не напрягает… И нет — раскладка у меня не ЯВЕРТЫ…
Это такой способ «застыдить»?

Нет, конечно. Интересно с точки зрения статистики.

Я без десятипальцевого не смотрю на клавиатуру и пишу почти без ошибок — ЧЯДНТ?

Вы всё делаете так. А с моей стороны — проблема с терминологией. Я говорил про способность печатать не глядя на клавиатуру. Каким методом — неважно. То есть, по моему мнению, владеть именно десятипальцевым методом не обязательно.

На самом деле такие статьи очень Важны. Для гуру это просто способ обсудить что то, для таких как я любителей которые никогда не смогут бежать быстрее черепашки это мостик который не перепрыгнуть! Просто «знающим» практически всегда непонятно что неясно новичку. А вы построили еще один мостик… спасибо!
А в виме нужно просто нажать e

Объясните мне, как не_пользователю_vim, как тогда в этом случае там набирать букву «е»? Или подразумевается, что для того, чтобы переместить курсор к концу слова, надо сначала перейти из режима набора текста в какой-нибудь режим навигации, а уже потом нажать е?

Именно так: из режима «вставки» в «нормальный» режим. Хотя у меня для таких мелких передвижений в режиме набора используются сочетания вроде <C-b>/<C-f> (назад/вперёд на символ), ,b/,w (назад/вперёд на слово), ,B/,W (назад/вперёд на СЛОВО (ограниченное пробелами: первый вариант переносит на f в (foo|, второй — на ()). (Я имею ввиду, не выходя из режима вставки.)


И стрелки с <C- вроде тоже поддерживаются, но до них далеко тянуться и с высокой вероятностью в терминале что‐то из стрелок с модификаторами работать не будет.

Спасибо, понятно. Ну тогда особых преимуществ я для себя и не вижу. Разве что полностью ломать парадигму набора текста, вместо «пишешь и правишь по ходу» на «пишешь всё, а потом правишь всё».
Делать под себя набор клавиатурных макросов может быть и удобно, но лишь до тех пор, пока не окажешься на другом компьютере, где их нет.

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

Трагизм ситуации в том, что на первом этапе работать будет очень неудобно и всё будет делаться очень медленно. В случае с хорошей IDE, это обычно не так.

vimtutor в помощь

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

Может быть, это дело привычки. Меня неприятно «радовали» всякие экзотические штуки вроде Atom, но если брать популярные IDE, вроде IDEA, Eclipse или даже Visual Studio, они все следуют устоявшейся схеме интерфейса, и все нужные функции оказывались там, где я их и искал.
Как по мне, IDE предоставляют две незаменимые фичи, отсутствие которых куда сильнее бьёт по продуктивности, чем +5% к скорости правки текста. Это навигация по коду а-ля «перейти к определению метода/класса» и рефакторинг.
«перейти к определению метода/класса»

Это есть и в vim, хотя да в IDE сделано лучше из-за того, что IDE держит в код в памяти в разных представлениях.


рефакторинг.

Ну да, тут явно лучше. Но опять таки какой смысл сравнивать ежа с ужом. vim это про редактирование кода, отсюда и популярность vim плагинов в IDE

В вим этого нет. Найти метод по названию можно, но если их десяток в разных классах? IDE анализирует код и знает, какого класса текущий объект. Для вим такого плагина не видел.

К виму вроде тоже можно прикрутить анализаторы и менять все вхождения методов/членов классов/прочих code entity. Даже для какого-нибудь Си++ думаю что-то найдется.
В вим этого нет. Найти метод по названию можно, но если их десяток в разных классах?

Нужен плагин для соответствующего языка. Например для Python и Go все это есть: подсказка будет учитывать экземпляром какого класса является эта переменная. По моим ощущениям качество подсказки для Python такое же как в Pycharm.


А вот автоформатирование Python, на мой взгляд в Vim слабее чем в Pycharm или Spacemacs.

А что, мелкий рефакторинг типа "переименовать метод" уже перестал быть редактированием кода?

Но с IDE в отличие от vim по началу не возникает разрыва шаблона с написанием текста.
Банальный Hello World получится написать на раз-два, а потом уже по мере необходимости вникать во все менюшки.
С vim же, насколько я понял, получается ситуация, что нужно изучить толмут по правилам работы с ним, чтобы можно было нормально работать, а потом уже человек сможет что-то сделать. Но возникает вполне закономерный вопрос, а зачем ему это, если под рукой есть текстовые редакторы и IDE с «классическим» алгоритмом печати текста.

Туториал изучается примерно за полчаса. Для начала работы надо запомнить примерно десять действий. Потом начинается процесс адаптации: желательно внимательно прислушиваться к совим дейтвиям и прикидывать а нельзя ли вот это действие, которая делаю постоянно сделать быстрее. И ответ на этот вопрос будет почти наверняка "да, в vim есть уже такая кнопка или команда".

В IDE точно так же надо привыкать к хоткеям (или настраивать их под себя). Елозить по менюшкам-тулбаром мышкой — это несерьезно, разве что поначалу для ознакомления. У меня в IDEA все тулбары отключены к чертям, все делаю хоткеями. Ну и IdeaVIM-плагин стоит, конечно :)

Пользователи вима ценят возможность проводить манипуляции с курсором и текстом без необходимости держать при этом зажатыми клавиши-модификаторы

… сочетания вроде <C-b>/<C-f> (назад/вперёд на символ), ,b/,w (назад/вперёд на слово), ,B/,W ..

Shift то все-равно придется зажимать для заглавных букв?
Shift то все-равно придется зажимать для заглавных букв?

Придётся. Модификаторы используются в виме и другими способами. Общее правило — чем короче действие, тем больше смысла использовать модификатор, а не режим.

Обычно автокомплит помогает

Да, но здесь‐то модификатор всего один! Впрочем, в терминале <ModX-ModY-x> не заработает практически никогда, поэтому если вам (хотя бы иногда) нужен именно терминал с Vim, то ничего назначать на «сложные» сочетания вы не будете, потому что не можете, а не потому что неудобно (я, к примеру, не вижу ничего сложного в <C-S-, нужно просто мизинец чуть больше (Ctrl на CapsLock) согнуть). Поэтому же в стандартных сочетаниях есть <C-буква(лат.)>, верхний регистр, все печатные ASCII символы и немного оставшихся <C-неБуква> из того, что есть в ASCII (вроде U+001D, <C-]>) и вроде даже <F1>, но больше ничего: Брам не любит добавлять возможности, завязанные на GUI, вплоть до того, что сочетание <C-S-x> внезапно означает то же самое, что и <C-x>, потому что именно так поступают все эмуляторы терминалов без настройки (а многие и настроить различать эти два случая нельзя). (В последнем предложении под x понимаются печатные символы из ASCII, <C-S-F1> в GUI нормально работает, иногда даже и в терминале.)


Кроме того автор из первой цитаты намекал на нормальный режим, а я написал, что я использую в режиме вставки. Впрочем, там тоже есть полезные сочетания с <C- и <S-, особенно с shift’ом.

Да, именно так. Кроме того, если вы переместили курсор к концу слова для того, чтобы что-то написать сразу после этого слова — нужно после клавиши e нажать клавишу a для перехода в режим введения текста.

Вот к примеру у меня(да и у многих знакомых разработчиков) есть такая привычка — сначала набираем две скобки(или кавычки, или любые другие парные символы), потом нажимаем стрелку влево и набираем то, что в скобках должно быть. То же самое в vim'е можно сделать только переключившись 2 раза из режима в режим и никак иначе?
нет, просто vim сам закрывающую скобку вставит сразу после открывающей, а курсор оставит между ними. По крайней мере emacs так делает, vim должен уметь так же
Так и IDE делают, смысл в том, что определенная группа людей отключают этот функционал, и набирают кавычки вручную
Люди делают вручную то же самое, что IDE может сделать автоматически? Зачем им тогда IDE?
У меня IDE например к сожалению так не умеет в основном языке, и если пишу на чем то другом — руки на автомате символы зеркалят:"", (),{},[], и т.д. Тем более что они рядом.
Я например отключаю этот функционал, когда правлю код — очень часто приходится дописывать одну скобку, которую IDE/vim услужливо дополняют, несмотря на наличие скобки далее.

Вопрос был — как сделать так в vim'е, а вы развели демагогию =(
я на вопрос ответил, нет?
Вопрос: «как напечатать 2 скобки, перейти внутрь этих скобок и писать там?»

Ваши ответы: «Он сам ставит закрывающую» / «зачем людям IDE?»

Как я и habrahabr.ru/post/339908/#comment_10468622 уже объяснили: «сам ставит» — вообще не выход из ситуации
Войти в режим редактирования и напечатать две скобки, нажать стрелку влево, печатать между скобок. Либо можно сделать так, чтобы вторая скобка сама допечатывалась. В режиме редактирования vim будет похож на большинство обычных редакторов. Т.е. печатаете, стираете, двигаетесь по тексту как обычно. А вот в «нормальном» режиме уже можно и быструю навигацию, всякие действия, выделения и прочее-прочее-прочее и того, за что любят vim те, кто им пользуется.
  1. vim из коробки не ставит закрывающих скобок.
  2. можно повесить любое действие на любое сочетание клавиш в любом режиме. Например, эту задачу можно решить так: если в режиме ввода нажать два раза \, то вставить пару скобок, перейти в командный режим, вместиться на символ влево, вернуться в режим ввода. Комментарий я писал дольше, чем команду.

:inoremap \\ ()^[i

Для такого иногда можно посоветовать всё же дополнение: с таким простым автозакрытием скобок возникают проблемы с undo (вставка скобок создаёт новый узел в дереве undo) и точкой. Лично мне первое не мешает, но вот второе сильно раздражает, хотя дополнение я так и не поставил: они имеют свойство ломаться с обновлениями Vim и не уверен, что сейчас вообще есть с работающей точкой (т.к. следил за vim-dev и иногда ловил сообщения «этот трюк сломался», но соответствующие ветки потом не особо читал).


Сам использую ,s (круглые скобки) / ,h ([]) / ,f ({}) / ,u (<>).


PS: Не нужно говорить про «любое сочетание клавиш» и «в любом режиме»: я знаю очень много контрпримеров, вот два самых простых: на первое достаточно просто <C-S-x>, на второе: вы знаете, что у YouCompleteMe есть «принципиально нерешаемая» проблема с неработающим <C-u>?

Для такого иногда можно посоветовать всё же дополнение

Да, дополнение лучше велосипедов. Команда только для демонстрации лёгкой расширяемости vim, это ни в коем случае не эталонное решение.


PS: Не нужно говорить

Спасибо.
Errata: "большинство сочетаний клавиш в различных режимах" =)


вы знаете, что у YouCompleteMe

Нет, из дополнений у меня только slime.

Ну современные IDE, не только ставят скобку (кавычку) автоматом, но если человк машинально после этого ставит её ещё раз, то они просто двигают курсор на позицию дольше. То есть вместо 3х кавычек получаются две и курсор за ними.

ага, в Vim также, удобно

Самая большая проблема этого подхода — в недетерменированности.

Я могу написать Кавычку перед строкой:
string"
и вторая не появится, а в остальных случаях появится. Или посередите строки я хочу сделать разрыв и вставить туда переменную, количество кавычек вставленных IDE я иногда предсказать не могу.

Поэтому мне кроме контекста надо всегда помнить, в каких случаях кавычка ставится, а в каких нет, и тратить время на борьбу с IDE. Мне лень, поэтому я отключаю эту шелуху. Скорость набора ну уж точно не падает.
Нужен плагин на автокомплит, например, `auto-pairs`. Набираешь скобку/кавычку и он сразу ставит закрывающую, а курсор оказывается между ними. Плюс, есть дополнительные возможности навигации.

Это страшно бесит, когда ты не пишешь новый код, а редактируешь существующий. Тебе надо поставить открывающую тут, а закрывающую там, а вместо этого ты занимаешься удалением невпопад добавленных закрывающих скобочек, кавычек и прочей ерунды. "Особо умные" редакторы ещё и удаляют эти символы парами, что особенно доставляет.

Нее, "особо умные" редакторы самостоятельно находят пару для скобок и кавычек и ставят их в случайном месте :-)

Да, случается. Если становится слишком много этих итераций, то можно забиндить `Toggle Autopairs` куда-нибудь на удобное сочетание, и переключаться между режимами по необходимости.

Неужели экономия одного нажатия рядом стоящей клавиши стоит введения ещё одного "режима"? Это совершенно не то место, где нужно оптимизировать. Вот закрывающие теги в HTML — это да, экономия. Хотя, куда лучше вообще отказ от HTML если не на уровне исходных кодов, то уж на уровне представления при редактировании — точно.

Прошу прощения, случайно минусанул, хотел поставить плюс за +1 режим в мозгу vs ставить вторую кавычку руками.
Это не одно нажатие, а два. Нужно сначала нужно поставить обе скобки/кавычки/…, а уже потом сделать «шаг» назад, чтобы начать писать что-то внутри :)
То же самое можно сделать подключив плагин и нажав одну открывающую скобку. Вторая добавится сама, и курсор встанет между ними.
(кстати не только в виме)
При корректно работающей эмуляции терминала (если клавиши со стрелками перемещают курсор) в vim (или даже vi) не требуется никаких дополнительных действий: i (или a), две скобки, клавиша влево и печатаем то, что в скобках.

Вы второй человек, кто упомянул слово 'стрелка влево', когда вся статья была о том, что стрелки моветон. Кроме того, в комментах звучала мысль, что контрол и шрифт — зло. И тут же были сочетания клавиш с заглавными буквами. Я печатаю вслепую на эргономичной клавиатуре, я понимаю, что такое до стрелок тянуться. Но вы мне весь шаблон рвете… То стрелки зло, то тут же советы со стрелками.

есть такая привычка — сначала набираем две скобки(или кавычки, или любые другие парные символы), потом нажимаем стрелку влево

Погодите, вы чем пользуетесь в 2017 году? Разве не во всех редактора кода уже давно по дефолту, что при наборе парного символа (левой скобки или апострофа) правый добавляется автоматом, а курсор остаётся между ними?

Ещё удобно настроить какое-нибудь сочетание клавиш, которое поставит точку с запятой в конце строки и забьёт Enter, после того, как ты ввёл содержимое последних скобок.

Например; + , ага :)

(; + Return) имелся в виду.

Если повезёт с разработчиками, есть возможность такую функцию отключить.
В IDE бывает, что можно не отключать: при наборе, например кавычки, вторая ставится, но становится выделенной, так что если сразу набрать вторую, их всё равно будет две, а не три.

Да проблема-то не в этом. Проблема в том, что иногда нужно обернуть в кавычки или скобки уже написанный блок текста — и тут-то автоматическое закрытие показывает себя во всей "красе".


Пример — гифка в комментарии ниже.

В IDEA сделано через жопу:

image

(да, есть replace quotes, surround selection но вот самый очевидный и базовый функционал — без элементарной эвристики, не понимает когда не надо добавлять кавычку)
А vim догадывается, что ему нужно врапнуть следомидущий токен?

В Vim этой ереси по‐умолчанию, к счастью, нет. Я люблю вставку открывающей+закрывающей сразу, но у меня это на отдельных сочетаниях клавиш. Плюс дополнение surround.vim, позволяет легко запихивать различные конструкции в скобки/кавычки/… или удалять сразу два парных символа.

Если в vim-е вы в режиме редактирования (а Вы в нём, если набираете скобку) то последовательность такая же. Пишете зеркальные скобки, потом нажимаете стрелку влево и набираете то, что в скобках должно быть.
Иногда в режиме вставки работают и стрелки на клавиатуре.
Если нет — 2 переключения: Esc, i

Всегда приходится неистово нажимать esc до пиканья в консоли, чтобы случайно не оказать не в том режима и не начала происходить неведомая хрень, что придется вырубать питание))))

Печально, но если задать этот вопрос среднестатистическому гуру вим-гольфа — он его просто не поймёт.

Любой, кто постоянно пользуется вимом и осилил хотя бы базовый набор функций, легко ответит вам на этот вопрос, не нужно утрировать.

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

Ваша фраза очень смахивает на вим-фанатизм по типу религиозного.
Ваш ник, вон, тоже кое на что смахивает, и что? При чем здесь фанатизм, тем более, религиозный? Любой, кто пользуется чем угодно длительное время на приемлемом уровне, способен дать ответ, в чем для него заключаются преимущества.
Буквально в прошлой холиварной статье на хабре писали и про удобную навигацию по тексту, и про возможности кастомизации плагинами, коих сотни, и про быструю развертку своего конфига на удаленном сервере. Режимы просто дают возможности, сами по себе они сомнительные киллер-фичи.
Режимы просто дают возможности, сами по себе они сомнительные киллер-фичи.

Возможности, которые дают режимы, можно предоставить и без них. Но нередко люди хотят именно модального интерфейса.

удобную навигацию по тексту, и про возможности кастомизации плагинами, коих сотни, и про быструю развертку своего конфига на удаленном сервере

Удобство понятие относительное, меня например устраивает вариант ctrl+стрелка.
Остальные «фишки» вполне себе реализуются с использованием классического сейчас интерфейса.
Так какой же ответ, который будет знать любой, кто осилил базовый набор функций?
Именно тот ответ, который я написал.
Перемещение по тексту — это о том, что я могу не брать в руки мышь. В любое место на экране я попадаю практически мгновенно либо через стандартные команды, либо через easymotion плагин когда нужное место где-то далеко внутри строки. Если вам нравится нажимать ctrl-стрелку, чтобы перейти строк на 20 вниз и в сторону, ради бога, только о какой оптимизации мы вообще тогда говорим?
Кастимиированная версия вима переезжает на удаленный сервер ровно за то время, которое требуется, чтобы сделать clone из моего репозитория.
Плюс интеграция с tmux.
Код в Vim писать это дичь, конечно. А в качестве штатного консольного редактора — очень удобен. Всяко лучше всяких nano, например. Ну и при удаленном подключении удобен, например.
А что не так с nano при удаленном подключении?
Бывают проблемы, из собственной практики с серверами со встроенными средствами удалённого доступа через консоль по внутренней шине. Типа RSC и ILOM для Sun/Oracle или HMC для IBM. Тогда обычно помогает установить эмуляцию в vt100, чтобы ввод/вывод не ломался. Но это явно не про ежедневное написание кода, а чтобы конфиги поправить :)
Ну если прям придираться, то иногда его не удается подружить с mc. Нажимаешь ctrl + o, чтобы засейвить файл, а после этого, в зависимости от системы, все либо идет по плану и файл сохраняется, либо вылетает на панельное меню mc. При следующем нажатии ctrl + o уже не видно сам редактор, но хоткеи nano все еще работают и можно даже засейвиться по ctrl + x. Т.е. не то чтобы прям проблема, но бесит.

На старых mc у vim та же проблема — ctrl-o перехватывается.

Если сравнивать nano и vim, то это всего лишь дело привычки. Разве нет?

Ну, фраза "Всяко лучше всяких nano, например." подразумевала что есть какие-то объективные причины.

А что не так с писанием кода в Vim?

Очень даже хорошо пишется код в Vim, уже лет 10 им пользуюсь, 6 из них пишу код.
Надо просто понимать что Vim это продвинутый редактор с удобным интерфесом за счет режимов и кучей плагинов.


Но если нужно изучить код, то конечно лучше IDE

Режимы не фатальный недостаток, а киллер фича, но в чем конкретно она заключается нам не скажут.

Сначала в статье был длинный кусок на эту тему, но в конце концов я понял, что для нормального объяснения нужно 3 таких статьи с прикреплёнными видеороликами. Поэтому я оставил ооооочень маленький кусок про необходимость переключаться между режимами с помощью клавиш i и эскейп, а также про перемещение курсора без клавиш-модификаторов в режиме вставки. Придумать, как хорошо продемонстрировать, что такое режимы, не смещая при этом фокуса статьи я не смог :(

Но тогда, получается, статья лишилась смысла. Кто знает, что такое режимы и чем они хороши — тем не нужна статья, а кто не знает — тот так и останется в неведении.
Но тогда, получается, статья лишилась смысла.

Статья писалась для того, чтобы те, кто хочет выяснить чем хорош вим — выясняли чем хороши режимы, а не пытались понять ради чего пользователи их терпят.

При этом получилось, что из статьи мы лишь узнали, что вместо привычного Ctrl+вправо нужно делать два перехода между режимами и нажимать нелогичные на первый взгляд клавиши. Мне например, как человеку, который не работал с вимом, осталось неясно, почему второе круче и лучше первого.

Я хотел, чтобы из статьи было понятно, что причина использовать вим — режимы. Я лично знаю несколько человек, которые узнали что такое режимы, знают, как ими пользоваться и при этом считают их досадным пережитком старины и продолжают попытки выяснить в чём всё-таки настоящая сила vim.


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

В 2017 году на хабре втирают, что режимы — это хорошо. Куда катится мир.
programming-lang.com/ru/comp_programming/raskin/0/j38.html

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

Осильте классика по ссылке. С любым модальным режимом такая проблема есть.

Нет с вимом таких проблем. Текущий режим считывается одним взглядом в левый нижний угол.


image

И про это там тоже есть. Можете поискать по "не находится в локусе внимания".

В каком режиме ты находишься как правило легко понять по форме курсора, который как раз находится в этом самом локусе. Проблем с пониманием в каком режиме сейчас находится пользователь в виме нет.

тут ведь какое дело — у тех кто пользуется — проблем нет, потому и пользуются. У тех у кого есть проблемы с вимом — они им не пользуются. Это тоже очевидно. Непонятно почему вторые первым пытаются что то доказать. (когда первые вторым доказывают — досадно). Сам вимер если что.
Да у всех они есть. Те кто пользуется — переборол себя, выработал рефлекс, научился подсознательно различать режимы. Это не значит что их нет и что режимы — это не отстой.
Мда. Открываем блокнот, печатаем. Хотим сохранить — жмем в меню на файл->сохранить как. Внезапно и неожиданно — мы поменяли режим. Как и в любом GUI. НЕТ НИ ОДНОГО редактора или IDE в котором бы не было режимов, просто в большинстве их очень много и они завуалированы настолько что пользователи не понимают что это режимы. Да, и в статье по приведенной выше ссылке — ошибками UX пытаются обосновать ненужность режимов — это не выдерживает никакой критики.
Мои тезисы были, что режимы — это отстой, хоть в виме, хоть еще где и выкидывают из состояния потока они везде одинаково. Я привел в качестве аргумента ссылку на классическую работу, от признанного специалиста по пользовательским интерфейсам, посвященную режимам.

Вы же пока привели в качестве аргумента пук в воздух.

Нигде я не говорил, что без режимов можно полностью обойтись. Но вообще-то есть способы минимизировать вред от них, они описаны в том числе по моей ссылке, работа еще 80-х годов. И уж тем более глупо писать, что режимы — это преимущество вима. Без режимов он был бы в сто раз прекраснее.

Про блокнот, видно что 3 страницы текста по ссылке вы осилить не способны, чтобы дочитать до понятия квазирежимов, например, позволяющих сохранять файлы через Ctrl+S, которое есть хоть в блокноте, хоть в саблайме, а в куче редакторов вообще автосохранение. Пук в воздух, о чем речь. Не позорьтесь.
Про блокнот, видно что 3 страницы текста по ссылке вы осилить не способны, чтобы дочитать до понятия квазирежимов, например, позволяющих сохранять файлы через Ctrl+S, которое есть хоть в блокноте, хоть в саблайме, а в куче редакторов вообще автосохранение.
Автосохранение с автопридумываением имена файла, я так понял? Речь идёт о том, что выполняя определённое действие вы попадает в другое окно, в котором у вас другой мир и старые команды не работают. Работает только… барабанная дробь клавиша ESC. А иногда, кстати, и она не работает.

Так чем эти режимы (коих десятки в так восхваляемом вами Sublime) лучше того, что в VIM'е? Тем что там нет отдельного режима редактирования и ввобда текста? Но есть отдельные режимы (без всяких «квази», я статью прочитал, не беспокойтесь) для ввода имени нового класса, строки для поиска и прочих интересных вещей? Чем режим поиска текста в Sublime лучше командного режима в VIM'е? Тем что Sublime вам нравится, а VIM — нет?
Вся статья про то, что в виме два основных режима, и это типа хорошо. Причем тут режим поиска текста и окна сохранения? Это альтернативные режимы работы других редакторов что ли? И еще, может быть, где-то придумали, как в этих местах модальности избежать? Что за чушь вы пишете?
Причем тут режим поиска текста и окна сохранения? Это альтернативные режимы работы других редакторов что ли?
Таки да. При редактировании текста я поиском очень часто пользуюсь.

И еще, может быть, где-то придумали, как в этих местах модальности избежать?
Дык разумеется! Вы тут поминаете всуе Раскина, а Canon Cat когда-либо видели? Ну хоть на картинке? Вот у него как раз всё сделано «по феншую»: поиск — это не отдельный режим, а отдельный квазирежим.

Вся статья про то, что в виме два основных режима, и это типа хорошо.
Это не мы говорим. Это ваш «гуру» говорит:
Иногда разработчики говорят, что режимы нужны потому, что число необходимых программных функций превышает число жестов, которые пользователь может выполнить с помощью клавиатуры и графического устройства ввода, поэтому жесты должны использоваться многократно. Однако число команд, исполняемых с помощью монитора (например, меню), и команд, вводимых с клавиатуры в командную строку и содержащих множество символов, может быть неограниченным и потому позволяет избежать упомянутой трудности.

И? Где в вашем Сублиме командная строка, позволяющая избежать перегрузки интерфейса режимами?

Вся статья про то, что в виме два основных режима, и это типа хорошо.
Именно так. Имеющиеся в VIM'е три режима позволяют обойтись без десятков и сотен режимов и режимчиков, которые имеются в других редакторах — тем и хороши.

Попытки же борьбы за «интерфейс без режимов» под руководством Раскина так ни к чем популярному не привели, как вы верно заметили.
Тут я бессилен, нужны доктора.
Хотя, время есть немного, давайте разберем этот треш в мозгах:

Таки да. При редактировании текста я поиском очень часто пользуюсь.


Именно так. Имеющиеся в VIM'е три режима позволяют обойтись без десятков и сотен режимов и режимчиков, которые имеются в других редакторах — тем и хороши.


Режим поиска в блокноте — это не альтернативный основной режим работы блокнота. Точно такой же подрежим внутри одного из основных режимов есть в виме и в любом другом редакторе — потому что как-то же надо дать команду начать искать — а значит — переключиться в режим поиска.

Режим сохранения файлов требует ввода имени, если файл новый. Хоть в блокноте, хоть в виме, хоть где-то еще. Внутри вима вы точно также при сохранении файла выпадаете из потока и вводите имя файла при сохранении — это тоже дополнительный режим — такой же как в блокноте.

Еще раз — эти режимы есть и в блокноте, и в вими. Зачем вы их сюда приплели? Давайте приплетем режим саблайма, альтернативный основному? Есть такой? Нет! А в виме — есть. Вот об этом и речь.

Кэнон Кэт я видел вживую в Музее компьютерной истории, и что? Причем тут Кэнон Кэт?

Это не мы говорим. Это ваш «гуру» говорит:

Мой «Гуру», в кавычках, подмена понятий, как мило. С такими аргументами в спорах, как у вас в российских новостных говноизданиях не пропадешь, вы часом не оттуда?

Попытки же борьбы за «интерфейс без режимов» под руководством Раскина так ни к чем популярному не привели, как вы верно заметили.

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

У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд. С сохранением то же самое. «Тем более» в начале я сказал, потому что именно у поиска есть несколько отличий, в т.ч. несколько дополнительных клавиатурных сочетаний, тогда как сохранение делается только командой без каких‐либо особенностей. И «команда» здесь в смысле «выражение на языке программирования, выполняемое ради побочных эффектов (т.е. без возвращаемого значения)», какое выражение прекрасно сочетается с другими командами, если нужно, а не что‐то, позволяющее только написать имя файла и больше ничего.


PS: «плагинчики для гиков» почему‐то есть в стандартной поставке: то же https://github.com/JetBrains/ideavim откуда‐то имеет бейджик «JB official» (хотя и требует отдельной установки) и упомянуто в официальной документации, а не в редакторах, но интерактивных оболочках вроде bash, zsh и fish (последнее ещё и называет себя «friendly interactive shell») аналог есть без установки каких‐либо дополнений. Зачем JetBrains внезапно официально поддерживает «плагинчик для гиков», вам не кажется это странным?

У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд.

Нет, не так — чтобы искать надо ввести "/" и после этого вим поймет, что он в режиме поиска. А в Sublime типа не так? Так, только там Ctrl+F и сразу можно искать, а тут режим команд, затем "/"? Но в Sublime по вашему это «режим поиска», а тут — нет? С какой стати?

С сохранением то же самое.

Что — тоже самое? При сохранении нового файла его имя для файловой системы вводить надо? Надо. Из потока вылетаем? Безусловно — локус внимания смещается а командную строку в поле ввода имени файла. Ну а в блокноте на модалку с выбором папки и тоже полем ввода имени файла. А здесь — командная строка — а суть-то одна. Этого режима нельзя избежать, только минимизировать, например автосохраняя файлы с дефолтным названмем при создании.
Зачем JetBrains внезапно официально поддерживает «плагинчик для гиков», вам не кажется это странным?

Чтобы расширить потенциальную аудиторию за счет гиков и заработать больше денег, как и подобает разумной компании?

Режим ввода команд начинается в том числе с /, но вопрос не в этом: в sublime есть именно режим поиска, который не основной, и который сделан с одной узкой целью со своим узкоспециализированным элементом интерфейса. Сохранение тоже позволяет только сохранять, и тоже имеет отдельный интерфейс. В Vim есть режим для ввода команд редактору, но он не настолько узко специализирован и интерфейс для ввода поисковой строки практически не отличается от интерфейса для ввода команды сохранения. Кроме того, командный режим официально признаётся режимом, и при том одним из основных.


И ещё, нет такой вещи, как «поле ввода имени файла», оно часть команды. Внимание смещается просто в командную строку.

Внимание смещается просто в командную строку.

Внимание смещается.

Еще раз, если до сих пор непонятно — и там и там для использования функциональности присутствуют режимы, которые вынимают внимание пользователя из потока работы с текстом. Как конкретно это выглядит, какими конкретно клавишами вызывается — это десятый вопрос. То что в виме весь дополнительный функционал построен вокруг CLI с одной точкой входа, а в других редакторах — вокруг GUI(кстати бывают с одной точкой входа, Spotlite-like окошки с умным автораспознаванием ввода) — ни на что не влияет в плане необходимости модальности — чтобы обратить внимание юзера что он сохраняет файл, или что то ищет.

Где я или кто‐то ещё говорил про «одну точку входа»? Она там не одна, режим там один на много разных вещей. С необходимостью или наличием модальности я не спорил, я спорил только с определением количества режимов.


(А spotlite-like окошки — это хорошо, но это не вопрос «CLI vs GUI», на ncurses для своей программы при желании можно и такое написать, просто пока никто одновременно хочет и способен это сделать, да и приложений, где такое было бы оправданно, для терминала не слишком много. Да и не то что ncurses, специально для Vim можно подпилить какое‐нибудь дополнение вроде ctrlp.)

Где я или кто‐то ещё говорил про «одну точку входа»?

Где я сказал, что вы это говорили?

Она там не одна, режим там один на много разных вещей. С необходимостью или наличием модальности я не спорил, я спорил только с определением количества режимов.

Альтернативный основному с кучей встроенных в него режимов, это про количество. Там где у других — просто куча тех же встроенных режимов вокруг единственного основного режима.

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

Единственное концептуальное отличие VIM'а от других редакторов является то, что режим ввода текста тут не является основным. Хорошо это или плохо — зависит от вашего стиля редактирования: если вы из тех, кто заголовок в Word'е центрует пробелами, то вам VIM точно ни к чему.
Но зато там есть куча режимов и режимчиков, которых тоже могло бы и не быть.

Точно также как и в виме, вызываются только по другому. А вот командного режима, равнозначного по важности режиму набора текста в них нет, и это замечательно.
У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд.

Мнэээ… но ведь результаты применения разные — после '/' будет поиск по регулярному выражению, а после ':' — выполнение команды.
Даже если редактирование одинаково, это таки вполне соответствует понятию "режим".
(И я не говорю, что это плохо.)

Кэнон Кэт я видел вживую в Музее компьютерной истории, и что? Причем тут Кэнон Кэт?
Мы вроде как о поиске тут говорили? Ну так вот у него — такие большие красные клавиши есть. Их очень сложно не заметить. Именно для того, чтобы этот самый поиск без создания режимов производить.

Режима задания имени файла том тоже не было (могли бы поинтересоваться тем, как это было сделано, раз уж вы такой фанат).

Исследования Раскина и других привели к тому, что ни один современный текстовый редактор не идет по пути вима.
Neovim, первая версия которого вышла в 2015 году — для вас недостаточно современен?

Или вы про то, что все современные модальные редакторы используют подход VIM'а? Ну так и с немодальными та же история — сплошной Ctrl+C/Ctrl+V, куда ни плюнь.

А вот попытки избавиться от режимов в принципе (и от режима ввода имени файла и от режима поиска подстроки и от командного режима) — не удалось настолько, что когда вам в это, я извиняюсь, тыкают носом — вы начинаете кипятится и пороть чушь:
Режим сохранения файлов требует ввода имени, если файл новый. Хоть в блокноте, хоть в виме, хоть где-то еще.
Не требует, если система соответствующим образом спроектирована. Ни в Canon Cat, ни в Archy этого не требуется.

Мой «Гуру», в кавычках, подмена понятий, как мило.
Где я подменил понятия? Если бы Раскин для вас был настоящим Гуру, без кавычек, то, уж наверное, если бы не пользовались средой, воплотившей его идеи (отказ от окон, команды вместо программ, ZUI и прочее), то, как минимум, знали бы о них.

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

А тот факт, что об идеях Раскина даже его самоназваный фанат не подозревает — по моему характеризует «величие» его наследия лучше, чем что-либо ещё.
Господи, сколько шума на ровном месте. Раскин в ветке появился как самый известный человек, описавший проблемы режимов, даже для таких лососей, как автор поста или вы, бегающие и вещающие, какие в виме они офигенные.

Доступность изложения даже для совсем тупых — вот был критерий приложить ссылку на часть книги Раскина, а не то, что я его фанат. Я, так-то, много кого фанат.

https://en.wikipedia.org/wiki/Mode_(computer_interface)
Поспорьте с Википедией, с Дональдом Норманом из Nielsen Norman Group и еще с кучей ученых, изучавших эту область поплотнее, чем мутный графоман с хабра.
Раскин в ветке появился как самый известный человек, описавший проблемы режимов

И я считаю, что для вима эти проблемы либо не свойственны, либо преимущества режимов с лихвой компенсируют их недостатки.


Поспорьте с Википедией

Хорошо, давайте поспорим с википедией :). Прежде всего в качестве самых ярких примеров проблем с режимами там приведены примеры использования клавиш CapsLock и Insert. Но эти клавиши не вредны, а просто бесполезны. Проблемы с ними возникают когда ты случайно нажал одну из этих клавиш и пытаешься понять, что произошло. Намеренно их используют очень редко. Поэтому в контексте проблемы режимов о них говорить особого смысла нет.


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


И наконец, речь заходит о vi. Википедия упоминает, что для новичка vi сложен из-за режимов. Опять же, согласен :). Для новичка привыкнуть к режимам непросто. Для того, кто привык без них уже тяжело.


Немного о влиянии работ Раскина на текстовые редакторы


И отдельно хочется обсудить последний пункт из википедии. Где-то выше по ветке вы упомянули, что таких редакторов, как вим больше не делают благодаря работам Раскина. По-моему это называется социальным доказательством.


Так вот, реальный пример повседневного использования режимов, который причиняет вред и мешает работать большому количеству людей это циклическое переключение раскладки клавиатуры. И, несмотря на наличие работ Раскина, дискуссия о переключении раскладки как правило сводится к тому, какой клавишей её лучше переключать.


Те, кто не хочет заморачиваться используют дефолтный Alt+Shift, более продвинутые меняют его на Control+Shift, постигшие дзен слепой печати возвращаются обратно к Alt+Shift, потому что это позволяет не двигать руку, а маководы сидят на Command+Space, не знаю почему.


Самые решительные и радикальные настраивают переключение раскладки на клавишу CapsLock.


А, между тем, по уму нужно от циклического переключения раскладки отказаться и забить хоткей на один язык и хоткей на другой. Однако тех, кто делает так, можно перечесть по пальцам.


Как же так вышло, что в случае с текстовыми редакторами, рекомендациям Раскина последовали, а в случае с переключением раскладки — забили на них большой болт? По моему мнению, Раскин тут вообще не при чём. Модель редактирования текста, используемая большинством текстовых редакторов исторически появилась раньше, чем модель, используемая в виме и для начинающего пользователя она гораздо проще. Поэтому она и распространена. С переключением раскладки точно так же.


Кстати, интересно, как вы переключаете раскладку?

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


Я привык переключать раскладку через RAlt+Shift и не испытываю никаких проблем (кроме того что с некоторого момента винда из коробки не поддерживает этот способ, а также раздолбанного шифта — но эти недостатки сохраняются и при переключении раскладки через два разных хоткея).

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

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

Вы зря переключение языка по разным клавишам считаете решением. Предлагаемый вами подход приводит к одному из 2 сценариев:


  1. Если пользователь переключает раскладку лишь когда думает, что сейчас не та, то получает одни и те же проблемы что с одной клавишей переключения, что с двумя.
  2. Если пользователь переключает на нужную раскладку каждый раз начиная ввод, то это очень дофига ритуализированных нажатий. Любое сколь угодно краткое вырывание из потока ввода текста и надо снова актуализировать выбранную раскладку. Кстати, идея для вима: переходить в режим ввода текста, не по нажатию на i, а по выбору конкретного языка ввода. ir и ie, например.

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


Тем не менее, я согласен, что переключение языков разными клавишами удобнее, особенно, если языков больше, чем 2. У меня под досом была такая тема, как включение русского по правому альту, а английского по левому. После этого привыкать ко всяким альт-шифт было очень тяжело.

Где-то выше по ветке вы упомянули, что таких редакторов, как вим больше не делают благодаря работам Раскина. По-моему это называется социальным доказательством.

Neovim?

Самые решительные и радикальные настраивают переключение раскладки на клавишу CapsLock.

Гм… меня когда-то просто приучили к CapsLock, и я не вижу тут ничего радикального :) Это банально удобно. В отличие от


А, между тем, по уму нужно от циклического переключения раскладки отказаться и забить хоткей на один язык и хоткей на другой. Однако тех, кто делает так, можно перечесть по пальцам.

Да, и именно потому, что


  1. Режим клавиатуры всё равно надо помнить, хотя бы краем одной извилины. Собственно наличие одной клавиатуры (а не двух, или даже одной восьмирядной) вынуждает к этому. Набор не в том режиме приводит к неверному результату. Punto Switcher не вспоминать — это костыль, не работающий в сложных случаях (а для программиста не пригодный, считаем, во всех практически важных случаях).


  2. Все эти хоткеи будут значительно тяжелее набираться, чем один кивок левым мизинцем (или, для ниасиливших десятипальцевый набор, как я — левым безымянным). Ограничивающее условие: две постоянные раскладки по кругу. Если иной вариант (например, KDE позволяет строить какие-то по кругу, а какие-то вне круга, или на кругу 3 или больше) — то хоткеи таки настраиваются. Я пока что обошёлся. Но у меня есть второй уровень режимов ввода — выбор между наборами en,ru <-> en,uk <-> en,ru(ruu), переключается в среднем пару раз в день.

Собственно, это всё даёт ответ на более общий вопрос — почему от режимов не уходят совсем. Я бы ещё добавил, что это невозможно в принципе — режимы вождения самолёта, светского приёма и интима в постели различаются естественным образом и радикально. Почему вообще ставят вопрос, что не должно быть режимов, когда этого достичь невозможно?

Режим клавиатуры всё равно надо помнить, хотя бы краем одной извилины.
Совершенно не нужно. Считаем, что переход в английский режим ввода в VIM — это «Caps, i», переход в русский режим ввода «Shift+Caps, i».

В других редакторах = просто «Caps» и «Shift+Caps».

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

Почему вообще ставят вопрос, что не должно быть режимов, когда этого достичь невозможно?
Это вы у Раскина и его последователей спросите — он на это всю жизнь потратил.

А vim уже умеет понимать команду "Shift+Caps, ш"? :)

langmap (для восьмибитных кодировок) или map каждой клавиши отдельно для utf-8.

А нажатие Shift+Caps он поймёт?

Думаю, нет. А надо? Это ведь событие, которое не транслируется в печатаемый символ.
(Скорее он и не услышит такое нажатие. У gvim было бы больше шансов — в иксы поступают все нажатия, это уже на уровне юзерской libxkb отфильтровываются непечатные. Тот, что в терминале, не получит, потому что терминал не передаст это событие через PTY discipline.)
Думаю, нет.

Вот и я думаю, что нет :(. Вы там в предыдущих комментариях подразумевали, что Shift+Caps обработакт операционная система, да?


А надо?

Надо! Это же кратно увеличивает количество возможных комбинаций клавиш!


Это ведь событие, которое не транслируется в печатаемый символ.

В консоли не будет видно, да, но может хотя бы в графической версии. Может в neovim сделают...

Вот и я думаю, что нет :(. Вы там в предыдущих комментариях подразумевали, что Shift+Caps обработакт операционная система, да?

Да. А как иначе? (на реальных системах)


Надо! Это же кратно увеличивает количество возможных комбинаций клавиш!

Мне кажется, их и так больше, чем можно запомнить за разумное время.


А что именно вы предполагаете? Чтобы он понял цепочку из переключения ввода и входа в режим вставки как нечто целое?

А что именно вы предполагаете? Чтобы он понял цепочку из переключения ввода и входа в режим вставки как нечто целое?

Да не обязательно, просто думал вдруг можно Shift+Caps в виме обработать. Я на жто внимание обратил.

Раскин в ветке появился как самый известный человек, описавший проблемы режимов, даже для таких лососей, как автор поста или вы, бегающие и вещающие, какие в виме они офигенные.

Раскин — экстремист (как и Вы, судя по ad hominem лексике). Один пример Canon Cat чего стоит. Поиск документа по содержимому в одной огромной простыне — нормально работает только для ситуации "домохозяйка со списком закупок", для чего-то более сложного он уже не годится. Вот у меня версия документа 1.12, а тут прислали исправленную соседним отделом версию 1.05, надо сравнить и смержить правки — как будем отличать, где какая? А вот пришли требования к софтине, что в них, ещё не знаем, выкладываем в память… ой, и как их искать? (Видимо, потому Canon Cat и остался только в музее.)


То же самое с режимами. Факт, что человек в принципе переключается между режимами — (повторяюсь) режим ведения самолёта, светского раута и интима в постели — мягко говоря, отличаются во всём. Или к собственно компьютерной тематике — какой именно файл редактируете, пока в редакторе. Это ведь тоже режим, как ни удивительно кому-то! (И Раскин как-то об этом не упоминает. Странно, да?) Но есть и тысячи кратковременных микрорежимов — тут вы дали подкурить (сложное, между прочим, действие, роботы ещё не справляются), тут ответили диспетчеру… и существенная разница не в том, что вообще кто-то отвлёкся от основного действия, а в том, насколько это вывело его из прошлого основного режима.


с Дональдом Норманом из Nielsen Norman Group и еще с кучей ученых, изучавших эту область поплотнее

А не надо сразу спорить с ними. Надо спорить с теми, кто потом бесконтрольно, без измерений переносит эти общие результаты на конкретное применение. (А потом можно и на исходные внимательнее посмотреть...)


В случае vim, сам по себе факт режимов банален и ключевым фактором является лишь привычка к их существованию — и их учёт ровно в той же мере, как Вы не начинаете на рауте поднимать закрылки или целовать собеседника, извините за пример :) Кому непривычно — сходит с ума и орёт про режимы, кому привычно — он всего лишь держит в голове текущий режим в том механизме мозга, который для этого предназначен (не хочу вспоминать слово "локус", тем более что этих локусов всегда много и они обычно складываются в многоуровневую структуру). А если отвлёкся (сходил за кофе, etc.) — то всегда есть указание текущего режима — для vim это нижняя строка терминала.


Вот если бы Вы вспомнили классический vi, по виду которого никак нельзя было понять, мы в insert или в vi commands, и который не показывал полунабранную vi command — я бы понял жалобы. Но к vimʼу это слабо применимо, у него всё показывается как надо. Во многих IDE бо́льшая проблема увидеть факт overwrite mode — они это показывают или совсем бледным подчёркиванием чего-то далеко скраю, или вообще не показывают, и сиди гадай.


К слову, ещё про Раскина и квазирежимы. Вот та же идея "поиск работает, пока мы держим кнопку", и как она согласуется с тем, что для облегчения работы некоторых категорий вводят "залипающие" модификаторы вроде Shift? На какую из… мнэээ… disability мы сегодня работаем? ;)

В случае vim, сам по себе факт режимов банален и ключевым фактором является лишь привычка к их существованию — и их учёт ровно в той же мере, как Вы не начинаете на рауте поднимать закрылки или целовать собеседника, извините за пример :)


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

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

Далее, утверждается, что к виму нужно привыкнуть и будет круто. Кто бы сомневался. К Sublime если привыкнуть — будет тоже круто. Только привыкать проще, потому что тут нет разделения на режимы на базовом уровне.

И даже более — никто не мешает людям работать в виме. Но выдавать за киллер-фичу то, чего в любом букваре для дизайнеров рекомендуется избегать — это ломать мозг неофитам. Нефиг.
Но выдавать за киллер-фичу то, чего в любом букваре для дизайнеров рекомендуется избегать — это ломать мозг неофитам. Нефиг.

Киллер фича — это такая штука, из за которой пользователи любят приложение. Которая его "продаёт". Если при этом в букваре для дизайнеров рекомендуется её избегать — она из-за этого не перестаёт быть фичей, из за которой приложение вообще нужно людям.

Киллер фича — это такая штука, из за которой пользователи любят приложение

В вашем понимании пользователи — это только люди, преодолевшие порог вхождения, появившийся из-за этой киллер-фичи. А остальные по-вашему — например те, кто честно хотел или был вынужден работать с вимом, но сдал назад из-за проблем редактора с юзабилити и умеет только поменять текст и написать :wq — это типа уже и не пользователи.

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

Какое высокомерие.
В вашем понимании пользователи — это только люди, преодолевшие порог вхождения, появившийся из-за этой киллер-фичи.

С чего вы это взяли? Пользователи вполне могут пользоваться приложением и его не любить. Вим вот любят за режимы. Не любят — тоже за них :). Но вообще приложение, которое ты не любишь — лучше не использовать, если есть такая возможность.


А остальные по-вашему — например те, кто честно хотел или был вынужден работать с вимом, но сдал назад из-за проблем редактора с юзабилити и умеет только поменять текст и написать :wq — это типа уже и не пользователи.

Всё зависит от того, используют они вим, или нет.


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

Мне кажется, вам имеет смысл определить почему мы пользуетесь вимом и найти редактор, в котором есть это самое "почему", но нет режимов. Это сильно облегчит жизнь.

Мне кажется, вам имеет смысл определить почему мы пользуетесь вимом и найти редактор, в котором есть это самое «почему», но нет режимов. Это сильно облегчит жизнь.


Безусловно. Но все приведенные мной аргументы против неоправданного использования режимов никуда не пропадут, а в пользу них — не прибавится.

Собсно аргумент-то у вас сквозь статью и комменты ровно один — надо привыкнуть к режимам и все станет хорошо. И у меня один — не нужно к ним привыкать и все будет также хорошо.

Разница — в потраченном на привыкание времени.
Но все приведенные мной аргументы против неоправданного использования режимов никуда не пропадут, а в пользу них — не прибавится.

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


Собсно аргумент-то у вас сквозь статью и комменты ровно один — надо привыкнуть к режимам и все станет хорошо.

Нет, основная мысль статьи — "Если вам не нравятся режимы, не нужно искать, что в виме компенсирует их наличие. Ничего такого там нет. Если режимы раздражают, то лучше не пользоваться вимом — ничего не потеряете"

Дискуссия началась с этого до сих пор не подкрепленного аргументами заявления:
image

А теперь как-то съехала в «да статья не о том» и в что таки да проблема у вима такая есть, но только до того, как к ней привыкнешь.

Тут два момента.


Во-первых, какое заявление ничем не подкреплено? Что режимы это нехорошо когда пользователь не понимает, в каком режиме находится в данный момент? Так вроде у Раскина и написано, что модальный интерфейс — зло, потому что пользователь путает режимы.


Или вы про утверждение, что с модальным интерфейсом вима эта проблема отсутствует? Оно подкреплено моим личным опытом и опытом других любителей вима.


И второй момент. Вы только что говорили о том, что сквозит через всю статью, а потом вдруг съехали в "да я про комментарий из ветки, а не про статью". А с тем, что проблема для новичков есть, я об этом тут же и писал.

Или вы про утверждение, что с модальным интерфейсом вима эта проблема отсутствует? Оно подкреплено моим личным опытом и опытом других любителей вима.


Про него. То есть не подтверждено ничем, кроме ваших слов, в отличие от хотя бы статьи на википедии, что вы только что сами в очередной раз подтвердили.
То есть не подтверждено ничем, кроме ваших слов, в отличие от хотя бы статьи на википедии, что вы только что сами в очередной раз подтвердили.

Не только моих слов, а ещё слов большого количества пользователей вима.


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

У меня нет такого мнения, которое вы мне сейчас приписали. Мое мнение ясно выражено по ссылке из самого первого комментария, а затем кучу раз в этой дискуссии.

Мое мнение — это мнение, подтвержденное приведенными мной источниками — наличие режима всегда ухудшает восприятие по сравнению с его отсутствием.

Раскин, люди из википедии — они там не про вим рассуждают, они говорят — режимы — это плохо. Везде, всегда, старайтесь их избегать, когда возможно. И дискутируете вы до сих пор не с моим мнением, а с этими людьми.

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

Тогда можно будет сравнить и обсудить что-то, а пока до сих пор все ваши аргументы — пуки в воздух.
Раскин, люди из википедии — они там не про вим рассуждают, они говорят — режимы — это плохо. Везде, всегда, старайтесь их избегать, когда возможно.

Почтайте Раскина, он, в отличии от вас, обосновывает свою позицию тем, что пользователи путаются в режимах. Если бы пользователи в них не путались, проблем с режимами бы не было.


Опытные пользователи вима не путаются в режимах, следовательно у них проблем с режимами нет.


Вот такой вот простой силлогизм.


Приведите ссылки не на мнения своих друзей, а на исследования, показывающие, что в виме модальность является исключительной и не попадает под рамки приведенных исследований.

Про то, почему модальность в виме не вредна с точки зрения Раскина я уже объяснил, а тут хочу сказать, что вим тут не исключителен. Раскин, например, приводит пример фонарика, который включается и выключается одной кнопкой, я добавлю сюда пример с электической дрелью. Режимы есть, они не мешают, хотя можно было бы обойтись без них. Такие дела.


А вот насчёт исследований, на которые вы ссылаетесь. Мне интересно, это были такие исследования в которых взяли 100 опытных пользователей вима и 100 опытных пользователей notepad++, попросили их сделать примерно одинаковые вещи и замеряли количество ошибок, которые пользователи вима сделали из-за того, что не понимали в каких режимах они находятся? А самим пользователям сказали, что замеряют их производительность в зависимости от марки напитка, который им выдали перед испытанием?
Ну, чтобы цель исследования не влияла на подопытных?

Как проводятся исследования(один из тонны вариантов):
Почитайте букварь, объяснятель.
Ссылка на исследования юзабилити веба.

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


Почитайте букварь, объяснятель.

Так и скажите, про исследования слышал где-то, как они проводились не знаю, объяснить ничего не могу, буду давать ссылки, пока вы не поймёте, что кроме них у меня ничего нет.

Опытные пользователи вима не путаются в режимах, следовательно у них проблем с режимами нет.


Краткое содержание:

Вы: Режимы не плохие, если люди не путаются. Опытные пользователи не путаются
Я: Вот пруф, что все путаются
Вы: Раскин не знает о чем пишет
Я: Вот еще куча пруфов
Вы: Да, сначала нужно привыкнуть. Но потом я и мои друзья не путаемся. Никто из опытных не путается, вообще ваши исследования фуфло
Я: Мои ссылки показывают, что все путаются. Покажите ваши исследования, опровергающие это
Вы: Повторяю, опытные — не путаются, а ваши исследования явно фуфло
Я: ¯\_(ツ)_/¯

Нет, что вы видите себе Д'Артаньяном было понятно практически сразу, но что вы ещё не читаете, что я вам пишу, это я понял только сейчас.


Я: Вот пруф, что все путаются

Пруф, что все путаются в режимах вима? А то там у Раскина написано, что могут и не путаться.


Вы: Раскин не знает о чем пишет

Раскин пишет, что режимы плохи потому, что в них путаются. С вашей стороны неплохо бы цитату, в которой я говорю, что Раскин не знает о чём пишет.


Я: Вот еще куча пруфов

Нет, не куча пруфов, а ссылка на википедию, в которой написано, что неопытные пользователи путаются в режимах вима. С этим я, что интересно, не спорил.


Мои ссылки показывают, что все путаются

В виме? А то последняя ваша ссылка рассказывает о методиках исследования веб интерфейсов.

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

Ниасилили?

Пруф, что все путаются в режимах вима? А то там у Раскина написано, что могут и не путаться.

В виме? А то последняя ваша ссылка рассказывает о методиках исследования веб интерфейсов.

Идея провести исследования на каждый частный случай применения режимов мне нравится. Предлагаю вам с вимом такое исследование провести и поделиться результатами. Пример конкретной методики исследования человеческого взгляда — как трекать, что говорить участникам исследования, размер фокус группы, как обрабатывать собранные результаты с eyetracker-а — там все есть.
В книге приведены исследования веб-интерфейсов, в основном связанных с продажами, потому что за такие исследования платили. За попытку доказать, что в виме уникальный случай применения режимов — в нем результаты прошлых лет не работают, невероятное открытие — за 30 лет существования методики почему-то пока никто не заплатил.

Нет, не куча пруфов, а ссылка на википедию, в которой написано, что неопытные пользователи путаются в режимах вима. С этим я, что интересно, не спорил.

Разуйте глаза, там есть отличный пример ошибки опытного пользователя — катастрофа самолета:

«According to the NTSB, one of the factors contributing to Asiana Airlines Flight 214 crash was „the complexities of the autothrottle and autopilot flight director systems … which increased the likelihood of mode error“.»

Это был неопытный пилот, ага.

Пожалуй не буду нагружать ваш мозг ссылками на источники по когнитивной психологии(Раскин-то не на ровном месте книжку написал). Мне кажется, и так уже нормально.
Тем не менее, безопаснее всегда избегать применения режимов в разработке интерфейсов.
Ниасилили?
Асилили, асилили. Но заодно увидели насколько же у вас узок «локус». Потому что вы одно слово заметили, а соседнее — уже нет:
Тем не менее, безопаснее всегда избегать применения режимов в разработке интерфейсов.
Заметьте — не удобнее, не быстрее, а именно безопаснее.

Вся работа Раскина была нацелена на решение одной проблемы: как-бы-это-так-сделать-эту-хитромудрую-технику-доступной 40-50-60-летним дядям, которые её тупо боятся.

На за прошедшие с тех пор 30 с гаком лет ситуация изменилась: нет уже больше тех людей, которые про компьютер ничего не знают и пугаются режимов. Просто нету. И потому «безопасные» среды — никому не нужны. А нужны удобные. А удобство — в первую очередь зависит от того, какие режимы есть в вашей программе.

Кому-то подход VIM'а с «командным режимом» и режимом ввода текста нравится, кому-то — не нравится, кому-то удобнее так, кому-то — эдак. Но вот среды, которые избегают режимов в принципе — нету. Неудобны они, потому что.

За попытку доказать, что в виме уникальный случай применения режимов — в нем результаты прошлых лет не работают, невероятное открытие — за 30 лет существования методики почему-то пока никто не заплатил.
И это — много о чём говорит, не так ли? Все ваши исследования — предназначены не для создания удобного интерфейса, а для созданияпродаваемого интерфейса. А это — я извиняюсь, далеко не одно и то же.

Разуйте глаза, там есть отличный пример ошибки опытного пользователя — катастрофа самолета:

«According to the NTSB, one of the factors contributing to Asiana Airlines Flight 214 crash was „the complexities of the autothrottle and autopilot flight director systems … which increased the likelihood of mode error“.»
Отличная идея — вырезать ровно самое важное. А давайте-ка посмотрим на оригинальный репорт, а? Какие-такие там пуковки были вырезаны, а?

Contributing to the accident were; (1) the complexities of the autothrottle and autopilot flight director systems that were inadequately described in Boeing’s documentation and Asiana’s pilot training, which increased the likelihood of mode error

Ути-как-интересно-то, а?

Это был неопытный пилот, ага.
Недостаточно тренированный, да. Во всяком случае так комиссия решила. И предписала провести тренировки и обновить документацию — а вот про отказ от разных режимов в рекомендациях нет ни звука.

Интересно, не так ли?
Больше болда! Больше тупости!

Болдом выделили текст, который вы аккуратно убрали из цитаты и который сильно меняет её смысл. Неудивительно, что он вас беспокоит :)

Не, он без болда не умеет.

Ну чтож поделать, если вы без болда некоторые куски текста просто не видите :)

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

Поправка — в самолете никак нельзя обойтись без поднятия закрылок, а тут — можно было, но не стали.
Раскин — экстремист

С языка сняли. По этой же ссылке Раскин выступает против возможности пользовательских настроек, якобы они могут привести к путанице и вообще, после этого система находится в состоянии, не описанном в документации.


Основная мысль этого утверждения заключается в том, что если мы являемся опытными разработчиками интерфейсов и можем в максимальной степени оптимизировать данный интерфейс, то пользовательские настройки могут только ухудшить работу этого интерфейса. Поэтому следует с осторожностью предоставлять пользователю возможности по установке личных настроек. Если пользователь может действительно улучшить работу интерфейса, внеся в него всего лишь несколько полезных изменений, – это значит, что, вероятно, мы плохо сделали свою работу.

Возможно, это правильно по отношению к кабине самолёта — нельзя давать возможности пилоту переместить тумблеры и кнопки так, как это будет ему удобно, ведь тогда в случае чего стюардесса не сможет посадить самолёт по указаниям с земли. Если говорить о софте, то такой запрет может касаться программ управления реакторами, медицинскими роботами — там, где цена ошибки велика, а ошибка необратима. Но нет смысла устанавливать диктат безопасности над удобством в 99.9% программ.
К тому же, пока что я ещё не встречал программ, который бы мне не хотелось настроить под себя. Видимо, все дизайнеры плохо сделали свою работу (конечно же, нет).

Если говорите про режимы, осильте уже теоретический минимум, е-мое, даже ссылку выдал. Смешно читать.

У Раскина я прочёл "режимы — плохо, квазирежимы — туда-сюда". Допустим. Предложите текстовый редактор без режимов. ЕМНИП, при жизни и участии Раскина, а так же в течении нескольких лет после его смерти, у команды программистов Raskin Center for Humane Interfaces эту задачу решить не получилось — проект заглох на стадии альфы. Получившимся недо-Emacs'ом с квазирежимами оказалось неудобно пользоваться. https://en.wikipedia.org/wiki/Archy
Есть ещё ссылки?

Да любой редактор, нигде такого ада как в виме нет. Sublime прекрасный пример редактора который максимально оставляет пользователя в потоке при работе с документом.
Тем, кто хотел узнать, чем хорош vim и так никто не мешал это сделать, и статья не нужна.
Очень странно читать о киллерфичах vi от того, кто сам им активно не пользуется и даже удивляется, как кто-то им может пользоваться.

Я видел людей, которые делают офигенные вещи через vi/vim, через notepad++, через встроенный редактор в FAR. У каждого свои «механически задроченные комбинации», за которыми посторонний не всегда успевает уследить глазом. Но они стали такими не сразу, а после того, как человек близко познакомился с функционалом.

То есть вопрос удобства не всегда должен рассматриваться как «мгновенное улучшение».
Переходить с привычного инструмента на совершенно новый ради одной или двух-трех киллерфич — не всегда работает.

В большинстве случаев гораздо проще найти аналог такой фичи в инструментах, которые ты уже используешь — о чем и идут постоянные холиворы.
Очень странно читать о киллерфичах vi от того, кто сам им активно не пользуется и даже удивляется, как кто-то им может пользоваться.

Вы, совершенно случайно, не про меня ли? Я использую вим на постоянной основе и знаю о чём говорю, если что.

Ну, то ради чего лично я пытался использовать VIM-плагин для IDE — навигация по коду не используя мышь и клавишы стрелок. ИМХО, вот этим предложением можно было заменить большую часть статьи.
Разрешите полюбопытствовать: чем было вызвано желание навигировать по коду, не используя мышь и клавиши стрелок?

Ну вот лично мне в какой-то момент мышка стала тупо мешаться — лишний контроллер, на который иногда приходится отвлекаться… в итоге перешел на Emacs (до этого программировал в VS, Eclipse, QT Creator) и теперь бОльшую часть времени работы за компьютером я вообще не задумываюсь над тем, что и как делать — все делается при помощи хоткеев, которые пальцы сами помнят) И сейчас единственное, чего не хватает в OS для полного счастья — это интеграции своего emacs-конфига на уровне OS, чтобы всякие браузеры и мессенджеры с ними умели работать)

В emacs разве ещё нет встроенного браузера и мессенджера? :-)

Таки все есть, но качество их очень не очень :-)

Чисто вопрос удобства. Работаю на МакПро, блок стрелок на нём ущербный, каждая ситуация, когда надо подвинуть курсор на несколько символов вправо/влево/вверх/вниз вызывает боль, т.к. нужно сместить правую руку на эти маленькие стрелки, а потом вернуть обратно в правильную позицию. В принципе Vim-плагин решил бы эту проблему, но лень и нежелание переучиваться в итоге победили.
Впервые за долгое время мне стало интересно, за что мой комментарий получил минусы.
Попросили описать личный опыт, почему мне хотелось не пользоваться мышью(тачпадом)/стрелками, описал, получил минусы, причём даже в карму судя по всему) Причём, что характерно, никаких гневных комментариев разъясняющих в чём я не прав и где задел чьи-то чувста, просто тупо минусы.

Скорее всего это яблоко-фаны самовыражаются, Вы ведь осмелились использовать в одном предложении слова "МакПро" и "ущербный".

Дело в том что объяснять это действительно тяжело. В первую очередь из-за того, что сторонние наблюдатели считают режим вставки основным, вимеры считают таковы командный режим (он не зря здесь называется нормальным).


Вот какие фокусы доступны в нормальном режиме:


dt. — удалить все до символа точки
d10j — удалить 10 строчек вниз
50a#ESC — вставить 50 симоволов #
G — перейти в конце файла
dG — удалить все до конца файла.
5J — объеденить пять строк в одну, разделив пробелом


В этих дейтвия можно лекго увидеть некую систему:


  • Каждое действие можно повторить N раз: dj — удалит десять строчек вниз, d10j удалит 10 строк.
  • Действие можно связать с навигацией: dk — удалит строчку вверх, dG все до конца файла.
  • Действие можно произвести над выделеным блоком: выделение бывает произвольное, строчное и что особо удобно блочное

Действий довольно много:


  • d — удаляет
  • с — удаляет и переходит в режим вставки
  • r — меняет символ без перехода в режим вставки (звучит бредом, но в некоторых случаях очень удобно)
  • p — вставляет из буфера обмена
  • y — копирует в буфер
  • u/U — меняет регистр вниз/вверх
    и ещё стопицот.

Навигации ещё больше:


  • hjkl — аналог стрелочек
  • t — до симовола
  • g — до строчки номер N

    w/e — по словам

Отлично. Просто отлично. В двух словах вы объяснили, почему vim так притягивает к себе программистов. Ведь программистам редко приходится что-то писать — обычно мы редактируем уже существующий код.


Примерно в том же стиле написан и культовый комментарий на тему vim https://stackoverflow.com/a/1220118/661236 Если вы его ещё не читали, то стоит прочитать.

Если вы его ещё не читали, то стоит прочитать.

Спасибо.
И комментарий к ответу "… вы, вероятно, написали его в vim примерно за 10 нажатий клавиш" :)
У меня есть язык программирование в среде для написания программ, чтобы я мог программировать, пока я программирую.
Отличная статья, и комменты нескучные. Раньше я думал, что vim — это крутая магическая штука, к которой лучшие умы планеты пишут плагины, затыкающие глубоко за пояс любую IDE и до которой просто надо дорасти (а то честно пройдя какой-то интерактивный туториал я так и не понял зачем мне все эти команды, когда я вбитые за 20 лет в «подкорку» нормальные комбинации с Ctrl нажимаю гораздо быстрее, чем буду всё это набирать). Теперь понял, что он мне нужен как жирафу водительские права. Значит для меня будет лучше посвятить время изучению Emacs. Или может даже углублённому изучению того же Sublime (он вроде тоже достаточно «hackable»). Хотя, чуть-чуть «насобачиться» в vim всё-равно наверно стоит хотябы потому, что только он есть практически везде.

Ситуация с плагинами довольно нелепая. На этапе создания vimscript никто не подполагал, что на нем будут пытаться выразить чего-нибудь сложнее макросов. На деле вышло как вышло. Есть прослойка фанбоев, который рассказываютс про крутость эти плагинов, но их реальная крутость в одном: нативность для vim.


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

Большие по объёму кода дополнения часто пишут на Python, lua и ruby; в основном первое.

Ну это появилось в семерке, которой не так много лет ещё, поэтому реальных, хороших плагинов пока мало. Активно эту идею продвигает nvim: вот там больше возможностей для построения IDE на +nvim.

Vim-7.0 появился в 2004 (точнее, тогда появился первый commit в mercurial репозитории, а он содержит исходные коды начиная с 7.0, но не более ранние). Первый commit, позволяющий запуск powerline (которому нужен +python) — 7.0.112 — октябрь 2006.


А у Neovim есть API на основе msgpack для взаимодействия с внешними процессами, что позволяет писать на любом языке.

Хм. Как вчера было :)

Значит для меня будет лучше посвятить время изучению Emacs

Хаха, тоже так когда-то думал. Но руки сделали свой выбор сами. Главная киллер-фича vim для меня — руки меньше болят после целого дня работы с текстом (в сравнении с "традиционными" редакторами, IDE и тем же Emacs). Это эффект именно модального режима, благодаря которому все эти Ctrl, Alt, Shift приходится жать на порядок реже. Как итог, существенно меньше напрягаются кисти.

Простите, а о каком ЯП идет речь, что требует так много печатать?

Русский язык, к примеру.


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

Разумеется, но так, чтобы после целого дня работы с кодом руки болели — не представляю…
Я могу вспомнить только PHP и Perl где нужно жмакать неудобные @#$% постоянно, но vim вроде проблемы не решает даже в этом случае. Хотя может пэхапэшникам лучше живется на Dvorak-раскладках

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


Ну и, опять же, физиология у всех разная. Кто-то более предрасположен к RSI, кто-то меньше. Возраст тоже влияет: чем старше пациент, тем больше шансов поиметь проблем со связками.

Хаха, тоже так когда-то думал. Но руки сделали свой выбор сами.
А evil-mode не пробовали?

Знаю про него, но так руки и не дошли. Привык уже к классическому vim.

Я попробовал — серьёзно размышляю отказаться от вима в пользу емакса.

Лучше тогда spacemacs использовать

Spacemacs – это emacs с набором плагинов, чтобы быть максимально удобным для любителей vim-подобного редактирования. Такой «Зверь-пак» можно сказать.

Ну там не только пак, справедливости ради. У них там своя атмосфера со "слоями" и мегаконфигом для всего сразу. Кроме того они заботятся чтоб все сторонние плагины, которые они к себе берут, не дрались с evil модом (что сплошь и рядом в ванильном емакс). Поэтому его так вимеры и любят.

Главная киллер-фича vim для меня — руки меньше болят после целого дня работы с текстом

У меня одно время тоже начали побаливать руки, когда много на встроенной клаве ноута фигачил, держа их на весу. Подключил классическую внешнюю клаву, кинул перед ней силиконовую подушку, на которой руки лежат практически неотрывно (и ни малейших проблем ни с какими комбинациями не испытывают) и всё прошло. Но возможно мне просто повезло с длинной пальцев (я бы с удовольствием добавил между цифрами и F-клавишами ещё один программируемый ряд полноразмерных кнопок и мне было бы не менее комфортно).
Это индивидуальная особенность. Я более десяти лет работаю в emacs, каждый день, с руками всё хорошо.

Естественно, как любой нормальный емаксер, я control перемапил на caps lock, ну и клава должна быть не сильно плохая (сейчас у меня макбук, на декстопе когда сидел — была майкрософт натурал, потом майкрософт 4к).
Саблайм гавно, емакс на несколько порядков круче.
Если есть возможность я бы сейчас смотрел на Atom/Visual Studio Code, мне кажется это очень перспективные вещи, возможно, лет через 20 даже emacs начнут догонять.

Т.е. vim притягивает тем, что можно писать мэджик команды для редактирования текста и ощущать себя грёбаным Гэндальфом?

Ну, в целом да. Но это правда удобно.

Вопрос, а чем так проблематично установить IDE и скачать vim плагин для этой IDE и радоваться жизни?

Совсем не проблематично. Но вопрос — зачем ставить vim плагин и портить им замечательную IDE останется открытым :)

А зачем ставить Vim? Ради режимов и быстрого редактирования текста. А зачем ставить Vim плагин в IDE? Ради режимов и быстрого редактирования текста.
Ваш Кэп.
P.S. Все лучше чем раскладка Visual Studio без Rider.
А зачем ставить Vim плагин в IDE? Ради режимов и быстрого редактирования текста.

Совершенно согласен. Именно это я и хотел сказать :)

Пробовал плагины, но все они далеки от работы с кодом в vim.
Скорее вопрос в привычки и расширяемости Vim в плане редактирования, управления буферами, переходами по файлам и т.д. и т.п.
Всю IDE перестроить не получится.

Тогда в vim не нужно будет добавлять плагинов, в которых не разбираетесь. А так любимая IDE с плюшками + удобный инструмент работы с текстом.