Комментарии 622
Не обязательно использовать сам vim. Почти в каждой популярной IDE есть vim плагин, который покрывает существенную долю функций vim. Кроме плагинов разумеется, но это скорее плюс :)
Автору так и нужно было писать: Через SSH лучше Vima нет. Это его киллер фича.
Нет, работа через SSH киллер фичей вима не является. Многие пользуются вимом, хотя по SSH ходят дай бог раза 2 в неделю. Киллер фича вима именно режимы.
Многие пользуются вимом, хотя по 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, когда возникает нужда.
На сервере не нужны иксы чтобы запустить gedit по ssh. Иксов хватит и на клиентской машине.
Но такой путь все равно костылевостью отдает (по крайней мере для текстового редактора) :-)
Автору так и нужно было писать: Через SSH лучше Vima нет.
Можно в emacs через Tramp mode подключаться к удаленному терминалу и работать через него как на локальной машине ;-)
Теперь есть micro, по SSH он работает как в нативном терминале. И даже иксовый буфер обмена пробрасывается. Он прекрасен.
Использую mcedit (редактор midnight commander), удобно как по ssh так и локально. Особых недостатков перед графическими IDE не вижу. Vi только там где нет возможности запустить вышеуказанный, либо где настолько плохой коннект что он лагает перерисовкой экрана.
Как в мседит скопировать в буфер обмена выделенный блок?
То есть, для вас нормально в одном месте для копирования текста нажимать Ctrl-C/V, а в другом месте F3/F5? И постоянно об этом помнить и следить за тем где вы выполняете шорткат?
Наоборот, когда шорткаты отличаются настолько сильно это вызывает меньше когнитивного диссонанса, чем когда отличие минимально — но таки есть…
Ну люди же работаю как-то на Mac'е где нужно помнить в какой программе это Ctrl-C/V, а в какой — Command-C/V и ничего.
Что за бинарное мышление? Наличие неудобства не означает, что его невозможно терпеть. А а возможность человека привыкать к неудобствам не означает, что эти неудобства не стоит устранять.
А ещё есть третий вариант Ctrl-Ins, Shift-Ins, который причём есть в двух вариантах (кнопки одни и те же, логика работы чуть разная). Это не проблема редактора в любом случае, ну а для меня это не кажется проблемой вообще — всё на автомате.
На плюсах пишу в clion, впрочем.
Но при этом нужно сделать одно отступление. Он хорош если вы действительно много работаете с различного рода текстом. Код- лишь малая часть этого. И если с кодом для большинства распространенных языков есть варианты, то со всем остальным- дело может быть совсем плохо. Моя основная работа- инженер-связист. У каждого производителя железа свои закидоны. Например для сетевых элементов Ericsson скрипты нужно писать на языке, у которого даже названия нет. Во всяком случая я его в документации не нашел. И если языка нет, то и подсветки синтаксиса не существует. Как собственно и IDE под него. Но состряпать ее для Vim- совсем не проблема. Или вам нужно на оборудовании Huawei поменять один параметр на базовой станции. Но на каждой. У системы можно получить их список, но каждую строку нужно будет вручную переколбасить. Что-то оставить, что-то переместить в другое место, что-то убрать. И самое страшное в том, что эту операцию нужно будет сделать для каждой из тысячи строк. Vim поддерживает регулярки. Не несчастные вайлдкарды, а по полной программе. Одна команда прямо в редакторе и все готово. Конечно это можно сделать при помощи того-же Python и когда парсинг очень сложный, то я так и делаю, но очень часто хватает просто Vim.
PS: Я не являюсь фанатиком Vim и с удовольствием пользуюсь IDE. Но как по мне IDE + Vim звучит куда лучше, чем IDE или Vim.
Всё, что вы описали умеет любой современный редактор. И подсветка синтаксиса за 10 минут и рефакторинг по регуляркам и прочие радости жизни.
Э. Perl, например. Или даже sed. То что вы описали, вполне подоходит под описание автоматизируемой раз и навсегда задачи.
Что мы узнали из статьи? Что клавишу E нажать быстрее, чем Ctrl+Right. Ок.
Я хотел сказать, что это может быть и не сильно быстрее, но, для многих людей, сильно удобнее.
но, для многих людей, сильно удобнееДополню фразу примером, чтобы было понятнее. Вспомните печатную машинку. Когда человек умеет быстро печатать слепым десятипальцевым методом vim для него гораздо удобнее. Все эти сочетания клавиш не просто медленнее, они мешают.
Там нет такого количества манипуляций с текстом
В Vim есть все, что связано с любыми манипуляциями с текстом. В нем уже реализован любой бред, который вам придет в голову. Даже если вы придумаете это под тяжелыми наркотиками или попросите что-то придумать больного на всю голову психа даже не сомневайтесь. Vim будет на вашей стороне.
Хочу из списка слов разделённых пробелами получить все варианты их перестановок, каждый на отдельной строке.
Хочу по нескольким введённым словам получить осмысленное предложение-палиндром, начинающееся с них.
Хочу по введённой строке текста получить список словосочетаний, которые рифмуются с окончанием строки.
Я не настолько быстро думаю, чтобы десятипальцевый метод что-то ускорил. Серьёзно. Набор текста в программировании — это вообще мизер.
Опечатки… вот где особенно помогает слепой метод печати, так как они исправляются сразу, а не в тот момент когда оторвал взгляд от клавиатуры...
Много вы знаете людей, печатающих не слепым методом, но тупящих в клавиатуру не отрываясь?
Обычно на клавиатуру смотрят пока печатают слово. А опечатки видны уже после того, как посмотришь, что напечатал.
Достаточно, что бы их останавливать когда они пытаются в другой раскладке сообщение печатать...
Меня удивляют такие люди. Почему-то у меня нет "борьбы с клавиатурой" и алгоритм пользования мышью я не обдумываю(ну, знаете, вот этот типичный пример про "снять руку с клавиатуры, найти мышь взглядом, перевести руку на мышь, найти курсор взглядом, перевести курсор, кликнуть, снять руку с мыши, положить руку на клавиатуру").
Почему режимы суть гавно плюс-минус нормально написано у Раскина в его Интерфейсе.
А киллер-фича емакса (и такая фича очень мало у кого есть, что-то подобное есть в Atom/Visual Studio Code, но у них это очень примитивно) — это elisp, то есть возможность работать с кодом не через клавиши, а через команды (как командная строка). У vim-а его язык расширения очень примитивен, поэтому такой метод работы в нём неудобен.
Вообще, я уже давно не пытаюсь никого ни в чем убеждать в подобных спорах. Начинал с K52 для RSX-11M, а сейчас давно уже нахожусь в комфортном для себя балансе между vim и ide, а эту дисуссию посматриваю скорее из ностальгии. Десятки лет проходят, а темы холиваров не меняются :)
Почему режимы суть гавно плюс-минус нормально написано у Раскина в его Интерфейсе.
У Раскина написано, что плохие режимы это такие режимы, при которых пользователь не может чётко понимать в каком режиме он находится на данный момент. К виму это не относится, там забыть в каком режиме ты сейчас находишься достаточно трудно.
Пример плохого переключения режимов — циклическое переключение языков.
Это, мягко говоря, неправда. В виме регулярно люди путаются, в каком именно режиме они находятся. Шутки про тройной долбёж по кнопке esc не на пустом месте, да и внезапно появившийся символ i в странном месте в пулл-реквесте тоже.
Это, мягко говоря, неправда. В виме регулярно люди путаются, в каком именно режиме они находятся.
Поначалу да, путаются.
Шутки про тройной долбёж по кнопке esc не на пустом месте
Во-первых, esc надо нажать не три раза, а два :). А во-вторых это нужно для того, чтобы гарантировано попасть в нормальный режим, в каком бы режиме ты не находился сейчас. Паник кнопка для новичков, которые могут не знать, в каком режиме находятся и для тех, кто отошёл от компа и не помнит что он делал.
О проблемах с символом i в пулл реквесте я не слышал.
Я например когда веду машину, постоянно забываю на какой скорости еду. Особенно путаю вторую и четвертую, ибо по положению ручки понять какая включена почти невозможно.
Так же не понимаю, как можно считать редактор с режимами удобным, если постоянно приходится помнить, в каком режиме находишься. Плюс стандартные действия с текстом во всей системе осуществляются одним образом, а в vi другим. Как это может быть удобно — непонятно.
Как это может быть удобно — непонятно.Тут вопрос не «как», а «кому». Тому, кто не путает вторую и четвёртые передачи, однако.
А профессионалов (причём не только у автогонщиков, но и у дальнобоев, коих несравнимо больше) этих передач может быть и два десятка, представляете?
Это не в упрёк вам — просто люди разные, кто-то в четырёх-пяти передачах путается, а кто-то и в 4-5 режимах VIM'а чувствует себя как «рыба в воде».
Если привыкаешь писать код двумя руками, прерываться на то, чтобы, положить руку на мышь, найти курсор, навести его куда-то, нажать комбинацию кнопок на мыши и клавиатуре, вернуть руку на клавиатуру кажется не самой лучшей тратой времени.
Кроме того, использование только клавиатуры, а особенно если не приходится использовать сочетания, дает возможность по максимуму почти интуитивно использовать бытрые последовательности команд («мышечную память»). То есть я заранее знаю, какой набор действий надо выполнить, и могу это сделать очень быстро. С мышью такое невозможно — каждое перемещение курсора требует сосредоточенности и постоянного контроля, т.к. можно промахнуться.
Условно говоря, мышь — это аналоговый интерсфейс, постоянно требующий коррекции на основе телеметрии с экрана, а клаватура — цифровой, достаточно выбрать клавишу.
Вы не поверите В СКОЛЬКИХ местах IDE глотают нажатия клавиш, если кто-то набирает быстро и не глядя на экран. В VIM вы можете быть уверены, что набрав 100 команд не глядя на экран вы увидите то, на что рассчитывали. IDE (за исключением текстовых) в одном случае из 100 будет что-то глотать. Вроде бы немного, но это значит что ваши действия нужно контролировать после каждой команды. Иначе рано или поздно вы пропустите момент, когда какое-то окно не успело открыться (или закрыться), после чего уже все последующие команды пойдут «мимо контекста».
В том-то и дело, что на самом деле режимов у IDE в 100 раз больше, чем у VIM'а (окно редактирования свойств класса — один режим, окно открытия файла — другой, окно заливки в VCS — третий и так далее… сотни их… если не тысячи...).
Так что разница принципиальна: в IDE вы работаете с компьютером в режиме диалога, в VIM это «я сказал, компьютер сделал».
Никогда об этом не задумывался в таком ключе, хотя и сталкивался не раз. Спасибо за чёткую формулировку.
То есть когда я работал в каким-нибудь седом Turbo Pascal'е, то для меня не предоставляло проблемы нажать «не глядя» что-нибудь типа "<Ctrl+F7> x <Ctrl+F7> y <Ctrl+F8> <Ctrl+F9>" — всё это «не глядя», после чего я мог повернуться и что-то написать на листочке, пока комп всё это будет проделывать (у нас жётских дисков в компьютерном классе не было, а при работе с дискетки одно окно могло окрываться секунд 5). И это не вызывало ощущения «ужасающих тормозов»: думаю-то я всё равно не так быстро, так что после того, как я подал пару десятков команд могу и подумать над чем-нибудь ещё.
А вот в Clion гораздо меньшие тормоза — раздражают ужасно. Потому что я не могу «забросить» кучку команд и глотнуть кофе. Я должен за этим монстром приcматривать… и подавать команды когда он будет готов. Возникает вопрос: кто для кого работает — я для компьютера или компьютер для меня?
На машинке за $10'000 примерно, впрочем, тормозов почти нет и можно работать почти как в Turbo Pascal'е… потому что CLion успевает отреагировать на всё между двумя нажатиями клавиш… но есть ощущение какой-то неадкватности: неужели же вся эта моща нужна только, чтобы компенсировать тот факт, что мы используем GUI?
Обидно как-то…
Нет, тут разница скорее между однопоточностью и многопоточностью. То, что в однопоточной программе получается автоматически, в многопоточной (гуй — это почти всегда несколько потоков) требует намеренной реализации.
А вот то, что это свойство в GUI реализовано намерено — тут вы правы на 100%. При работе с многими программами в этом даже есть какой-то смысл — действительно, не должна же моя среда тормозить из-за того, что в каком-то там браузере в фоне дизайнер навороты, грузящие одно из ядер на 100%, сделал… но почему эта беда должна наблюдаться в рамках одного процесса — мне решительно непонятно.
Потому что гуй к ним писали по тем же принципам что и сайты, там нет основного потока исполнения для формы (как было к примеру у delphi для для winforms) а если ещё и начинают использовать асинхронный js, то это же и выходит по сути страничка браузера. Меня это застало на vs от ms(большой не code) когда ты жмёшь быстро ctrl+f и текст, и первые буквы успевают попасть в файл с кодом т.к. окошко ещё не успело всплыть.
p.s. vim-ом не пользуясь, очень редко нужно писать быстро, и в основном это касается запросов к БД где ключевой ускоритель — подстановка названий полей.
Для администрирования, когда нужно быстро подправить какую-то опцию, учитывая возможности vi/vim в навигации по тексту, это особенно прекрасно в случае медленного коннекта. Например с мобильного телефона за пределами обитаемых мест.
Поклонники vim'а запоминили только, похоже, как выглядели IDE лет 20 назад.
Оно там тоже все есть)))
Разница между Vim и IDE…
Vim изначально рассчитан на горячие клавиши и построение команд, по этому с ходу тяжело научится этим пользоваться…
IDE позволяет постепенно уходить от мышки, меню к неудобным горячим клавишам, которые в команды не строятся.
В виме ведется работа с буферами, не важно что в них отображается, главное что они ведут себя одинаково.
В IDE каждое окно имеет свой интерфейс взаимодействия.
В виме я могу расположить информацию как угодно за счет буферов и вкладок(не только файлы) и перемещатся одними и теми же хоткеями.
В IDE я толком не могу разделить даже файлы в разном виде(горизонтально, вертикально, по 3, по 4, спрятать скрыть) конфигурации, не говоря уже о приятном интуитивном перемещении по ним.
Я не отрицаю, что в IDE можно работать без мыши. Но это не настолько удобно. И шорткаты в разных IDE разные, особенно Visual Studio от других отличается.
Не стоит тратить время. Они просто не понимают о чем Вы. Им нравится "не пробовал но осуждаю" и проходить vimtutor не будут.
Я им так скажу: "10 пальцевый слепой набор. VIM — руки всегда на месте, IDE — как минимум руки скачут к стрелочным кнопкам и/или мыше."
P.S. С условием что Esc на Caps Lock.
Ещё раз — зачем он нужен программисту, ваш десятипальцевый слепой набор? Ну добились вы 500 знаков в минуту, ок. И что? Я за это же время нажал 5 клавиш, а кода у меня получилось больше. В программировании набивка кода — это вообще не главное.
Ещё раз — зачем он нужен программисту, ваш десятипальцевый слепой набор?
Для того, чтобы не переводить глаза на клавиатуру, когда он работает с кодом и для того, чтобы спокойно переписываться с заказчиком в мессенджерах.
По-вашему, существует два вида печати — ваш метод и "уткнулся в клавиатуру, ничего не вижу, страдаю, набираю в час по чайной ложке"?
И зачем программисту вообще переписываться с заказчиком, это работа аналитика и менеджера.
По-вашему, существует два вида печати — ваш метод и "уткнулся в клавиатуру, ничего не вижу, страдаю, набираю в час по чайной ложке"?
Совершенно непонятно, откуда вы сделали такой вывод. Я был бы благодарен за цитату. Мы тут обсуждаем полезность для программиста слепого набора на клавиатуре. Слепой набор это когда программист не смотрит на клавиатуру, когда печатает. Когда программист смотрит на клавиатуру — он немножко теряет контекст. Чем меньше он отвлекается, тем проще ему работать.
И зачем программисту вообще переписываться с заказчиком, это работа аналитика и менеджера.
Значит будет переписываться с аналитиком и менеджером, суть от этого меняется не сильно.
Ну из вашего же комментария следует, что все, кто не владеет десятипальцевым слепым методом, страдают и не могут даже переписку вести нормально.
Кто вам сказал, что теряется контекст при взгляде на клавиатуру? Это ваши домыслы. Программист может смотреть вообще в сторону, не на код, а в окно и не терять контекст. Если для вас контекст — это три строчки кода, у меня плохие новости.
Ну из вашего же комментария следует, что все, кто не владеет десятипальцевым слепым методом, страдают и не могут даже переписку вести нормально.
Из моего комментария следует, что всем, кто владеет десятипальцевым слепым методом переписку вести удобнее, чем тем, кто не владеет.
Кто вам сказал, что теряется контекст при взгляде на клавиатуру? Это ваши домыслы.
Посмотрел на клавиатуру — потерял фокус на месте, где курсор. Когда возвращаешь взгляд надо искать курсор. Когда привык это практически не заметно, но на самом деле это и есть постоянное переключение контекста. Удобно, когда его не происходит.
Домыслы, субъективизм, проецирование личного опыта на других.
Всё, я в этой теме больше не отвечаю, сколько раз зарекался вступать в холивары с фаниатиками.
Домыслы, субъективизм, проецирование личного опыта на других.
Я хотел бы отметить, что это не только мои личные домыслы, а опыт большого количества людей. Кстати, вы умеете печатать вслепую? У вас есть такой опыт?
Всё, я в этой теме больше не отвечаю, сколько раз зарекался вступать в холивары с фаниатиками.
Вы приписали мне слова, которых я не говорил, а потом обозвали фанатиком. Неудивительно, что вам сложно общаться с людьми.
Из моего комментария следует, что всем, кто владеет десятипальцевым слепым методом переписку вести удобнее, чем тем, кто не владеет.
Нет, из него следует что всем, кто владеет слепым методом переписку вести удобнее, чем тем, кто не владеет.
Превосходство десятипальцевого метода над остальными вы не доказали.
Да и, честно говоря, потеря контекста тоже у вас вышла какая-то натянутая. Программист же не просто так набирает что-то, а ожидает после набора получить вполне конкретный результат. И в этот ожидаемый результат входит в том числе ожидаемое положение курсора.
Нет, из него следует что всем, кто владеет слепым методом переписку вести удобнее, чем тем, кто не владеет.
А я что написал?
Да и, честно говоря, потеря контекста тоже у вас вышла какая-то натянутая.
Вы умеете печатать не глядя на клавиатуру?
Вы умеете печатать не глядя на клавиатуру?
Я владею обоими методами слепой печати и не наблюдаю ни разницы в скорости набора, ни потерь контекста. При желании могу писать комментарии смотря в потолок, но тут уже скорость страдает.
Я владею обоими методами слепой печати и не наблюдаю ни разницы в скорости набора, ни потерь контекста.
Меня вот, пока не научился не глядя на клавиатуру печатать, перенос фокуса с экрана на клавиатуру и обратно очень раздражал. И такие ощущения у достаточно большого количества народу. Надо опрос на хабре устроить :)
Меня вот, пока не научился не глядя на клавиатуру печатать, перенос фокуса с экрана на клавиатуру и обратно очень раздражал.
Меня тоже, и именно поэтому я сначала выучился печатать не глядя на экран. Это позволило увеличить скорость печати, в результате чего руки стали постепенно "запоминать" клавиатуру. А там уже получилось перестать на нее смотреть :-)
Но одновременно с этим меня перестал раздражать перевод фокуса между экраном и клавиатурой.
Я без десятипальцевого не смотрю на клавиатуру и пишу почти без ошибок — ЧЯДНТ?
Вы всё делаете так. А с моей стороны — проблема с терминологией. Я говорил про способность печатать не глядя на клавиатуру. Каким методом — неважно. То есть, по моему мнению, владеть именно десятипальцевым методом не обязательно.
Программирование состоит из манипуляций с кодом и обдумывании.
Не набивка — а огромное число перемещений, небольших или больших правок. Но вовсе не из: думал 7 часов не прикасаясь к клавиатуре, потом за 1 час все набил
А в виме нужно просто нажать e
Объясните мне, как не_пользователю_vim, как тогда в этом случае там набирать букву «е»? Или подразумевается, что для того, чтобы переместить курсор к концу слова, надо сначала перейти из режима набора текста в какой-нибудь режим навигации, а уже потом нажать е?
Именно так: из режима «вставки» в «нормальный» режим. Хотя у меня для таких мелких передвижений в режиме набора используются сочетания вроде <C-b>/<C-f> (назад/вперёд на символ), ,b/,w (назад/вперёд на слово), ,B/,W (назад/вперёд на СЛОВО (ограниченное пробелами: первый вариант переносит на f в (foo|, второй — на ()). (Я имею ввиду, не выходя из режима вставки.)
И стрелки с <C- вроде тоже поддерживаются, но до них далеко тянуться и с высокой вероятностью в терминале что‐то из стрелок с модификаторами работать не будет.
Делать под себя набор клавиатурных макросов может быть и удобно, но лишь до тех пор, пока не окажешься на другом компьютере, где их нет.
vim это тот случай когда надо попробовать, также как надо обязательно попробовать хорошую IDE. Составить впечатление по постам в интернетах не получится.
Трагизм ситуации в том, что на первом этапе работать будет очень неудобно и всё будет делаться очень медленно. В случае с хорошей IDE, это обычно не так.
vimtutor в помощь
Ну не знаю. В IDE тоже свой ад связанный с обилием менюшек, которые по началу оказываются совсем не там где ты их ожидаешь.
Как по мне, IDE предоставляют две незаменимые фичи, отсутствие которых куда сильнее бьёт по продуктивности, чем +5% к скорости правки текста. Это навигация по коду а-ля «перейти к определению метода/класса» и рефакторинг.
«перейти к определению метода/класса»
Это есть и в vim, хотя да в IDE сделано лучше из-за того, что IDE держит в код в памяти в разных представлениях.
рефакторинг.
Ну да, тут явно лучше. Но опять таки какой смысл сравнивать ежа с ужом. vim это про редактирование кода, отсюда и популярность vim плагинов в IDE
В вим этого нет. Найти метод по названию можно, но если их десяток в разных классах? IDE анализирует код и знает, какого класса текущий объект. Для вим такого плагина не видел.
В вим этого нет. Найти метод по названию можно, но если их десяток в разных классах?
Нужен плагин для соответствующего языка. Например для Python и Go все это есть: подсказка будет учитывать экземпляром какого класса является эта переменная. По моим ощущениям качество подсказки для Python такое же как в Pycharm.
А вот автоформатирование Python, на мой взгляд в Vim слабее чем в Pycharm или Spacemacs.
А что, мелкий рефакторинг типа "переименовать метод" уже перестал быть редактированием кода?
Банальный 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'е, а вы развели демагогию =(
Ваши ответы: «Он сам ставит закрывающую» / «зачем людям IDE?»
Как я и habrahabr.ru/post/339908/#comment_10468622 уже объяснили: «сам ставит» — вообще не выход из ситуации
- vim из коробки не ставит закрывающих скобок.
- можно повесить любое действие на любое сочетание клавиш в любом режиме. Например, эту задачу можно решить так: если в режиме ввода нажать два раза
\, то вставить пару скобок, перейти в командный режим, вместиться на символ влево, вернуться в режим ввода. Комментарий я писал дольше, чем команду.
:inoremap \\ ()^[i
Для такого иногда можно посоветовать всё же дополнение: с таким простым автозакрытием скобок возникают проблемы с undo (вставка скобок создаёт новый узел в дереве undo) и точкой. Лично мне первое не мешает, но вот второе сильно раздражает, хотя дополнение я так и не поставил: они имеют свойство ломаться с обновлениями Vim и не уверен, что сейчас вообще есть с работающей точкой (т.к. следил за vim-dev и иногда ловил сообщения «этот трюк сломался», но соответствующие ветки потом не особо читал).
Сам использую ,s (круглые скобки) / ,h ([]) / ,f ({}) / ,u (<>).
PS: Не нужно говорить про «любое сочетание клавиш» и «в любом режиме»: я знаю очень много контрпримеров, вот два самых простых: на первое достаточно просто <C-S-x>, на второе: вы знаете, что у YouCompleteMe есть «принципиально нерешаемая» проблема с неработающим <C-u>?
Для такого иногда можно посоветовать всё же дополнение
Да, дополнение лучше велосипедов. Команда только для демонстрации лёгкой расширяемости vim, это ни в коем случае не эталонное решение.
PS: Не нужно говорить
Спасибо.
Errata: "большинство сочетаний клавиш в различных режимах" =)
вы знаете, что у YouCompleteMe
Нет, из дополнений у меня только slime.
ага, в Vim также, удобно
Я могу написать Кавычку перед строкой:
string" и вторая не появится, а в остальных случаях появится. Или посередите строки я хочу сделать разрыв и вставить туда переменную, количество кавычек вставленных IDE я иногда предсказать не могу.
Поэтому мне кроме контекста надо всегда помнить, в каких случаях кавычка ставится, а в каких нет, и тратить время на борьбу с IDE. Мне лень, поэтому я отключаю эту шелуху. Скорость набора ну уж точно не падает.
Это страшно бесит, когда ты не пишешь новый код, а редактируешь существующий. Тебе надо поставить открывающую тут, а закрывающую там, а вместо этого ты занимаешься удалением невпопад добавленных закрывающих скобочек, кавычек и прочей ерунды. "Особо умные" редакторы ещё и удаляют эти символы парами, что особенно доставляет.
Нее, "особо умные" редакторы самостоятельно находят пару для скобок и кавычек и ставят их в случайном месте :-)
Неужели экономия одного нажатия рядом стоящей клавиши стоит введения ещё одного "режима"? Это совершенно не то место, где нужно оптимизировать. Вот закрывающие теги в HTML — это да, экономия. Хотя, куда лучше вообще отказ от HTML если не на уровне исходных кодов, то уж на уровне представления при редактировании — точно.
(кстати не только в виме)
Вы второй человек, кто упомянул слово 'стрелка влево', когда вся статья была о том, что стрелки моветон. Кроме того, в комментах звучала мысль, что контрол и шрифт — зло. И тут же были сочетания клавиш с заглавными буквами. Я печатаю вслепую на эргономичной клавиатуре, я понимаю, что такое до стрелок тянуться. Но вы мне весь шаблон рвете… То стрелки зло, то тут же советы со стрелками.
есть такая привычка — сначала набираем две скобки(или кавычки, или любые другие парные символы), потом нажимаем стрелку влево
Погодите, вы чем пользуетесь в 2017 году? Разве не во всех редактора кода уже давно по дефолту, что при наборе парного символа (левой скобки или апострофа) правый добавляется автоматом, а курсор остаётся между ними?
Ещё удобно настроить какое-нибудь сочетание клавиш, которое поставит точку с запятой в конце строки и забьёт Enter, после того, как ты ввёл содержимое последних скобок.
Да проблема-то не в этом. Проблема в том, что иногда нужно обернуть в кавычки или скобки уже написанный блок текста — и тут-то автоматическое закрытие показывает себя во всей "красе".
Пример — гифка в комментарии ниже.
(да, есть replace quotes, surround selection но вот самый очевидный и базовый функционал — без элементарной эвристики, не понимает когда не надо добавлять кавычку)
В Vim этой ереси по‐умолчанию, к счастью, нет. Я люблю вставку открывающей+закрывающей сразу, но у меня это на отдельных сочетаниях клавиш. Плюс дополнение surround.vim, позволяет легко запихивать различные конструкции в скобки/кавычки/… или удалять сразу два парных символа.
Если нет — 2 переключения: Esc, i
Всегда приходится неистово нажимать esc до пиканья в консоли, чтобы случайно не оказать не в том режима и не начала происходить неведомая хрень, что придется вырубать питание))))
Печально, но если задать этот вопрос среднестатистическому гуру вим-гольфа — он его просто не поймёт.
Любой, кто постоянно пользуется вимом и осилил хотя бы базовый набор функций, легко ответит вам на этот вопрос, не нужно утрировать.
Конечно ответит. Он и отвечает, но, насколько я понимаю он сразу отвечает на вопрос — как пользоваться режимами. И у того, кто спрашивал, создаётся впечатление, что режимы это такой пережиток прошлого, но ради других достоинств вима люди терпят.
Буквально в прошлой холиварной статье на хабре писали и про удобную навигацию по тексту, и про возможности кастомизации плагинами, коих сотни, и про быструю развертку своего конфига на удаленном сервере. Режимы просто дают возможности, сами по себе они сомнительные киллер-фичи.
Режимы просто дают возможности, сами по себе они сомнительные киллер-фичи.
Возможности, которые дают режимы, можно предоставить и без них. Но нередко люди хотят именно модального интерфейса.
удобную навигацию по тексту, и про возможности кастомизации плагинами, коих сотни, и про быструю развертку своего конфига на удаленном сервере
Удобство понятие относительное, меня например устраивает вариант ctrl+стрелка.
Остальные «фишки» вполне себе реализуются с использованием классического сейчас интерфейса.
Так какой же ответ, который будет знать любой, кто осилил базовый набор функций?
Перемещение по тексту — это о том, что я могу не брать в руки мышь. В любое место на экране я попадаю практически мгновенно либо через стандартные команды, либо через easymotion плагин когда нужное место где-то далеко внутри строки. Если вам нравится нажимать ctrl-стрелку, чтобы перейти строк на 20 вниз и в сторону, ради бога, только о какой оптимизации мы вообще тогда говорим?
Кастимиированная версия вима переезжает на удаленный сервер ровно за то время, которое требуется, чтобы сделать clone из моего репозитория.
Плюс интеграция с tmux.
Очень даже хорошо пишется код в Vim, уже лет 10 им пользуюсь, 6 из них пишу код.
Надо просто понимать что Vim это продвинутый редактор с удобным интерфесом за счет режимов и кучей плагинов.
Но если нужно изучить код, то конечно лучше IDE
Сначала в статье был длинный кусок на эту тему, но в конце концов я понял, что для нормального объяснения нужно 3 таких статьи с прикреплёнными видеороликами. Поэтому я оставил ооооочень маленький кусок про необходимость переключаться между режимами с помощью клавиш i и эскейп, а также про перемещение курсора без клавиш-модификаторов в режиме вставки. Придумать, как хорошо продемонстрировать, что такое режимы, не смещая при этом фокуса статьи я не смог :(
Но тогда, получается, статья лишилась смысла.
Статья писалась для того, чтобы те, кто хочет выяснить чем хорош вим — выясняли чем хороши режимы, а не пытались понять ради чего пользователи их терпят.
Я хотел, чтобы из статьи было понятно, что причина использовать вим — режимы. Я лично знаю несколько человек, которые узнали что такое режимы, знают, как ими пользоваться и при этом считают их досадным пережитком старины и продолжают попытки выяснить в чём всё-таки настоящая сила vim.
Из моей статьи нельзя понять, что такое режимы и как ими пользоваться. Но можно понять, что, если вы разобрались что такое режимы и они вам не понравились, то дальше причины, по которым люди пользуются вимом, можно не искать.
Режимы это нехорошо только тогда, когда пользователь путает, в каком режиме находится в данный момент. Например — плохо переключать язык по одному сочетанию клавишь. С модальным интерфейсом вима такой проблемы нет.
Нет с вимом таких проблем. Текущий режим считывается одним взглядом в левый нижний угол.
И про это там тоже есть. Можете поискать по "не находится в локусе внимания".
В каком режиме ты находишься как правило легко понять по форме курсора, который как раз находится в этом самом локусе. Проблем с пониманием в каком режиме сейчас находится пользователь в виме нет.
Про блокнот, видно что 3 страницы текста по ссылке вы осилить не способны, чтобы дочитать до понятия квазирежимов, например, позволяющих сохранять файлы через Ctrl+S, которое есть хоть в блокноте, хоть в саблайме, а в куче редакторов вообще автосохранение.Автосохранение с автопридумываением имена файла, я так понял? Речь идёт о том, что выполняя определённое действие вы попадает в другое окно, в котором у вас другой мир и старые команды не работают. Работает только… барабанная дробь клавиша ESC. А иногда, кстати, и она не работает.
Так чем эти режимы (коих десятки в так восхваляемом вами Sublime) лучше того, что в VIM'е? Тем что там нет отдельного режима редактирования и ввобда текста? Но есть отдельные режимы (без всяких «квази», я статью прочитал, не беспокойтесь) для ввода имени нового класса, строки для поиска и прочих интересных вещей? Чем режим поиска текста в Sublime лучше командного режима в VIM'е? Тем что Sublime вам нравится, а VIM — нет?
Причем тут режим поиска текста и окна сохранения? Это альтернативные режимы работы других редакторов что ли?Таки да. При редактировании текста я поиском очень часто пользуюсь.
И еще, может быть, где-то придумали, как в этих местах модальности избежать?Дык разумеется! Вы тут поминаете всуе Раскина, а Canon Cat когда-либо видели? Ну хоть на картинке? Вот у него как раз всё сделано «по феншую»: поиск — это не отдельный режим, а отдельный квазирежим.
Вся статья про то, что в виме два основных режима, и это типа хорошо.Это не мы говорим. Это ваш «гуру» говорит:
Иногда разработчики говорят, что режимы нужны потому, что число необходимых программных функций превышает число жестов, которые пользователь может выполнить с помощью клавиатуры и графического устройства ввода, поэтому жесты должны использоваться многократно. Однако число команд, исполняемых с помощью монитора (например, меню), и команд, вводимых с клавиатуры в командную строку и содержащих множество символов, может быть неограниченным и потому позволяет избежать упомянутой трудности.
И? Где в вашем Сублиме командная строка, позволяющая избежать перегрузки интерфейса режимами?
Вся статья про то, что в виме два основных режима, и это типа хорошо.Именно так. Имеющиеся в VIM'е три режима позволяют обойтись без десятков и сотен режимов и режимчиков, которые имеются в других редакторах — тем и хороши.
Попытки же борьбы за «интерфейс без режимов» под руководством Раскина так ни к чем популярному не привели, как вы верно заметили.
У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд. С сохранением то же самое. «Тем более» в начале я сказал, потому что именно у поиска есть несколько отличий, в т.ч. несколько дополнительных клавиатурных сочетаний, тогда как сохранение делается только командой без каких‐либо особенностей. И «команда» здесь в смысле «выражение на языке программирования, выполняемое ради побочных эффектов (т.е. без возвращаемого значения)», какое выражение прекрасно сочетается с другими командами, если нужно, а не что‐то, позволяющее только написать имя файла и больше ничего.
PS: «плагинчики для гиков» почему‐то есть в стандартной поставке: то же https://github.com/JetBrains/ideavim откуда‐то имеет бейджик «JB official» (хотя и требует отдельной установки) и упомянуто в официальной документации, а не в редакторах, но интерактивных оболочках вроде bash, zsh и fish (последнее ещё и называет себя «friendly interactive shell») аналог есть без установки каких‐либо дополнений. Зачем JetBrains внезапно официально поддерживает «плагинчик для гиков», вам не кажется это странным?
Режим ввода команд начинается в том числе с /, но вопрос не в этом: в sublime есть именно режим поиска, который не основной, и который сделан с одной узкой целью со своим узкоспециализированным элементом интерфейса. Сохранение тоже позволяет только сохранять, и тоже имеет отдельный интерфейс. В Vim есть режим для ввода команд редактору, но он не настолько узко специализирован и интерфейс для ввода поисковой строки практически не отличается от интерфейса для ввода команды сохранения. Кроме того, командный режим официально признаётся режимом, и при том одним из основных.
И ещё, нет такой вещи, как «поле ввода имени файла», оно часть команды. Внимание смещается просто в командную строку.
Где я или кто‐то ещё говорил про «одну точку входа»? Она там не одна, режим там один на много разных вещей. С необходимостью или наличием модальности я не спорил, я спорил только с определением количества режимов.
(А spotlite-like окошки — это хорошо, но это не вопрос «CLI vs GUI», на ncurses для своей программы при желании можно и такое написать, просто пока никто одновременно хочет и способен это сделать, да и приложений, где такое было бы оправданно, для терминала не слишком много. Да и не то что ncurses, специально для Vim можно подпилить какое‐нибудь дополнение вроде ctrlp.)
Наличие второго основного режима тут преподносится как невероятный подарок. А на самом деле это просто лишний режим на ровном месте, там где его могло и не быть. В нормальных редакторах его и нет, либо он опциональный(см. «плагины для гиков»).Но зато там есть куча режимов и режимчиков, которых тоже могло бы и не быть. Начиная хотя бы с того факта, что почти все редакторы, которые я видел имеют режим вставки и режим замены.
Единственное концептуальное отличие VIM'а от других редакторов является то, что режим ввода текста тут не является основным. Хорошо это или плохо — зависит от вашего стиля редактирования: если вы из тех, кто заголовок в Word'е центрует пробелами, то вам VIM точно ни к чему.
У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд.
Мнэээ… но ведь результаты применения разные — после '/' будет поиск по регулярному выражению, а после ':' — выполнение команды.
Даже если редактирование одинаково, это таки вполне соответствует понятию "режим".
(И я не говорю, что это плохо.)
Кэнон Кэт я видел вживую в Музее компьютерной истории, и что? Причем тут Кэнон Кэт?Мы вроде как о поиске тут говорили? Ну так вот у него — такие большие красные клавиши есть. Их очень сложно не заметить. Именно для того, чтобы этот самый поиск без создания режимов производить.
Режима задания имени файла том тоже не было (могли бы поинтересоваться тем, как это было сделано, раз уж вы такой фанат).
Исследования Раскина и других привели к тому, что ни один современный текстовый редактор не идет по пути вима.Neovim, первая версия которого вышла в 2015 году — для вас недостаточно современен?
Или вы про то, что все современные модальные редакторы используют подход VIM'а? Ну так и с немодальными та же история — сплошной Ctrl+C/Ctrl+V, куда ни плюнь.
А вот попытки избавиться от режимов в принципе (и от режима ввода имени файла и от режима поиска подстроки и от командного режима) — не удалось настолько, что когда вам в это, я извиняюсь, тыкают носом — вы начинаете кипятится и пороть чушь:
Режим сохранения файлов требует ввода имени, если файл новый. Хоть в блокноте, хоть в виме, хоть где-то еще.Не требует, если система соответствующим образом спроектирована. Ни в Canon Cat, ни в Archy этого не требуется.
Мой «Гуру», в кавычках, подмена понятий, как мило.Где я подменил понятия? Если бы Раскин для вас был настоящим Гуру, без кавычек, то, уж наверное, если бы не пользовались средой, воплотившей его идеи (отказ от окон, команды вместо программ, ZUI и прочее), то, как минимум, знали бы о них.
А так получается что вы носитесь с его книгой, но открыть её и почитать — похоже так и не удосужились. Такой подход сектантством попахивает, уж извините.
А тот факт, что об идеях Раскина даже его самоназваный фанат не подозревает — по моему характеризует «величие» его наследия лучше, чем что-либо ещё.
Раскин в ветке появился как самый известный человек, описавший проблемы режимов
И я считаю, что для вима эти проблемы либо не свойственны, либо преимущества режимов с лихвой компенсируют их недостатки.
Поспорьте с Википедией
Хорошо, давайте поспорим с википедией :). Прежде всего в качестве самых ярких примеров проблем с режимами там приведены примеры использования клавиш CapsLock и Insert. Но эти клавиши не вредны, а просто бесполезны. Проблемы с ними возникают когда ты случайно нажал одну из этих клавиш и пытаешься понять, что произошло. Намеренно их используют очень редко. Поэтому в контексте проблемы режимов о них говорить особого смысла нет.
Кроме этого википедия упоминает проблемы с внезапно появляющимися модальными окнами и проблему отдельного режима ввода сообщений в компьютерных играх, из за которого ты можешь не успеть вовремя среагировать на хедшот. Тут тоже не поспоришь, но в виме таких проблем нет, а с тем, что режимы могут вредить я в общем согласен.
И наконец, речь заходит о vi. Википедия упоминает, что для новичка vi сложен из-за режимов. Опять же, согласен :). Для новичка привыкнуть к режимам непросто. Для того, кто привык без них уже тяжело.
Немного о влиянии работ Раскина на текстовые редакторы
И отдельно хочется обсудить последний пункт из википедии. Где-то выше по ветке вы упомянули, что таких редакторов, как вим больше не делают благодаря работам Раскина. По-моему это называется социальным доказательством.
Так вот, реальный пример повседневного использования режимов, который причиняет вред и мешает работать большому количеству людей это циклическое переключение раскладки клавиатуры. И, несмотря на наличие работ Раскина, дискуссия о переключении раскладки как правило сводится к тому, какой клавишей её лучше переключать.
Те, кто не хочет заморачиваться используют дефолтный Alt+Shift, более продвинутые меняют его на Control+Shift, постигшие дзен слепой печати возвращаются обратно к Alt+Shift, потому что это позволяет не двигать руку, а маководы сидят на Command+Space, не знаю почему.
Самые решительные и радикальные настраивают переключение раскладки на клавишу CapsLock.
А, между тем, по уму нужно от циклического переключения раскладки отказаться и забить хоткей на один язык и хоткей на другой. Однако тех, кто делает так, можно перечесть по пальцам.
Как же так вышло, что в случае с текстовыми редакторами, рекомендациям Раскина последовали, а в случае с переключением раскладки — забили на них большой болт? По моему мнению, Раскин тут вообще не при чём. Модель редактирования текста, используемая большинством текстовых редакторов исторически появилась раньше, чем модель, используемая в виме и для начинающего пользователя она гораздо проще. Поэтому она и распространена. С переключением раскладки точно так же.
Кстати, интересно, как вы переключаете раскладку?
В защиту циклического переключения раскладки. При использовании правильного метода слепой печати (который "не глядя на клавиатуру") ошибка режима заметна сразу же, и очень просто исправляется. Это не летательный аппарат который нужно сначала суметь удержать в воздухе прежде чем делать что-нибудь еще.
Я привык переключать раскладку через RAlt+Shift и не испытываю никаких проблем (кроме того что с некоторого момента винда из коробки не поддерживает этот способ, а также раздолбанного шифта — но эти недостатки сохраняются и при переключении раскладки через два разных хоткея).
В защиту циклического переключения раскладки. При использовании правильного метода слепой печати (который "не глядя на клавиатуру") ошибка режима заметна сразу же, и очень просто исправляется.
Если не печатаешь вслепую, циклическое переключение раскладки это вообще ад :). Но даже, если сразу понимаешь, что с раскладкой что-то не так, к этому моменту уже обычно напечатано две-три буквы. Их надо удалять, потом переключаться. И я часто забываю, какой язык сейчас активен, особенно, когда пишу текст в котором надо использовать англоязычные термины.
Вы зря переключение языка по разным клавишам считаете решением. Предлагаемый вами подход приводит к одному из 2 сценариев:
- Если пользователь переключает раскладку лишь когда думает, что сейчас не та, то получает одни и те же проблемы что с одной клавишей переключения, что с двумя.
- Если пользователь переключает на нужную раскладку каждый раз начиная ввод, то это очень дофига ритуализированных нажатий. Любое сколь угодно краткое вырывание из потока ввода текста и надо снова актуализировать выбранную раскладку. Кстати, идея для вима: переходить в режим ввода текста, не по нажатию на i, а по выбору конкретного языка ввода. ir и ie, например.
На мой взгляд проблему режимов языков (а от них не избавиться без педальки или второй клавы) лучше решать через превентивный фидбек. Например, цветоформой курсора и/или поля ввода (в случае однострочных полей). То есть собираясь ввести куда-то текст ты автоматически считываешь информацию о том, на каком языке будешь печатать. Плюс пунтосвичер, если вдруг всё же ошибся.
Тем не менее, я согласен, что переключение языков разными клавишами удобнее, особенно, если языков больше, чем 2. У меня под досом была такая тема, как включение русского по правому альту, а английского по левому. После этого привыкать ко всяким альт-шифт было очень тяжело.
Где-то выше по ветке вы упомянули, что таких редакторов, как вим больше не делают благодаря работам Раскина. По-моему это называется социальным доказательством.
Neovim?
Самые решительные и радикальные настраивают переключение раскладки на клавишу CapsLock.
Гм… меня когда-то просто приучили к CapsLock, и я не вижу тут ничего радикального :) Это банально удобно. В отличие от
А, между тем, по уму нужно от циклического переключения раскладки отказаться и забить хоткей на один язык и хоткей на другой. Однако тех, кто делает так, можно перечесть по пальцам.
Да, и именно потому, что
Режим клавиатуры всё равно надо помнить, хотя бы краем одной извилины. Собственно наличие одной клавиатуры (а не двух, или даже одной восьмирядной) вынуждает к этому. Набор не в том режиме приводит к неверному результату. Punto Switcher не вспоминать — это костыль, не работающий в сложных случаях (а для программиста не пригодный, считаем, во всех практически важных случаях).
- Все эти хоткеи будут значительно тяжелее набираться, чем один кивок левым мизинцем (или, для ниасиливших десятипальцевый набор, как я — левым безымянным). Ограничивающее условие: две постоянные раскладки по кругу. Если иной вариант (например, 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 обработакт операционная система, да?
Да. А как иначе? (на реальных системах)
Надо! Это же кратно увеличивает количество возможных комбинаций клавиш!
Мне кажется, их и так больше, чем можно запомнить за разумное время.
А что именно вы предполагаете? Чтобы он понял цепочку из переключения ввода и входа в режим вставки как нечто целое?
Раскин в ветке появился как самый известный человек, описавший проблемы режимов, даже для таких лососей, как автор поста или вы, бегающие и вещающие, какие в виме они офигенные.
Раскин — экстремист (как и Вы, судя по 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 мы сегодня работаем? ;)
Но выдавать за киллер-фичу то, чего в любом букваре для дизайнеров рекомендуется избегать — это ломать мозг неофитам. Нефиг.
Киллер фича — это такая штука, из за которой пользователи любят приложение. Которая его "продаёт". Если при этом в букваре для дизайнеров рекомендуется её избегать — она из-за этого не перестаёт быть фичей, из за которой приложение вообще нужно людям.
В вашем понимании пользователи — это только люди, преодолевшие порог вхождения, появившийся из-за этой киллер-фичи.
С чего вы это взяли? Пользователи вполне могут пользоваться приложением и его не любить. Вим вот любят за режимы. Не любят — тоже за них :). Но вообще приложение, которое ты не любишь — лучше не использовать, если есть такая возможность.
А остальные по-вашему — например те, кто честно хотел или был вынужден работать с вимом, но сдал назад из-за проблем редактора с юзабилити и умеет только поменять текст и написать :wq — это типа уже и не пользователи.
Всё зависит от того, используют они вим, или нет.
Или люди типа меня, которые таки осилили мануал(к текстовому редактору, sic), использующие вим в работе, но не считающие режимы его киллер-фичей или преимуществом, а наоборот — минусом — это по-вашему тоже не пользователи.
Мне кажется, вам имеет смысл определить почему мы пользуетесь вимом и найти редактор, в котором есть это самое "почему", но нет режимов. Это сильно облегчит жизнь.
Но все приведенные мной аргументы против неоправданного использования режимов никуда не пропадут, а в пользу них — не прибавится.
Я в этой статье не хотел рассказать почему режимы, это очень хорошо, даже что это просто хорошо не хотел сказать (хотя я, конечно, так думаю). Я хотел сказать только, что вим любят из-за режимов.
Собсно аргумент-то у вас сквозь статью и комменты ровно один — надо привыкнуть к режимам и все станет хорошо.
Нет, основная мысль статьи — "Если вам не нравятся режимы, не нужно искать, что в виме компенсирует их наличие. Ничего такого там нет. Если режимы раздражают, то лучше не пользоваться вимом — ничего не потеряете"
Тут два момента.
Во-первых, какое заявление ничем не подкреплено? Что режимы это нехорошо когда пользователь не понимает, в каком режиме находится в данный момент? Так вроде у Раскина и написано, что модальный интерфейс — зло, потому что пользователь путает режимы.
Или вы про утверждение, что с модальным интерфейсом вима эта проблема отсутствует? Оно подкреплено моим личным опытом и опытом других любителей вима.
И второй момент. Вы только что говорили о том, что сквозит через всю статью, а потом вдруг съехали в "да я про комментарий из ветки, а не про статью". А с тем, что проблема для новичков есть, я об этом тут же и писал.
То есть не подтверждено ничем, кроме ваших слов, в отличие от хотя бы статьи на википедии, что вы только что сами в очередной раз подтвердили.
Не только моих слов, а ещё слов большого количества пользователей вима.
С другой стороны, ваше мнение о том, что опытные пользователи вима путаются с режимами точно также не подтверждено ничем, кроме мнения тех, кто с вами согласен. Они, в большинстве своём, что характерно, опытными пользователями vim не являются.
Раскин, люди из википедии — они там не про вим рассуждают, они говорят — режимы — это плохо. Везде, всегда, старайтесь их избегать, когда возможно.
Почтайте Раскина, он, в отличии от вас, обосновывает свою позицию тем, что пользователи путаются в режимах. Если бы пользователи в них не путались, проблем с режимами бы не было.
Опытные пользователи вима не путаются в режимах, следовательно у них проблем с режимами нет.
Вот такой вот простой силлогизм.
Приведите ссылки не на мнения своих друзей, а на исследования, показывающие, что в виме модальность является исключительной и не попадает под рамки приведенных исследований.
Про то, почему модальность в виме не вредна с точки зрения Раскина я уже объяснил, а тут хочу сказать, что вим тут не исключителен. Раскин, например, приводит пример фонарика, который включается и выключается одной кнопкой, я добавлю сюда пример с электической дрелью. Режимы есть, они не мешают, хотя можно было бы обойтись без них. Такие дела.
А вот насчёт исследований, на которые вы ссылаетесь. Мне интересно, это были такие исследования в которых взяли 100 опытных пользователей вима и 100 опытных пользователей notepad++, попросили их сделать примерно одинаковые вещи и замеряли количество ошибок, которые пользователи вима сделали из-за того, что не понимали в каких режимах они находятся? А самим пользователям сказали, что замеряют их производительность в зависимости от марки напитка, который им выдали перед испытанием?
Ну, чтобы цель исследования не влияла на подопытных?
Ссылка на исследования юзабилити веба.
Да, теперь многое понятно. Жаль, что вы оказались не в состоянии ответить на простой вопрос про методику исследований, если бы вы прочитали книгу на которую ссылаетесь, вы вне всякого сомнения ответили бы без особых пробем.
Почитайте букварь, объяснятель.
Так и скажите, про исследования слышал где-то, как они проводились не знаю, объяснить ничего не могу, буду давать ссылки, пока вы не поймёте, что кроме них у меня ничего нет.
Нет, что вы видите себе Д'Артаньяном было понятно практически сразу, но что вы ещё не читаете, что я вам пишу, это я понял только сейчас.
Я: Вот пруф, что все путаются
Пруф, что все путаются в режимах вима? А то там у Раскина написано, что могут и не путаться.
Вы: Раскин не знает о чем пишет
Раскин пишет, что режимы плохи потому, что в них путаются. С вашей стороны неплохо бы цитату, в которой я говорю, что Раскин не знает о чём пишет.
Я: Вот еще куча пруфов
Нет, не куча пруфов, а ссылка на википедию, в которой написано, что неопытные пользователи путаются в режимах вима. С этим я, что интересно, не спорил.
Мои ссылки показывают, что все путаются
В виме? А то последняя ваша ссылка рассказывает о методиках исследования веб интерфейсов.
Асилили, асилили. Но заодно увидели насколько же у вас узок «локус». Потому что вы одно слово заметили, а соседнее — уже нет:Тем не менее, безопаснее всегда избегать применения режимов в разработке интерфейсов.Ниасилили?
Тем не менее, безопаснее всегда избегать применения режимов в разработке интерфейсов.Заметьте — не удобнее, не быстрее, а именно безопаснее.
Вся работа Раскина была нацелена на решение одной проблемы: как-бы-это-так-сделать-эту-хитромудрую-технику-доступной 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
Есть ещё ссылки?
Я видел людей, которые делают офигенные вещи через vi/vim, через notepad++, через встроенный редактор в FAR. У каждого свои «механически задроченные комбинации», за которыми посторонний не всегда успевает уследить глазом. Но они стали такими не сразу, а после того, как человек близко познакомился с функционалом.
То есть вопрос удобства не всегда должен рассматриваться как «мгновенное улучшение».
Переходить с привычного инструмента на совершенно новый ради одной или двух-трех киллерфич — не всегда работает.
В большинстве случаев гораздо проще найти аналог такой фичи в инструментах, которые ты уже используешь — о чем и идут постоянные холиворы.
Ну вот лично мне в какой-то момент мышка стала тупо мешаться — лишний контроллер, на который иногда приходится отвлекаться… в итоге перешел на Emacs (до этого программировал в VS, Eclipse, QT Creator) и теперь бОльшую часть времени работы за компьютером я вообще не задумываюсь над тем, что и как делать — все делается при помощи хоткеев, которые пальцы сами помнят) И сейчас единственное, чего не хватает в OS для полного счастья — это интеграции своего emacs-конфига на уровне OS, чтобы всякие браузеры и мессенджеры с ними умели работать)
Попросили описать личный опыт, почему мне хотелось не пользоваться мышью(тачпадом)/стрелками, описал, получил минусы, причём даже в карму судя по всему) Причём, что характерно, никаких гневных комментариев разъясняющих в чём я не прав и где задел чьи-то чувста, просто тупо минусы.
Дело в том что объяснять это действительно тяжело. В первую очередь из-за того, что сторонние наблюдатели считают режим вставки основным, вимеры считают таковы командный режим (он не зря здесь называется нормальным).
Вот какие фокусы доступны в нормальном режиме:
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 — по словам
Ситуация с плагинами довольно нелепая. На этапе создания 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 приходится жать на порядок реже. Как итог, существенно меньше напрягаются кисти.
Русский язык, к примеру.
Впрочем, бывает, что в состоянии потока код прёт как бешеный. Но это не зависит от ЯП, только от степени понимания задачи и наличия времени для спокойного погружения в кодинг.
Не исключено, что тут влияет дополнительная нагрузка на кисти. Я в те годы активно барабанами занимался. В комментах ниже гитарист тоже на Emacs жалуется.
Ну и, опять же, физиология у всех разная. Кто-то более предрасположен к RSI, кто-то меньше. Возраст тоже влияет: чем старше пациент, тем больше шансов поиметь проблем со связками.
Хаха, тоже так когда-то думал. Но руки сделали свой выбор сами.
А evil-mode не пробовали?
Знаю про него, но так руки и не дошли. Привык уже к классическому vim.
Главная киллер-фича vim для меня — руки меньше болят после целого дня работы с текстом
У меня одно время тоже начали побаливать руки, когда много на встроенной клаве ноута фигачил, держа их на весу. Подключил классическую внешнюю клаву, кинул перед ней силиконовую подушку, на которой руки лежат практически неотрывно (и ни малейших проблем ни с какими комбинациями не испытывают) и всё прошло. Но возможно мне просто повезло с длинной пальцев (я бы с удовольствием добавил между цифрами и F-клавишами ещё один программируемый ряд полноразмерных кнопок и мне было бы не менее комфортно).
Естественно, как любой нормальный емаксер, я control перемапил на caps lock, ну и клава должна быть не сильно плохая (сейчас у меня макбук, на декстопе когда сидел — была майкрософт натурал, потом майкрософт 4к).
Если есть возможность я бы сейчас смотрел на Atom/Visual Studio Code, мне кажется это очень перспективные вещи, возможно, лет через 20 даже emacs начнут догонять.
Киллер фича Vim