Если открыть вимом файл, перевести курсор в нужное место и начать печатать, то с текстом на экране будет происходить всё что угодно, кроме того, что пользователю хотелось сделать. Кратковременный приступ паники, перемешанной со злостью, пройдёт достаточно быстро, ведь файл пока никто не сохранял, так что можно просто отключить питание, включить компьютер обратно и погуглить.
Гуглим, выясняется, что для превращения вима в нормальный редактор нужно нажать i. Только сохранить поредактированный текст нельзя, перед этим надо несколько раз нажать эскейп, а потом набрать :w. А, чтобы его закрыть, нужно нажать эскейп, а потом набрать :q. Тяжёлое наследие прошлого. Ну, зато вим есть везде.
Но в какой-нибудь из статей, рассказывающей, как провести 5 минут в виме и остаться в живых, обязательно будет написано, что вим — лучший текстовый редактор в мире. И ещё выяснится, что люди в нём программируют. То есть, натурально, пишут код. То есть, на дворе 21 век, в любой момент можно скачать Visual Studio, Intellij Idea или, прости господи, Eclipse, а они пишут код в виме. Добровольно.
IDE настолько облегчает работу программиста, что отказаться от использования интегрированной среды разработки нынче можно только имея очень веские причины. И, раз некоторые отказываются от IDE в пользу вима, значит там должно быть что-то круче автоматического рефакторинга, круче интегрированного дебаггера, круче подстановки импортов и интеграции с системами контроля версий.
Интересно, какие такие фичи есть в виме, которых нет даже в IDE, не говоря уже о банальном notepad++?
Печально, но если задать этот вопрос среднестатистическому гуру вим-гольфа — он его просто не поймёт. В этом можно убедиться почитав комментарии на Хабре и вообще полазив в интернете. В ответ на вопрос, чем хорош вим, зачастую пишут, что вот там можно удалить слово, набрав diw, а, если не хочешь удалять, а хочешь выделить, то набираешь viw. Ну, то есть, в первом случае в начале d, во втором v, но потом то и там и там iw, что означает inside word. Ну не круто ли! Утрирую, конечно, но очень похоже на правду.
Но программировать-то в нём как?
Вопрошающий обычно уточняет — вим ведь как-то справляется с задачами, которые обычно решает IDE. Интересно, как? Ему отвечают, что в виме есть много офигенных плагинов, только их надо ставить и настраивать.
Чем эти плагины лучше чем возможности, предоставляемые IDE, выяснить как правило не удаётся, изредка удаётся выяснить, что IDE тормозит.
Тут все становится понятно, человек, который хотел узнать зачем нужен vim, рекомендует второй стороне дискуссии купить компьютер побыстрее и устраняется из разговора.
А между тем, ему стоило бы поставить вопрос прямо.
Ради каких фич вима, пользователи готовы терпеть такие фатальные недостатки, как несколько режимов работы, необходимость запоминать кучу клавиш, и добровольно отказываются от использования стрелок?
Ведь на самом деле, всё наоборот
Это не ради фич вима пользователи готовы терпеть режимы, а ради того, чтобы продолжать пользоваться режимами, пользователи пилят новые фичи в виме.
Да, именно так. То, что на первый взгляд кажется унаследованной медвежутью — на самом деле то, из-за чего вим вообще кому-то нужен.
Вы, возможно, считаете, что ничего хорошего в этих режимах нет и быть не может. Предположим даже, что так оно и есть. Но тем не менее вимом пользуются именно из-за них, всё остальное вторично. Собственно это и есть главная и единственная мысль статьи.
Режимы не фатальный недостаток, а киллер фича.
В обычном редакторе для того, чтобы переместить курсор к концу слова нужно зажать Control, а потом, не отпуская его, перенести руку к стрелкам и нажать клавишу вправо. В редакторе получше, можно нажать не вправо, а какую-нибудь клавишу на буквенной часть клавиатуры, например d, но Control всё равно придётся держать зажатым. А в виме нужно просто нажать e. Пользователи вима ценят возможность проводить манипуляции с курсором и текстом без необходимости держать при этом зажатыми клавиши-модификаторы или убирать руки с home row. Это расслабляет.
Сделаю тут акцент — речь не идёт о том, что с использованием режимов можно сделать такие штуки, которые без них сделать нельзя. Речь не идёт о том, что с использованием режимов всё получается быстрее, чем без них. Речь исключительно о том, что с использованием режимов пользователям вима работать удобнее и приятнее. Или, по крайней мере, они в это искренне верят.
И, если вы хотите понять, что хорошего в виме, нужно пытаться понять, что хорошего в режимах, а не выяснять, какие фичи есть в плагинах и, тем более, не пытаться понять чем эти фичи лучше тех, что предоставляют IDE.
А, если вы хотите обосновать кому-нибудь, что вим — полный отстой, то нужно доказывать, что режимы — полный отстой. Тем, кто использует вим, это на самом деле ни разу не очевидно.
Обратное, кстати, тоже верно. Если хочется объяснить кому-нибудь зачем нужен вим и почему он такой замечательный — рассказывать про плагины бесполезно. Плагины в IDE не хуже. Кроме того, если портировать плагины из вима в какую-нибудь IDE её нельзя будет использовать вместо вима. Для этого надо переносить главное — режимы.
Вместо послесловия
Возможно кто-то скажет, что писать целую статью ради такой мелочи это оверкил. Я тоже так думал, но картину, описанную выше, я наблюдаю уже несколько лет.
Между любителями вима и всем остальным миром существует какое-то грандиозное и при этом совершенно дурацкое непонимание, и я надеюсь, что когда я встречусь с ним в следующий раз, мне достаточно будет дать ссылку на эту статью.
Комментарии (499)
Beholder
12.10.2017 10:38+9Что мы узнали из статьи? Что клавишу
Eнажать быстрее, чемCtrl+Right. Ок.
poxvuibr Автор
12.10.2017 11:00Я хотел сказать, что это может быть и не сильно быстрее, но, для многих людей, сильно удобнее.
redfs
12.10.2017 11:44но, для многих людей, сильно удобнее
Дополню фразу примером, чтобы было понятнее. Вспомните печатную машинку. Когда человек умеет быстро печатать слепым десятипальцевым методом vim для него гораздо удобнее. Все эти сочетания клавиш не просто медленнее, они мешают.
domix32
12.10.2017 14:47Вот собственно и суть фичи — vim хорош для быстрых манипуляций с текстом. Но саму разработку он не ускоряет. Там нет такого количества манипуляций с текстом (может быть веб?). Навигация по коду, поиск, рефакторинг — не уступают и не превосходят современные IDE. Они просто делают это иначе. Для vim нужно запоминать кучу однобуквенных сочетаний, для обычных IDE — кучу горячих клавиш. Разница возникает только когда человеку хочется трогать мышь или работать по удаленке.
evseev
12.10.2017 20:17Там нет такого количества манипуляций с текстом
В Vim есть все, что связано с любыми манипуляциями с текстом. В нем уже реализован любой бред, который вам придет в голову. Даже если вы придумаете это под тяжелыми наркотиками или попросите что-то придумать больного на всю голову психа даже не сомневайтесь. Vim будет на вашей стороне.
vintage
12.10.2017 20:33Хочу из списка слов разделённых пробелами получить все варианты их перестановок, каждый на отдельной строке.
Хочу по нескольким введённым словам получить осмысленное предложение-палиндром, начинающееся с них.
Хочу по введённой строке текста получить список словосочетаний, которые рифмуются с окончанием строки.
domix32
13.10.2017 00:12Разработка маленько не про текст, а про логику. И если это не верстка латеха или какого-нибудь html/css/xml больших манипуляций с текстом обычно не происходит.
zagayevskiy
12.10.2017 20:06+1Я не настолько быстро думаю, чтобы десятипальцевый метод что-то ускорил. Серьёзно. Набор текста в программировании — это вообще мизер.
3aicheg
13.10.2017 11:03Слепой десятипальцевый метод в программировании реально помогает. Не из-за ускорения набора текста программы, как такового. Из-за того, что не надо отвлекаться от обдумывания программы на борьбу с клавиатурой. Понял, что должно быть на очередной строчке твоей программы — дальше пальцы сами справятся, тыц-тыц, и оно уже там. Впрочем, надо заметить, что дурацкое расположение скобок и спец-символов на клавиатуре приводит к очень частым опечаткам именно в них и портит всю картину довольно сильно.
mdErrDX5341
13.10.2017 11:15Опечатки… вот где особенно помогает слепой метод печати, так как они исправляются сразу, а не в тот момент когда оторвал взгляд от клавиатуры...
zagayevskiy
13.10.2017 11:43Много вы знаете людей, печатающих не слепым методом, но тупящих в клавиатуру не отрываясь?
poxvuibr Автор
13.10.2017 11:51Обычно на клавиатуру смотрят пока печатают слово. А опечатки видны уже после того, как посмотришь, что напечатал.
zagayevskiy
13.10.2017 11:53Есть статистика с пруфами?
poxvuibr Автор
13.10.2017 12:00Нет, есть только личный субъективный опыт. Правда, большого количества людей. Найду статистику, обязательно поделюсь.
ZyXI
14.10.2017 00:44Я часто опечатываюсь с десятипальцевым методом, и часто знаю, что я опечатался и чуть реже, как именно я опечатался, даже не смотря на результат. Правда т.к. я на него обычно всё?таки смотрю, то такая способность относится в первую очередь к паролям.
mdErrDX5341
13.10.2017 12:05Достаточно, что бы их останавливать когда они пытаются в другой раскладке сообщение печатать...
zagayevskiy
13.10.2017 11:41Меня удивляют такие люди. Почему-то у меня нет "борьбы с клавиатурой" и алгоритм пользования мышью я не обдумываю(ну, знаете, вот этот типичный пример про "снять руку с клавиатуры, найти мышь взглядом, перевести руку на мышь, найти курсор взглядом, перевести курсор, кликнуть, снять руку с мыши, положить руку на клавиатуру").
rkosolapov
13.10.2017 07:36Печатаю 300+ знаков в минуту, на vim-е работал с 1999 по 2004, потом пересел на emacs, ибо emacs удобнее.
Почему режимы суть гавно плюс-минус нормально написано у Раскина в его Интерфейсе.
А киллер-фича емакса (и такая фича очень мало у кого есть, что-то подобное есть в Atom/Visual Studio Code, но у них это очень примитивно) — это elisp, то есть возможность работать с кодом не через клавиши, а через команды (как командная строка). У vim-а его язык расширения очень примитивен, поэтому такой метод работы в нём неудобен.redfs
13.10.2017 08:23Читаете вы тоже быстро :) Семантику моего комментария вы увидели, но не поняли смысл. Я писал не столько о скорости, сколько об удобстве для определенной группы людей, владеющей определенными навыками. Десятипальцевым можно и медленно набирать текст, но использовать сочетания клавиш при этом все равно неудобно. Другая техника.
Вообще, я уже давно не пытаюсь никого ни в чем убеждать в подобных спорах. Начинал с K52 для RSX-11M, а сейчас давно уже нахожусь в комфортном для себя балансе между vim и ide, а эту дисуссию посматриваю скорее из ностальгии. Десятки лет проходят, а темы холиваров не меняются :)rkosolapov
13.10.2017 09:26+1Я прочитал про удобство, и сразу в первом же предложении написал, что емакс удобнее.
Впрочем, тупо холиварить действительно скучно. Удобство в данном случае есть вкусовщина, тут действительно кому что любо, пусть то и юзает.
poxvuibr Автор
13.10.2017 08:34Почему режимы суть гавно плюс-минус нормально написано у Раскина в его Интерфейсе.
У Раскина написано, что плохие режимы это такие режимы, при которых пользователь не может чётко понимать в каком режиме он находится на данный момент. К виму это не относится, там забыть в каком режиме ты сейчас находишься достаточно трудно.
Пример плохого переключения режимов — циклическое переключение языков.
rkosolapov
13.10.2017 09:30> К виму это не относится, там забыть в каком режиме ты сейчас находишься достаточно трудно.
Это, мягко говоря, неправда. В виме регулярно люди путаются, в каком именно режиме они находятся. Шутки про тройной долбёж по кнопке esc не на пустом месте, да и внезапно появившийся символ i в странном месте в пулл-реквесте тоже.poxvuibr Автор
13.10.2017 10:12Это, мягко говоря, неправда. В виме регулярно люди путаются, в каком именно режиме они находятся.
Поначалу да, путаются.
Шутки про тройной долбёж по кнопке esc не на пустом месте
Во-первых, esc надо нажать не три раза, а два :). А во-вторых это нужно для того, чтобы гарантировано попасть в нормальный режим, в каком бы режиме ты не находился сейчас. Паник кнопка для новичков, которые могут не знать, в каком режиме находятся и для тех, кто отошёл от компа и не помнит что он делал.
О проблемах с символом i в пулл реквесте я не слышал.
webhamster
15.10.2017 01:00> забыть в каком режиме ты сейчас находишься достаточно трудно.
Я например когда веду машину, постоянно забываю на какой скорости еду. Особенно путаю вторую и четвертую, ибо по положению ручки понять какая включена почти невозможно.
Так же не понимаю, как можно считать редактор с режимами удобным, если постоянно приходится помнить, в каком режиме находишься. Плюс стандартные действия с текстом во всей системе осуществляются одним образом, а в vi другим. Как это может быть удобно — непонятно.khim
15.10.2017 04:38Как это может быть удобно — непонятно.
Тут вопрос не «как», а «кому». Тому, кто не путает вторую и четвёртые передачи, однако.
А профессионалов (причём не только у автогонщиков, но и у дальнобоев, коих несравнимо больше) этих передач может быть и два десятка, представляете?
Это не в упрёк вам — просто люди разные, кто-то в четырёх-пяти передачах путается, а кто-то и в 4-5 режимах VIM'а чувствует себя как «рыба в воде».
VMichael
15.10.2017 15:22Смотрите по скорости (спидометр) и тахометру.
У каждой передачи свое соотношение.
Symphel
12.10.2017 15:23+3Да, быстрее. Всегда быстрее набрать команды с клавиатуры, чем навести мышь.
Если привыкаешь писать код двумя руками, прерываться на то, чтобы, положить руку на мышь, найти курсор, навести его куда-то, нажать комбинацию кнопок на мыши и клавиатуре, вернуть руку на клавиатуру кажется не самой лучшей тратой времени.
Кроме того, использование только клавиатуры, а особенно если не приходится использовать сочетания, дает возможность по максимуму почти интуитивно использовать бытрые последовательности команд («мышечную память»). То есть я заранее знаю, какой набор действий надо выполнить, и могу это сделать очень быстро. С мышью такое невозможно — каждое перемещение курсора требует сосредоточенности и постоянного контроля, т.к. можно промахнуться.
Условно говоря, мышь — это аналоговый интерсфейс, постоянно требующий коррекции на основе телеметрии с экрана, а клаватура — цифровой, достаточно выбрать клавишу.evseev
12.10.2017 20:42+1По сути IDE и Vim в равной степени позволяют писать код не отрывая рук от клавиатуры. И поддержка мыши скорее достоинство. Если вы что-то не помните вы берете таки эту гадость в руки и тыкаете в менюшку. В случае Vim-а нужно будет доки покурить.
khim
13.10.2017 02:44Проблема не в использовании мыши. Проблема в подходе.
Вы не поверите В СКОЛЬКИХ местах IDE глотают нажатия клавиш, если кто-то набирает быстро и не глядя на экран. В VIM вы можете быть уверены, что набрав 100 команд не глядя на экран вы увидите то, на что рассчитывали. IDE (за исключением текстовых) в одном случае из 100 будет что-то глотать. Вроде бы немного, но это значит что ваши действия нужно контролировать после каждой команды. Иначе рано или поздно вы пропустите момент, когда какое-то окно не успело открыться (или закрыться), после чего уже все последующие команды пойдут «мимо контекста».
В том-то и дело, что на самом деле режимов у IDE в 100 раз больше, чем у VIM'а (окно редактирования свойств класса — один режим, окно открытия файла — другой, окно заливки в VCS — третий и так далее… сотни их… если не тысячи...).
Так что разница принципиальна: в IDE вы работаете с компьютером в режиме диалога, в VIM это «я сказал, компьютер сделал».
debose
13.10.2017 19:55Никогда об этом не задумывался в таком ключе, хотя и сталкивался не раз. Спасибо за чёткую формулировку.
khim
13.10.2017 20:16+1Забавно, что на самом-то деле это разница между TUI и GUI.
То есть когда я работал в каким-нибудь седом Turbo Pascal'е, то для меня не предоставляло проблемы нажать «не глядя» что-нибудь типа "<Ctrl+F7> x <Ctrl+F7> y <Ctrl+F8> <Ctrl+F9>" — всё это «не глядя», после чего я мог повернуться и что-то написать на листочке, пока комп всё это будет проделывать (у нас жётских дисков в компьютерном классе не было, а при работе с дискетки одно окно могло окрываться секунд 5). И это не вызывало ощущения «ужасающих тормозов»: думаю-то я всё равно не так быстро, так что после того, как я подал пару десятков команд могу и подумать над чем-нибудь ещё.
А вот в Clion гораздо меньшие тормоза — раздражают ужасно. Потому что я не могу «забросить» кучку команд и глотнуть кофе. Я должен за этим монстром приcматривать… и подавать команды когда он будет готов. Возникает вопрос: кто для кого работает — я для компьютера или компьютер для меня?
На машинке за $10'000 примерно, впрочем, тормозов почти нет и можно работать почти как в Turbo Pascal'е… потому что CLion успевает отреагировать на всё между двумя нажатиями клавиш… но есть ощущение какой-то неадкватности: неужели же вся эта моща нужна только, чтобы компенсировать тот факт, что мы используем GUI?
Обидно как-то…vintage
14.10.2017 03:48Нет, тут разница скорее между однопоточностью и многопоточностью. То, что в однопоточной программе получается автоматически, в многопоточной (гуй — это почти всегда несколько потоков) требует намеренной реализации.
khim
14.10.2017 05:43Это уже детали реализации. TUI тоже может запускать фоновые процессы, общаться с демонами и прочая, прочая, прочая. В конце-концов Vi, как бы, родился во вполне себе многозадачной системе.
А вот то, что это свойство в GUI реализовано намерено — тут вы правы на 100%. При работе с многими программами в этом даже есть какой-то смысл — действительно, не должна же моя среда тормозить из-за того, что в каком-то там браузере в фоне дизайнер навороты, грузящие одно из ядер на 100%, сделал… но почему эта беда должна наблюдаться в рамках одного процесса — мне решительно непонятно.
saboteur_kiev
13.10.2017 20:12Особенно подпишусь под надежностью.
Для администрирования, когда нужно быстро подправить какую-то опцию, учитывая возможности vi/vim в навигации по тексту, это особенно прекрасно в случае медленного коннекта. Например с мобильного телефона за пределами обитаемых мест.mdErrDX5341
13.10.2017 20:21в vim'e прекрасно то что если построить команду, то можно не запариваться что отобразится на экране секунд через 10, так как уверен что все Ок, но самое главное что это через какое то время доходит до автоматизма.
Beholder
12.10.2017 21:41Да вы знаете, мы и в IDEA прекрасно пользуемся клавиатурой, там масса шорткатов. Есть даже режимы Find action и Search everywhere с клавиатуры — описывать не буду, посмотрите сами. Мышь используется по минимуму. Почти никогда не выделяю мышью текст — для этого есть стрелки и другие кнопки навигации с модификторами и Extend selection (Ctrl+W), Shrink selection (Ctrl+Shift+W).
Поклонники vim'а запоминили только, похоже, как выглядели IDE лет 20 назад.mdErrDX5341
12.10.2017 22:04Оно там тоже все есть)))
Разница между Vim и IDE…
Vim изначально рассчитан на горячие клавиши и построение команд, по этому с ходу тяжело научится этим пользоваться…
IDE позволяет постепенно уходить от мышки, меню к неудобным горячим клавишам, которые в команды не строятся.
В виме ведется работа с буферами, не важно что в них отображается, главное что они ведут себя одинаково.
В IDE каждое окно имеет свой интерфейс взаимодействия.
В виме я могу расположить информацию как угодно за счет буферов и вкладок(не только файлы) и перемещатся одними и теми же хоткеями.
В IDE я толком не могу разделить даже файлы в разном виде(горизонтально, вертикально, по 3, по 4, спрятать скрыть) конфигурации, не говоря уже о приятном интуитивном перемещении по ним.
Symphel
13.10.2017 01:52Я не отрицаю, что в IDE можно работать без мыши. Но это не настолько удобно. И шорткаты в разных IDE разные, особенно Visual Studio от других отличается.
Gordio
13.10.2017 05:26Не стоит тратить время. Они просто не понимают о чем Вы. Им нравится "не пробовал но осуждаю" и проходить vimtutor не будут.
Я им так скажу: "10 пальцевый слепой набор. VIM — руки всегда на месте, IDE — как минимум руки скачут к стрелочным кнопкам и/или мыше."
P.S. С условием что Esc на Caps Lock.zagayevskiy
13.10.2017 11:50-1Ещё раз — зачем он нужен программисту, ваш десятипальцевый слепой набор? Ну добились вы 500 знаков в минуту, ок. И что? Я за это же время нажал 5 клавиш, а кода у меня получилось больше. В программировании набивка кода — это вообще не главное.
poxvuibr Автор
13.10.2017 11:53Ещё раз — зачем он нужен программисту, ваш десятипальцевый слепой набор?
Для того, чтобы не переводить глаза на клавиатуру, когда он работает с кодом и для того, чтобы спокойно переписываться с заказчиком в мессенджерах.
zagayevskiy
13.10.2017 13:17По-вашему, существует два вида печати — ваш метод и "уткнулся в клавиатуру, ничего не вижу, страдаю, набираю в час по чайной ложке"?
И зачем программисту вообще переписываться с заказчиком, это работа аналитика и менеджера.poxvuibr Автор
13.10.2017 13:35По-вашему, существует два вида печати — ваш метод и "уткнулся в клавиатуру, ничего не вижу, страдаю, набираю в час по чайной ложке"?
Совершенно непонятно, откуда вы сделали такой вывод. Я был бы благодарен за цитату. Мы тут обсуждаем полезность для программиста слепого набора на клавиатуре. Слепой набор это когда программист не смотрит на клавиатуру, когда печатает. Когда программист смотрит на клавиатуру — он немножко теряет контекст. Чем меньше он отвлекается, тем проще ему работать.
И зачем программисту вообще переписываться с заказчиком, это работа аналитика и менеджера.
Значит будет переписываться с аналитиком и менеджером, суть от этого меняется не сильно.
zagayevskiy
13.10.2017 14:38Ну из вашего же комментария следует, что все, кто не владеет десятипальцевым слепым методом, страдают и не могут даже переписку вести нормально.
Кто вам сказал, что теряется контекст при взгляде на клавиатуру? Это ваши домыслы. Программист может смотреть вообще в сторону, не на код, а в окно и не терять контекст. Если для вас контекст — это три строчки кода, у меня плохие новости.
poxvuibr Автор
13.10.2017 15:08Ну из вашего же комментария следует, что все, кто не владеет десятипальцевым слепым методом, страдают и не могут даже переписку вести нормально.
Из моего комментария следует, что всем, кто владеет десятипальцевым слепым методом переписку вести удобнее, чем тем, кто не владеет.
Кто вам сказал, что теряется контекст при взгляде на клавиатуру? Это ваши домыслы.
Посмотрел на клавиатуру — потерял фокус на месте, где курсор. Когда возвращаешь взгляд надо искать курсор. Когда привык это практически не заметно, но на самом деле это и есть постоянное переключение контекста. Удобно, когда его не происходит.
zagayevskiy
13.10.2017 15:11Домыслы, субъективизм, проецирование личного опыта на других.
Всё, я в этой теме больше не отвечаю, сколько раз зарекался вступать в холивары с фаниатиками.poxvuibr Автор
13.10.2017 15:28Домыслы, субъективизм, проецирование личного опыта на других.
Я хотел бы отметить, что это не только мои личные домыслы, а опыт большого количества людей. Кстати, вы умеете печатать вслепую? У вас есть такой опыт?
Всё, я в этой теме больше не отвечаю, сколько раз зарекался вступать в холивары с фаниатиками.
Вы приписали мне слова, которых я не говорил, а потом обозвали фанатиком. Неудивительно, что вам сложно общаться с людьми.
mayorovp
13.10.2017 15:27Из моего комментария следует, что всем, кто владеет десятипальцевым слепым методом переписку вести удобнее, чем тем, кто не владеет.
Нет, из него следует что всем, кто владеет слепым методом переписку вести удобнее, чем тем, кто не владеет.
Превосходство десятипальцевого метода над остальными вы не доказали.
Да и, честно говоря, потеря контекста тоже у вас вышла какая-то натянутая. Программист же не просто так набирает что-то, а ожидает после набора получить вполне конкретный результат. И в этот ожидаемый результат входит в том числе ожидаемое положение курсора.
poxvuibr Автор
13.10.2017 15:31Нет, из него следует что всем, кто владеет слепым методом переписку вести удобнее, чем тем, кто не владеет.
А я что написал?
Да и, честно говоря, потеря контекста тоже у вас вышла какая-то натянутая.
Вы умеете печатать не глядя на клавиатуру?
mayorovp
13.10.2017 15:46Вы умеете печатать не глядя на клавиатуру?
Я владею обоими методами слепой печати и не наблюдаю ни разницы в скорости набора, ни потерь контекста. При желании могу писать комментарии смотря в потолок, но тут уже скорость страдает.
poxvuibr Автор
13.10.2017 15:56Я владею обоими методами слепой печати и не наблюдаю ни разницы в скорости набора, ни потерь контекста.
Меня вот, пока не научился не глядя на клавиатуру печатать, перенос фокуса с экрана на клавиатуру и обратно очень раздражал. И такие ощущения у достаточно большого количества народу. Надо опрос на хабре устроить :)
mayorovp
13.10.2017 16:12Меня вот, пока не научился не глядя на клавиатуру печатать, перенос фокуса с экрана на клавиатуру и обратно очень раздражал.
Меня тоже, и именно поэтому я сначала выучился печатать не глядя на экран. Это позволило увеличить скорость печати, в результате чего руки стали постепенно "запоминать" клавиатуру. А там уже получилось перестать на нее смотреть :-)
Но одновременно с этим меня перестал раздражать перевод фокуса между экраном и клавиатурой.
khim
13.10.2017 17:43Это такой способ «застыдить»? Я вот не скажу — умею ли я печатать, не глядя на клавитуру, но таки тот факт, что на клавиатуре, на которой я набираю это сообщение нет русских букв меня не напрягает… И нет — раскладка у меня не ЯВЕРТЫ…
poxvuibr Автор
13.10.2017 18:05Это такой способ «застыдить»?
Нет, конечно. Интересно с точки зрения статистики.
Borz
14.10.2017 10:46Я без десятипальцевого не смотрю на клавиатуру и пишу почти без ошибок — ЧЯДНТ?
poxvuibr Автор
14.10.2017 10:51+1Вы всё делаете так. А с моей стороны — проблема с терминологией. Я говорил про способность печатать не глядя на клавиатуру. Каким методом — неважно. То есть, по моему мнению, владеть именно десятипальцевым методом не обязательно.
DrPass
12.10.2017 10:41+4А в виме нужно просто нажать e
Объясните мне, как не_пользователю_vim, как тогда в этом случае там набирать букву «е»? Или подразумевается, что для того, чтобы переместить курсор к концу слова, надо сначала перейти из режима набора текста в какой-нибудь режим навигации, а уже потом нажать е?ZyXI
12.10.2017 10:50+1Именно так: из режима «вставки» в «нормальный» режим. Хотя у меня для таких мелких передвижений в режиме набора используются сочетания вроде
<C-b>/<C-f>(назад/вперёд на символ),,b/,w(назад/вперёд на слово),,B/,W(назад/вперёд на СЛОВО (ограниченное пробелами: первый вариант переносит наfв(foo|, второй — на()). (Я имею ввиду, не выходя из режима вставки.)
И стрелки с
<C-вроде тоже поддерживаются, но до них далеко тянуться и с высокой вероятностью в терминале что?то из стрелок с модификаторами работать не будет.DrPass
12.10.2017 10:54Спасибо, понятно. Ну тогда особых преимуществ я для себя и не вижу. Разве что полностью ломать парадигму набора текста, вместо «пишешь и правишь по ходу» на «пишешь всё, а потом правишь всё».
Делать под себя набор клавиатурных макросов может быть и удобно, но лишь до тех пор, пока не окажешься на другом компьютере, где их нет.
acmnu
12.10.2017 11:02+2vim это тот случай когда надо попробовать, также как надо обязательно попробовать хорошую IDE. Составить впечатление по постам в интернетах не получится.
poxvuibr Автор
12.10.2017 11:05Трагизм ситуации в том, что на первом этапе работать будет очень неудобно и всё будет делаться очень медленно. В случае с хорошей IDE, это обычно не так.
acmnu
12.10.2017 11:12+1Ну не знаю. В IDE тоже свой ад связанный с обилием менюшек, которые по началу оказываются совсем не там где ты их ожидаешь.
DrPass
12.10.2017 11:17+1Может быть, это дело привычки. Меня неприятно «радовали» всякие экзотические штуки вроде Atom, но если брать популярные IDE, вроде IDEA, Eclipse или даже Visual Studio, они все следуют устоявшейся схеме интерфейса, и все нужные функции оказывались там, где я их и искал.
Как по мне, IDE предоставляют две незаменимые фичи, отсутствие которых куда сильнее бьёт по продуктивности, чем +5% к скорости правки текста. Это навигация по коду а-ля «перейти к определению метода/класса» и рефакторинг.acmnu
12.10.2017 11:47«перейти к определению метода/класса»
Это есть и в vim, хотя да в IDE сделано лучше из-за того, что IDE держит в код в памяти в разных представлениях.
рефакторинг.
Ну да, тут явно лучше. Но опять таки какой смысл сравнивать ежа с ужом. vim это про редактирование кода, отсюда и популярность vim плагинов в IDE
Hardcoin
12.10.2017 14:28+1В вим этого нет. Найти метод по названию можно, но если их десяток в разных классах? IDE анализирует код и знает, какого класса текущий объект. Для вим такого плагина не видел.
domix32
12.10.2017 14:51К виму вроде тоже можно прикрутить анализаторы и менять все вхождения методов/членов классов/прочих code entity. Даже для какого-нибудь Си++ думаю что-то найдется.
acmnu
12.10.2017 15:26В вим этого нет. Найти метод по названию можно, но если их десяток в разных классах?
Нужен плагин для соответствующего языка. Например для Python и Go все это есть: подсказка будет учитывать экземпляром какого класса является эта переменная. По моим ощущениям качество подсказки для Python такое же как в Pycharm.
А вот автоформатирование Python, на мой взгляд в Vim слабее чем в Pycharm или Spacemacs.
zagayevskiy
12.10.2017 20:09А что, мелкий рефакторинг типа "переименовать метод" уже перестал быть редактированием кода?
Alozar
12.10.2017 11:21-1Но с IDE в отличие от vim по началу не возникает разрыва шаблона с написанием текста.
Банальный Hello World получится написать на раз-два, а потом уже по мере необходимости вникать во все менюшки.
С vim же, насколько я понял, получается ситуация, что нужно изучить толмут по правилам работы с ним, чтобы можно было нормально работать, а потом уже человек сможет что-то сделать. Но возникает вполне закономерный вопрос, а зачем ему это, если под рукой есть текстовые редакторы и IDE с «классическим» алгоритмом печати текста.acmnu
12.10.2017 11:41Туториал изучается примерно за полчаса. Для начала работы надо запомнить примерно десять действий. Потом начинается процесс адаптации: желательно внимательно прислушиваться к совим дейтвиям и прикидывать а нельзя ли вот это действие, которая делаю постоянно сделать быстрее. И ответ на этот вопрос будет почти наверняка "да, в vim есть уже такая кнопка или команда".
symbix
12.10.2017 15:36В IDE точно так же надо привыкать к хоткеям (или настраивать их под себя). Елозить по менюшкам-тулбаром мышкой — это несерьезно, разве что поначалу для ознакомления. У меня в IDEA все тулбары отключены к чертям, все делаю хоткеями. Ну и IdeaVIM-плагин стоит, конечно :)
YemSalat
12.10.2017 18:30+2Пользователи вима ценят возможность проводить манипуляции с курсором и текстом без необходимости держать при этом зажатыми клавиши-модификаторы
… сочетания вроде <C-b>/<C-f> (назад/вперёд на символ), ,b/,w (назад/вперёд на слово), ,B/,W ..
Shift то все-равно придется зажимать для заглавных букв?poxvuibr Автор
12.10.2017 18:32Shift то все-равно придется зажимать для заглавных букв?
Придётся. Модификаторы используются в виме и другими способами. Общее правило — чем короче действие, тем больше смысла использовать модификатор, а не режим.
ZyXI
12.10.2017 23:11Да, но здесь?то модификатор всего один! Впрочем, в терминале
<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’ом.
poxvuibr Автор
12.10.2017 10:53Да, именно так. Кроме того, если вы переместили курсор к концу слова для того, чтобы что-то написать сразу после этого слова — нужно после клавиши e нажать клавишу a для перехода в режим введения текста.
Germanets
12.10.2017 11:10+1Вот к примеру у меня(да и у многих знакомых разработчиков) есть такая привычка — сначала набираем две скобки(или кавычки, или любые другие парные символы), потом нажимаем стрелку влево и набираем то, что в скобках должно быть. То же самое в vim'е можно сделать только переключившись 2 раза из режима в режим и никак иначе?
Mutineer
12.10.2017 11:17+1нет, просто vim сам закрывающую скобку вставит сразу после открывающей, а курсор оставит между ними. По крайней мере emacs так делает, vim должен уметь так же
ozonar
12.10.2017 12:53Так и IDE делают, смысл в том, что определенная группа людей отключают этот функционал, и набирают кавычки вручную
Mutineer
12.10.2017 12:56Люди делают вручную то же самое, что IDE может сделать автоматически? Зачем им тогда IDE?
Neikist
12.10.2017 13:08У меня IDE например к сожалению так не умеет в основном языке, и если пишу на чем то другом — руки на автомате символы зеркалят:"", (),{},[], и т.д. Тем более что они рядом.
Fen1kz
12.10.2017 13:41+2Я например отключаю этот функционал, когда правлю код — очень часто приходится дописывать одну скобку, которую IDE/vim услужливо дополняют, несмотря на наличие скобки далее.
Вопрос был — как сделать так в vim'е, а вы развели демагогию =(Mutineer
12.10.2017 14:22-3я на вопрос ответил, нет?
Fen1kz
12.10.2017 16:56Вопрос: «как напечатать 2 скобки, перейти внутрь этих скобок и писать там?»
Ваши ответы: «Он сам ставит закрывающую» / «зачем людям IDE?»
Как я и habrahabr.ru/post/339908/#comment_10468622 уже объяснили: «сам ставит» — вообще не выход из ситуацииsshade
12.10.2017 21:52Войти в режим редактирования и напечатать две скобки, нажать стрелку влево, печатать между скобок. Либо можно сделать так, чтобы вторая скобка сама допечатывалась. В режиме редактирования vim будет похож на большинство обычных редакторов. Т.е. печатаете, стираете, двигаетесь по тексту как обычно. А вот в «нормальном» режиме уже можно и быструю навигацию, всякие действия, выделения и прочее-прочее-прочее и того, за что любят vim те, кто им пользуется.
niya3
12.10.2017 22:09- vim из коробки не ставит закрывающих скобок.
- можно повесить любое действие на любое сочетание клавиш в любом режиме. Например, эту задачу можно решить так: если в режиме ввода нажать два раза
\, то вставить пару скобок, перейти в командный режим, вместиться на символ влево, вернуться в режим ввода. Комментарий я писал дольше, чем команду.
:inoremap \\ ()^[iZyXI
12.10.2017 23:29Для такого иногда можно посоветовать всё же дополнение: с таким простым автозакрытием скобок возникают проблемы с undo (вставка скобок создаёт новый узел в дереве undo) и точкой. Лично мне первое не мешает, но вот второе сильно раздражает, хотя дополнение я так и не поставил: они имеют свойство ломаться с обновлениями Vim и не уверен, что сейчас вообще есть с работающей точкой (т.к. следил за vim-dev и иногда ловил сообщения «этот трюк сломался», но соответствующие ветки потом не особо читал).
Сам использую
,s(круглые скобки) /,h([]) /,f({}) /,u(<>).
PS: Не нужно говорить про «любое сочетание клавиш» и «в любом режиме»: я знаю очень много контрпримеров, вот два самых простых: на первое достаточно просто
<C-S-x>, на второе: вы знаете, что у YouCompleteMe есть «принципиально нерешаемая» проблема с неработающим<C-u>?niya3
12.10.2017 23:36Для такого иногда можно посоветовать всё же дополнение
Да, дополнение лучше велосипедов. Команда только для демонстрации лёгкой расширяемости vim, это ни в коем случае не эталонное решение.
PS: Не нужно говорить
Спасибо.
Errata: "большинство сочетаний клавиш в различных режимах" =)
вы знаете, что у YouCompleteMe
Нет, из дополнений у меня только slime.
foal
12.10.2017 16:09+1Ну современные IDE, не только ставят скобку (кавычку) автоматом, но если человк машинально после этого ставит её ещё раз, то они просто двигают курсор на позицию дольше. То есть вместо 3х кавычек получаются две и курсор за ними.
ozonar
13.10.2017 06:40Самая большая проблема этого подхода — в недетерменированности.
Я могу написать Кавычку перед строкой:
string"
и вторая не появится, а в остальных случаях появится. Или посередите строки я хочу сделать разрыв и вставить туда переменную, количество кавычек вставленных IDE я иногда предсказать не могу.
Поэтому мне кроме контекста надо всегда помнить, в каких случаях кавычка ставится, а в каких нет, и тратить время на борьбу с IDE. Мне лень, поэтому я отключаю эту шелуху. Скорость набора ну уж точно не падает.
Desprit
12.10.2017 11:18+1Нужен плагин на автокомплит, например, `auto-pairs`. Набираешь скобку/кавычку и он сразу ставит закрывающую, а курсор оказывается между ними. Плюс, есть дополнительные возможности навигации.
vintage
12.10.2017 13:49+9Это страшно бесит, когда ты не пишешь новый код, а редактируешь существующий. Тебе надо поставить открывающую тут, а закрывающую там, а вместо этого ты занимаешься удалением невпопад добавленных закрывающих скобочек, кавычек и прочей ерунды. "Особо умные" редакторы ещё и удаляют эти символы парами, что особенно доставляет.
mayorovp
12.10.2017 13:59Нее, "особо умные" редакторы самостоятельно находят пару для скобок и кавычек и ставят их в случайном месте :-)
Desprit
12.10.2017 14:28+1Да, случается. Если становится слишком много этих итераций, то можно забиндить `Toggle Autopairs` куда-нибудь на удобное сочетание, и переключаться между режимами по необходимости.
vintage
12.10.2017 17:14-1Неужели экономия одного нажатия рядом стоящей клавиши стоит введения ещё одного "режима"? Это совершенно не то место, где нужно оптимизировать. Вот закрывающие теги в HTML — это да, экономия. Хотя, куда лучше вообще отказ от HTML если не на уровне исходных кодов, то уж на уровне представления при редактировании — точно.
Sayonji
12.10.2017 23:02Прошу прощения, случайно минусанул, хотел поставить плюс за +1 режим в мозгу vs ставить вторую кавычку руками.
Desprit
16.10.2017 10:56Это не одно нажатие, а два. Нужно сначала нужно поставить обе скобки/кавычки/…, а уже потом сделать «шаг» назад, чтобы начать писать что-то внутри :)
aelaa
12.10.2017 11:20+1То же самое можно сделать подключив плагин и нажав одну открывающую скобку. Вторая добавится сама, и курсор встанет между ними.
(кстати не только в виме)
Xenos_rus
12.10.2017 11:32При корректно работающей эмуляции терминала (если клавиши со стрелками перемещают курсор) в vim (или даже vi) не требуется никаких дополнительных действий: i (или a), две скобки, клавиша влево и печатаем то, что в скобках.
questor
12.10.2017 22:49Вы второй человек, кто упомянул слово 'стрелка влево', когда вся статья была о том, что стрелки моветон. Кроме того, в комментах звучала мысль, что контрол и шрифт — зло. И тут же были сочетания клавиш с заглавными буквами. Я печатаю вслепую на эргономичной клавиатуре, я понимаю, что такое до стрелок тянуться. Но вы мне весь шаблон рвете… То стрелки зло, то тут же советы со стрелками.
tmnhy
12.10.2017 12:47есть такая привычка — сначала набираем две скобки(или кавычки, или любые другие парные символы), потом нажимаем стрелку влево
Погодите, вы чем пользуетесь в 2017 году? Разве не во всех редактора кода уже давно по дефолту, что при наборе парного символа (левой скобки или апострофа) правый добавляется автоматом, а курсор остаётся между ними?ozonar
12.10.2017 12:55Если повезёт с разработчиками, есть возможность такую функцию отключить.
ainoneko
16.10.2017 07:19В IDE бывает, что можно не отключать: при наборе, например кавычки, вторая ставится, но становится выделенной, так что если сразу набрать вторую, их всё равно будет две, а не три.
mayorovp
16.10.2017 08:42Да проблема-то не в этом. Проблема в том, что иногда нужно обернуть в кавычки или скобки уже написанный блок текста — и тут-то автоматическое закрытие показывает себя во всей "красе".
Пример — гифка в комментарии ниже.
deril
12.10.2017 16:33+2Если в vim-е вы в режиме редактирования (а Вы в нём, если набираете скобку) то последовательность такая же. Пишете зеркальные скобки, потом нажимаете стрелку влево и набираете то, что в скобках должно быть.
kost
12.10.2017 22:13Иногда в режиме вставки работают и стрелки на клавиатуре.
Если нет — 2 переключения: Esc, i
easty
12.10.2017 20:28Всегда приходится неистово нажимать esc до пиканья в консоли, чтобы случайно не оказать не в том режима и не начала происходить неведомая хрень, что придется вырубать питание))))
Desprit
12.10.2017 10:43-2Печально, но если задать этот вопрос среднестатистическому гуру вим-гольфа — он его просто не поймёт.
Любой, кто постоянно пользуется вимом и осилил хотя бы базовый набор функций, легко ответит вам на этот вопрос, не нужно утрировать.poxvuibr Автор
12.10.2017 10:57Конечно ответит. Он и отвечает, но, насколько я понимаю он сразу отвечает на вопрос — как пользоваться режимами. И у того, кто спрашивал, создаётся впечатление, что режимы это такой пережиток прошлого, но ради других достоинств вима люди терпят.
Alozar
12.10.2017 11:12+1Ваша фраза очень смахивает на вим-фанатизм по типу религиозного.
Desprit
12.10.2017 11:25Ваш ник, вон, тоже кое на что смахивает, и что? При чем здесь фанатизм, тем более, религиозный? Любой, кто пользуется чем угодно длительное время на приемлемом уровне, способен дать ответ, в чем для него заключаются преимущества.
Буквально в прошлой холиварной статье на хабре писали и про удобную навигацию по тексту, и про возможности кастомизации плагинами, коих сотни, и про быструю развертку своего конфига на удаленном сервере. Режимы просто дают возможности, сами по себе они сомнительные киллер-фичи.poxvuibr Автор
12.10.2017 11:55Режимы просто дают возможности, сами по себе они сомнительные киллер-фичи.
Возможности, которые дают режимы, можно предоставить и без них. Но нередко люди хотят именно модального интерфейса.
Alozar
12.10.2017 14:55удобную навигацию по тексту, и про возможности кастомизации плагинами, коих сотни, и про быструю развертку своего конфига на удаленном сервере
Удобство понятие относительное, меня например устраивает вариант ctrl+стрелка.
Остальные «фишки» вполне себе реализуются с использованием классического сейчас интерфейса.
Так какой же ответ, который будет знать любой, кто осилил базовый набор функций?Desprit
16.10.2017 11:08Именно тот ответ, который я написал.
Перемещение по тексту — это о том, что я могу не брать в руки мышь. В любое место на экране я попадаю практически мгновенно либо через стандартные команды, либо через easymotion плагин когда нужное место где-то далеко внутри строки. Если вам нравится нажимать ctrl-стрелку, чтобы перейти строк на 20 вниз и в сторону, ради бога, только о какой оптимизации мы вообще тогда говорим?
Кастимиированная версия вима переезжает на удаленный сервер ровно за то время, которое требуется, чтобы сделать clone из моего репозитория.
Плюс интеграция с tmux.
RikoSaGe
12.10.2017 10:49+1Код в Vim писать это дичь, конечно. А в качестве штатного консольного редактора — очень удобен. Всяко лучше всяких nano, например. Ну и при удаленном подключении удобен, например.
mayorovp
12.10.2017 10:50+5А что не так с nano при удаленном подключении?
Xenos_rus
12.10.2017 11:48Бывают проблемы, из собственной практики с серверами со встроенными средствами удалённого доступа через консоль по внутренней шине. Типа RSC и ILOM для Sun/Oracle или HMC для IBM. Тогда обычно помогает установить эмуляцию в vt100, чтобы ввод/вывод не ломался. Но это явно не про ежедневное написание кода, а чтобы конфиги поправить :)
lpwaterhouse
12.10.2017 12:02Ну если прям придираться, то иногда его не удается подружить с mc. Нажимаешь ctrl + o, чтобы засейвить файл, а после этого, в зависимости от системы, все либо идет по плану и файл сохраняется, либо вылетает на панельное меню mc. При следующем нажатии ctrl + o уже не видно сам редактор, но хоткеи nano все еще работают и можно даже засейвиться по ctrl + x. Т.е. не то чтобы прям проблема, но бесит.
mdErrDX5341
12.10.2017 12:22Очень даже хорошо пишется код в Vim, уже лет 10 им пользуюсь, 6 из них пишу код.
Надо просто понимать что Vim это продвинутый редактор с удобным интерфесом за счет режимов и кучей плагинов.
Но если нужно изучить код, то конечно лучше IDE
AstarothAst
12.10.2017 11:04+3Режимы не фатальный недостаток, а киллер фича, но в чем конкретно она заключается нам не скажут.
poxvuibr Автор
12.10.2017 11:12Сначала в статье был длинный кусок на эту тему, но в конце концов я понял, что для нормального объяснения нужно 3 таких статьи с прикреплёнными видеороликами. Поэтому я оставил ооооочень маленький кусок про необходимость переключаться между режимами с помощью клавиш i и эскейп, а также про перемещение курсора без клавиш-модификаторов в режиме вставки. Придумать, как хорошо продемонстрировать, что такое режимы, не смещая при этом фокуса статьи я не смог :(
AstarothAst
12.10.2017 11:22+4Но тогда, получается, статья лишилась смысла. Кто знает, что такое режимы и чем они хороши — тем не нужна статья, а кто не знает — тот так и останется в неведении.
poxvuibr Автор
12.10.2017 11:29Но тогда, получается, статья лишилась смысла.
Статья писалась для того, чтобы те, кто хочет выяснить чем хорош вим — выясняли чем хороши режимы, а не пытались понять ради чего пользователи их терпят.
Alozar
12.10.2017 11:36+1При этом получилось, что из статьи мы лишь узнали, что вместо привычного Ctrl+вправо нужно делать два перехода между режимами и нажимать нелогичные на первый взгляд клавиши. Мне например, как человеку, который не работал с вимом, осталось неясно, почему второе круче и лучше первого.
poxvuibr Автор
12.10.2017 12:51Я хотел, чтобы из статьи было понятно, что причина использовать вим — режимы. Я лично знаю несколько человек, которые узнали что такое режимы, знают, как ими пользоваться и при этом считают их досадным пережитком старины и продолжают попытки выяснить в чём всё-таки настоящая сила vim.
Из моей статьи нельзя понять, что такое режимы и как ими пользоваться. Но можно понять, что, если вы разобрались что такое режимы и они вам не понравились, то дальше причины, по которым люди пользуются вимом, можно не искать.
Synoptic
12.10.2017 14:13+1В 2017 году на хабре втирают, что режимы — это хорошо. Куда катится мир.
programming-lang.com/ru/comp_programming/raskin/0/j38.htmlpoxvuibr Автор
12.10.2017 15:01+2Режимы это нехорошо только тогда, когда пользователь путает, в каком режиме находится в данный момент. Например — плохо переключать язык по одному сочетанию клавишь. С модальным интерфейсом вима такой проблемы нет.
Synoptic
14.10.2017 14:33Осильте классика по ссылке. С любым модальным режимом такая проблема есть.
niya3
14.10.2017 16:35Нет с вимом таких проблем. Текущий режим считывается одним взглядом в левый нижний угол.
vintage
14.10.2017 18:16И про это там тоже есть. Можете поискать по "не находится в локусе внимания".
poxvuibr Автор
14.10.2017 20:21В каком режиме ты находишься как правило легко понять по форме курсора, который как раз находится в этом самом локусе. Проблем с пониманием в каком режиме сейчас находится пользователь в виме нет.
gonzazoid
15.10.2017 02:17тут ведь какое дело — у тех кто пользуется — проблем нет, потому и пользуются. У тех у кого есть проблемы с вимом — они им не пользуются. Это тоже очевидно. Непонятно почему вторые первым пытаются что то доказать. (когда первые вторым доказывают — досадно). Сам вимер если что.
AstarothAst
12.10.2017 14:04-1Тем, кто хотел узнать, чем хорош vim и так никто не мешал это сделать, и статья не нужна.
saboteur_kiev
12.10.2017 13:42+1Очень странно читать о киллерфичах vi от того, кто сам им активно не пользуется и даже удивляется, как кто-то им может пользоваться.
Я видел людей, которые делают офигенные вещи через vi/vim, через notepad++, через встроенный редактор в FAR. У каждого свои «механически задроченные комбинации», за которыми посторонний не всегда успевает уследить глазом. Но они стали такими не сразу, а после того, как человек близко познакомился с функционалом.
То есть вопрос удобства не всегда должен рассматриваться как «мгновенное улучшение».
Переходить с привычного инструмента на совершенно новый ради одной или двух-трех киллерфич — не всегда работает.
В большинстве случаев гораздо проще найти аналог такой фичи в инструментах, которые ты уже используешь — о чем и идут постоянные холиворы.poxvuibr Автор
12.10.2017 14:17+1Очень странно читать о киллерфичах vi от того, кто сам им активно не пользуется и даже удивляется, как кто-то им может пользоваться.
Вы, совершенно случайно, не про меня ли? Я использую вим на постоянной основе и знаю о чём говорю, если что.
FirExpl
12.10.2017 11:18Ну, то ради чего лично я пытался использовать VIM-плагин для IDE — навигация по коду не используя мышь и клавишы стрелок. ИМХО, вот этим предложением можно было заменить большую часть статьи.
tyomitch
12.10.2017 18:54+2Разрешите полюбопытствовать: чем было вызвано желание навигировать по коду, не используя мышь и клавиши стрелок?
BelBES
12.10.2017 23:13Ну вот лично мне в какой-то момент мышка стала тупо мешаться — лишний контроллер, на который иногда приходится отвлекаться… в итоге перешел на Emacs (до этого программировал в VS, Eclipse, QT Creator) и теперь бОльшую часть времени работы за компьютером я вообще не задумываюсь над тем, что и как делать — все делается при помощи хоткеев, которые пальцы сами помнят) И сейчас единственное, чего не хватает в OS для полного счастья — это интеграции своего emacs-конфига на уровне OS, чтобы всякие браузеры и мессенджеры с ними умели работать)
FirExpl
13.10.2017 08:11Чисто вопрос удобства. Работаю на МакПро, блок стрелок на нём ущербный, каждая ситуация, когда надо подвинуть курсор на несколько символов вправо/влево/вверх/вниз вызывает боль, т.к. нужно сместить правую руку на эти маленькие стрелки, а потом вернуть обратно в правильную позицию. В принципе Vim-плагин решил бы эту проблему, но лень и нежелание переучиваться в итоге победили.
FirExpl
16.10.2017 08:38+1Впервые за долгое время мне стало интересно, за что мой комментарий получил минусы.
Попросили описать личный опыт, почему мне хотелось не пользоваться мышью(тачпадом)/стрелками, описал, получил минусы, причём даже в карму судя по всему) Причём, что характерно, никаких гневных комментариев разъясняющих в чём я не прав и где задел чьи-то чувста, просто тупо минусы.
acmnu
12.10.2017 11:34+1Дело в том что объяснять это действительно тяжело. В первую очередь из-за того, что сторонние наблюдатели считают режим вставки основным, вимеры считают таковы командный режим (он не зря здесь называется нормальным).
Вот какие фокусы доступны в нормальном режиме:
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 — по словам
mikhailian
12.10.2017 14:12+1Отлично. Просто отлично. В двух словах вы объяснили, почему vim так притягивает к себе программистов. Ведь программистам редко приходится что-то писать — обычно мы редактируем уже существующий код.
Примерно в том же стиле написан и культовый комментарий на тему vim https://stackoverflow.com/a/1220118/661236 Если вы его ещё не читали, то стоит прочитать.
ploop
12.10.2017 20:40Если вы его ещё не читали, то стоит прочитать.
Спасибо.
И комментарий к ответу "… вы, вероятно, написали его в vim примерно за 10 нажатий клавиш" :)
hdfan2
12.10.2017 14:55+5У меня есть язык программирование в среде для написания программ, чтобы я мог программировать, пока я программирую.
johnnymmc
12.10.2017 15:47+2Отличная статья, и комменты нескучные. Раньше я думал, что vim — это крутая магическая штука, к которой лучшие умы планеты пишут плагины, затыкающие глубоко за пояс любую IDE и до которой просто надо дорасти (а то честно пройдя какой-то интерактивный туториал я так и не понял зачем мне все эти команды, когда я вбитые за 20 лет в «подкорку» нормальные комбинации с Ctrl нажимаю гораздо быстрее, чем буду всё это набирать). Теперь понял, что он мне нужен как жирафу водительские права. Значит для меня будет лучше посвятить время изучению Emacs. Или может даже углублённому изучению того же Sublime (он вроде тоже достаточно «hackable»). Хотя, чуть-чуть «насобачиться» в vim всё-равно наверно стоит хотябы потому, что только он есть практически везде.
acmnu
12.10.2017 16:08+1Ситуация с плагинами довольно нелепая. На этапе создания vimscript никто не подполагал, что на нем будут пытаться выразить чего-нибудь сложнее макросов. На деле вышло как вышло. Есть прослойка фанбоев, который рассказываютс про крутость эти плагинов, но их реальная крутость в одном: нативность для vim.
Лично я не пользуюсь плагинами, которые пытаются прератить vim в IDE. Если мне нужна IDE, то я беру Интелижжж и ставлю туда vim плагин.
ZyXI
12.10.2017 23:41Большие по объёму кода дополнения часто пишут на Python, lua и ruby; в основном первое.
acmnu
13.10.2017 09:55Ну это появилось в семерке, которой не так много лет ещё, поэтому реальных, хороших плагинов пока мало. Активно эту идею продвигает nvim: вот там больше возможностей для построения IDE на +nvim.
ZyXI
13.10.2017 10:17Vim-7.0 появился в 2004 (точнее, тогда появился первый commit в mercurial репозитории, а он содержит исходные коды начиная с 7.0, но не более ранние). Первый commit, позволяющий запуск powerline (которому нужен +python) — 7.0.112 — октябрь 2006.
А у Neovim есть API на основе msgpack для взаимодействия с внешними процессами, что позволяет писать на любом языке.
zloddey
12.10.2017 16:40-1Значит для меня будет лучше посвятить время изучению Emacs
Хаха, тоже так когда-то думал. Но руки сделали свой выбор сами. Главная киллер-фича vim для меня — руки меньше болят после целого дня работы с текстом (в сравнении с "традиционными" редакторами, IDE и тем же Emacs). Это эффект именно модального режима, благодаря которому все эти
Ctrl,Alt,Shiftприходится жать на порядок реже. Как итог, существенно меньше напрягаются кисти.MacIn
12.10.2017 16:43Простите, а о каком ЯП идет речь, что требует так много печатать?
zloddey
12.10.2017 16:48Русский язык, к примеру.
Впрочем, бывает, что в состоянии потока код прёт как бешеный. Но это не зависит от ЯП, только от степени понимания задачи и наличия времени для спокойного погружения в кодинг.
MacIn
12.10.2017 17:03Разумеется, но так, чтобы после целого дня работы с кодом руки болели — не представляю…
domix32
12.10.2017 17:24Я могу вспомнить только PHP и Perl где нужно жмакать неудобные @#$% постоянно, но vim вроде проблемы не решает даже в этом случае. Хотя может пэхапэшникам лучше живется на Dvorak-раскладках
zloddey
13.10.2017 11:18Не исключено, что тут влияет дополнительная нагрузка на кисти. Я в те годы активно барабанами занимался. В комментах ниже гитарист тоже на Emacs жалуется.
Ну и, опять же, физиология у всех разная. Кто-то более предрасположен к RSI, кто-то меньше. Возраст тоже влияет: чем старше пациент, тем больше шансов поиметь проблем со связками.
poxvuibr Автор
12.10.2017 16:51Хаха, тоже так когда-то думал. Но руки сделали свой выбор сами.
А evil-mode не пробовали?zloddey
12.10.2017 16:55Знаю про него, но так руки и не дошли. Привык уже к классическому vim.
poxvuibr Автор
12.10.2017 17:00Я попробовал — серьёзно размышляю отказаться от вима в пользу емакса.
acmnu
12.10.2017 18:26Лучше тогда spacemacs использовать
deril
12.10.2017 20:09Spacemacs – это emacs с набором плагинов, чтобы быть максимально удобным для любителей vim-подобного редактирования. Такой «Зверь-пак» можно сказать.
acmnu
12.10.2017 23:18Ну там не только пак, справедливости ради. У них там своя атмосфера со "слоями" и мегаконфигом для всего сразу. Кроме того они заботятся чтоб все сторонние плагины, которые они к себе берут, не дрались с evil модом (что сплошь и рядом в ванильном емакс). Поэтому его так вимеры и любят.
johnnymmc
12.10.2017 19:19Главная киллер-фича vim для меня — руки меньше болят после целого дня работы с текстом
У меня одно время тоже начали побаливать руки, когда много на встроенной клаве ноута фигачил, держа их на весу. Подключил классическую внешнюю клаву, кинул перед ней силиконовую подушку, на которой руки лежат практически неотрывно (и ни малейших проблем ни с какими комбинациями не испытывают) и всё прошло. Но возможно мне просто повезло с длинной пальцев (я бы с удовольствием добавил между цифрами и F-клавишами ещё один программируемый ряд полноразмерных кнопок и мне было бы не менее комфортно).
rkosolapov
13.10.2017 07:44Это индивидуальная особенность. Я более десяти лет работаю в emacs, каждый день, с руками всё хорошо.
Естественно, как любой нормальный емаксер, я control перемапил на caps lock, ну и клава должна быть не сильно плохая (сейчас у меня макбук, на декстопе когда сидел — была майкрософт натурал, потом майкрософт 4к).
rkosolapov
13.10.2017 07:41Саблайм гавно, емакс на несколько порядков круче.
Если есть возможность я бы сейчас смотрел на Atom/Visual Studio Code, мне кажется это очень перспективные вещи, возможно, лет через 20 даже emacs начнут догонять.
ZZahar
12.10.2017 11:07Вопрос, а чем так проблематично установить IDE и скачать vim плагин для этой IDE и радоваться жизни?
poxvuibr Автор
12.10.2017 11:20Совсем не проблематично. Но вопрос — зачем ставить vim плагин и портить им замечательную IDE останется открытым :)
ZZahar
12.10.2017 11:24+1А зачем ставить Vim? Ради режимов и быстрого редактирования текста. А зачем ставить Vim плагин в IDE? Ради режимов и быстрого редактирования текста.
Ваш Кэп.
P.S. Все лучше чем раскладка Visual Studio без Rider.poxvuibr Автор
12.10.2017 11:26А зачем ставить Vim плагин в IDE? Ради режимов и быстрого редактирования текста.
Совершенно согласен. Именно это я и хотел сказать :)
mdErrDX5341
12.10.2017 12:56Пробовал плагины, но все они далеки от работы с кодом в vim.
Скорее вопрос в привычки и расширяемости Vim в плане редактирования, управления буферами, переходами по файлам и т.д. и т.п.
Всю IDE перестроить не получится.
deril
12.10.2017 16:37Тогда в vim не нужно будет добавлять плагинов, в которых не разбираетесь. А так любимая IDE с плюшками + удобный инструмент работы с текстом.
Vorh
12.10.2017 11:15В любую среду разработки от JetBrains можно поставить плагин, который эмулирует VIm.
После его установки отпадает потребность в использование оригинального Vim для разработки.aelaa
12.10.2017 11:29Не отпадает. Прошёл путь RubyMine -> RubyMine + vimmode -> vim. Остался на последнем.
Использование режимов и возможность ввести команду не шевеля кистями распространяется не только на редактирование текста, но и на команды IDE. Есть сочетания типа Ctrl+Shift+Alt+T, после которых болят пальцы, и которые не всегда имеются на нужную команду. А в vim всё просто, одна клавиша — одна команда, другого способа её выполнить просто нет.Vorh
12.10.2017 14:40В IDE (мы же говорим о продуктах JetBrains?) почти все доступные команды можно переопределить в настройках на более удобные и тогда не придется нажимать на всякие Ctrl+Shift+Alt+T ( Что это сочетание вообще вызывает? У меня в Inellij Idea нечего не происходит и не исключено что я его уже изменил ))
aelaa
12.10.2017 14:54Ctrl+Shift+Alt+T — абстрактный пример самого пальцеломательного сочетания. Особенно когда вторая рука на мышке. Особенно когда ты левша)
Более удобные — да, но столь же семантичные? Например замапил git clone на Ctrl+Y и git push на Ctrl+U (потому что Ctrl+P занят чем-то ещё). И нужен тебе внезапно git rebase(раз в году и rebase нужен). А он не замаплен. И куда его вставить чтобы вспомнить потом что он там? Или мышкой тянуться?
По философии vim нужная комбинация существует заранее, и требует не столько вспомнить, сколько логически вывести. Сильно упрощённый пример: жмёшь клавишу-лидер (функциональная клавиша для разных сочетаний, мапится куда угодно), какой-нибудь g для вызова команды плагина (git же, логично) и r (rebase).
По этой же философии разрабатываются все плагины. Перемапить тоже можно что угодно, но лучше этим не увлекаться
timon_aeg
12.10.2017 11:22-1Существует какая-то IDE, которая умеет автодополнять js-код не только из стандартных библиотек, но и из проектных?
johnnymmc
12.10.2017 15:54+2Вебсторм, не? На сколько мне известно лучшее автодополнение именно в джетбрэйновских IDE (в обмен на адский жор памяти, конечно, например пичарм у меня под один скромненький скриптик отжирает примерно полгига).
timon_aeg
12.10.2017 16:16-1Он же просто собирает по проекту все методы и функции и потом предлагает к автодополнению.
Умеет хотя бы разворачивать commonjs импорты?
yuryvaskov
12.10.2017 16:02+2Существует хоть какая-то которая не умеет?
timon_aeg
12.10.2017 16:18vimВо всех реализациях надо знать хоть примерное название автодополняемой сущности.
serf
12.10.2017 11:25+1Vim это ведь редактор текста, а не кода, и в своей области возможно он удобен, но IDE это далеко не просто редактор текста, не нужно путать понятия. Как правило статьи про Vim пишут его почитатели, пытаясь видимо что-то кому-то доказать, но зачем доказывать если у них и так все хорошо, такое поведение походит на проявление комплекса неполноценности.
И, если вы хотите понять, что хорошего в виме ...
Значит у вас на самом деле нет настоящей работы которую нужно делать, и от нечего делать вы решили попробовать приобщиться к сообществую мифического вима.
А, если вы хотите обосновать кому-нибудь, что вим — полный отстой ...
Опять же от нечего делать.acmnu
12.10.2017 11:36Vim это ведь редактор текста, а не кода, и в своей области возможно он удобен
Как редактор текста (именно текста, художественного) он не шибко удобен, поскольку все действия заточены именно на структурированный текст
poxvuibr Автор
12.10.2017 16:11+2Художественный текст, на самом деле, неплохо структурирован. Там есть предложения, абзацы, главы и всё такое. Предложения делятся на части запятыми. С вимом вполне удобно.
poxvuibr Автор
12.10.2017 11:40Vim это ведь редактор текста, а не кода, и в своей области возможно он удобен, но IDE это далеко не просто редактор текста, не нужно путать понятия.
Мне кажется, я писал статью как раз для того, чтобы донести свою точку зрения до вас. Да, вим это просто редактор текста, но редактировать текст в нём настолько субъективно удобно, что пользователи своими руками превращают его в IDE. Или пишут плагины для эмуляции vim к другим IDE.
Что касается отсутствия настоящей работы, то редко можно найти человека, который занят 24/7 и совсем не имеет свободного времени.
GrinyaLovesYou
12.10.2017 12:32Отнюдь. Некоторые люди, кроме собственно работы, озадачены еще и тем, как работать побыстрее и делать больше.
yarric
12.10.2017 11:27В чём проблема использовать плагин "как vim" в IDE? И вообще проводились ли какие-нибудь исследования по влиянию на продуктивность этих киллер-фич vim?
serf
12.10.2017 11:34И вообще проводились ли какие-нибудь исследования по влиянию на продуктивность этих киллер-фич vim?
Сначала нужно правильно поставить вопрос, продуктивности чего? Набивки текста, вдумчивой и грамотной работы с кодом, или если смотреть еще шире — решении поставленной задачи?
Last_cat_in_universe
12.10.2017 11:32Почему-то вспомнился Планк:
Новая научная истина торжествует не потому, что ее противники признают свою неправоту, просто ее оппоненты со временем вымирают, а подрастающее поколение знакомо с нею с самого начала.
RouR
12.10.2017 11:37+1Скорость написания кода — это не скорость написания слов, и не скорость нажимания кнопок.
Аргумент «в виме быстрее и удобнее печатать» — это не актуально для программистов.poxvuibr Автор
12.10.2017 11:43"Быстрее" — не актуально. А вот "удобнее" — очень актуально.
mikhailian
12.10.2017 14:16+3Удобнее редактировать программный код. Программисты на самом-то дела пишут мало. Обычно они редактируют существующий код. Я как-то поймал себя на том, что пользуюсь девятью буферами одновременно — так много в коде бывает повторяющихся кусков.
serf
12.10.2017 14:33+3Программисты на самом-то дела пишут мало
Зависит от проекта и вообще специфик работы.
Я как-то поймал себя на том, что пользуюсь девятью буферами одновременно — так много в коде бывает повторяющихся кусков.
Признак говнокода.
Всегда обходился одним буфером и одним монитором, даже когда выбор железа самый любой, при этом более продуктивен чем большая часть коллег.mikhailian
12.10.2017 15:34-1Естественно говонокод, кто же спорит-то. Но зато однообразный и понятный. И дешёвый.
serf
12.10.2017 15:35+2Дешевизна не всегда выражается только в деньгах и даже если так, поддержка и развитие «дешевого» кода может быть дорогой, хотя согласен что поддержка и развитие не всегда предусмотрены.
serf
12.10.2017 11:43Не поленился найти одну из прошлых интеллектуальных (а как по другому если речь идет о Vim) дискуссий habrahabr.ru/post/307084/#comment_9732990
Germanets
12.10.2017 11:47А если ещё вспомнить, что программист в несколько раз больше времени проводит за чтением кода, а не за написанием — то вообще всё печально становится…
Symphel
13.10.2017 10:44Аргумент «в виме быстрее и удобнее печатать» — это не актуально для программистов.
Зато аргумент «в виме быстрее и удобнее выполнять команды» — это актуально.
uploadfor
12.10.2017 11:38Да, это единственный текстовый редактор, при запуске которого успеваешь помолиться, чтобы при работе с ним вдруг не отключился интернет…
kekekeks
12.10.2017 12:45Ну так работайте в screen-сессии, проблему-то нашли.
Fragster
12.10.2017 12:47+1ИМХО uploadfor имеет ввиду постоянную необходимость гуглить, а не работу с нелокальными файлами.
uploadfor
12.10.2017 16:39+1Так точно. Ибо когда его открываю и вспоминаю, как им пользоваться — забываю, собственно, причину его открытия. Увы, nano не всегда и не везде присутствует, поэтому vim до сих пор вызывает у меня трепет и ностальгические судороги :)
BelBES
12.10.2017 17:47-1Имхо, тут проблема от того, что редакторами аля Vim/Emacs сложно пользоваться, если пытаешься запоминать команды/хоткеи… вот когда начинаешь с ним работу с чистого конфига и по мере необходимости добавляешь функционал, то в конечном счете получается минималистичный редактор, весь функционал которого запоминается пальцами и не приходится ничего вспомнинать.
JTG
12.10.2017 16:17+5
river-fall
12.10.2017 16:53-1в чем юмор-то?
tar --help
echo $?
0acmnu
12.10.2017 18:28В этом :)
$ tar -h
tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options
Try 'tar --help' or 'tar --usage' for more information.
$ echo $?
2arheops
12.10.2017 22:33tar -xzf и tar -czf помоему все работающие с линукс больше года помнят. да, есть свичи, которые редко используются. но эти то часто.
acmnu
12.10.2017 23:10Да, но в unix принято, что на -h и на --help показывают хелп. Исключений мало, tar один из них.
И да, кстати. Можно писать просто tar xzf, без черточки.
VtD
12.10.2017 12:17Для перехода в другой режим нужно нажимать ESC. И точно так же убирать руку с home row.
poxvuibr Автор
12.10.2017 12:35Оооо, этот вопрос имеет множество решений.
- Замапить клавишу CapsLock на ESC
- Вместо ESC жать Control + C
- Вместо ESC жать Control + [
Лично я замапил CapsLock на Control и использую третий вариант. Руки с home row убирать не надо :)
siziyman
12.10.2017 13:36+6Так если начать использовать решения 2 и 3, то аргумент «У остальных надо жать Ctrl + Right» как-то слабеет, к примеру.
mayorovp
12.10.2017 13:46+1Проблема комбинации Ctrl + Right — не в Ctrl, а в Right. Эта кнопка находится довольно далеко.
siziyman
12.10.2017 14:18Для варианта 2 — валидный контраргумент (хотя всё ещё это относительно «чужеродная» комбинация), да.
В случае с вариантом 3 клавиша [ в свете расположения (по крайней мере, в стандартной раскладке) не очень удобна для зажимания одновременно с Ctrl — или надо занимать обе руки, или удобство не лучше, а то и хуже, кмк, чем передвижение правой кисти на Ctrl + Right.poxvuibr Автор
12.10.2017 15:15клавиша [ в свете расположения (по крайней мере, в стандартной раскладке) не очень удобна для зажимания одновременно с Ctrl — или надо занимать обе руки
Я почти всегда зажимаю комбинации с Control + клавиша двумя руками и всем советую. Это гораздо менее болезненно для рук.
MacIn
12.10.2017 16:1610см в сторону, причем просто сгибая кисть, а не перенося — это далеко? Какие у людей проблемы-то…
mayorovp
12.10.2017 16:21У вас какая-то уменьшенная клавиатура. Сгибая кисть без переноса я разве что до Left дотягиваюсь, а Right уже за пределами доступности.
MacIn
12.10.2017 16:31-1Да нет, стандарт. Это у вас рука маленькая :P Это так, просто к слову — я руку переношу, никаких неудобств не доставляет. Я не набираю код с такой скоростью, чтобы необходимость переноса кисти становилась узким местом.
poxvuibr Автор
12.10.2017 16:34+1Я не набираю код с такой скоростью, чтобы необходимость переноса кисти становилась узким местом.
Я в очередной раз хочу отметить, что речь не идёт о скорости. Речь идёт об удобстве.
MacIn
12.10.2017 16:38+1Мой мозг отказывается понимать, в чем здесь неудобство, если откинуть фактор времени и скорости.
Вообще, по большому счету, оба метода — отстой. Ведь программисту что нужно, если мы говорим о курсоре? Чтобы машина шарахнула курсор вооон туда, между теми двумя словами.
Было б здорово — о, идея для стартапа — чтобы были очки, которые следят за зрачком. Смотришь на позицию в тексте, жмакнул Ctrl и курсор туда прыгнул. Вот это — удобно.
А обсуждаемые методы — оба инвалидские.
Один — итеративный — мы жмем клавиши раз за разом, последовательно приближая текущую позицию курсора к желаемой; второй — делает то же, но мы мысленно загодя вычисляем разницу и компонуем команду, это так же неудобно.
А уж какой из двух неудобных инвалидских способов использовать — дело каждого.poxvuibr Автор
12.10.2017 16:50Мой мозг отказывается понимать, в чем здесь неудобство, если откинуть фактор времени и скорости.
В том, что нужно часто двигать руку к стрелкам и всему такому. Это реально напрягает после того, как понял, что это можно не делать. Искать стрелки не глядя на клавиатуру — немного отвлекает. Искать пупырышки на home row — тоже. Немного, но это приходится делать постоянно.
А обсуждаемые методы — оба инвалидские.
Тут не поспоришь. Хотя метод с очками, предложенный вами, наверное требует нелохой концентрации. А тут есть какая-то дискретность.
А уж какой из двух неудобных инвалидских способов использовать — дело каждого.
Ну да. Но только многие думают, что способ выбранный в виме объективно хуже обычного и пытаются найти ради чего пользователи вима готовы его терпеть.
MacIn
12.10.2017 17:01В том, что нужно часто двигать руку к стрелкам и всему такому.
Что в этом неудобного?
Это реально напрягает после того, как понял, что это можно не делать.
Теоритически, можно переопределить все ключевые слова и идентификаторы так, чтобы они укладывались в символы home row. Это будет еще удобнее — вообще пальцы отрывать не надо.
Искать стрелки не глядя на клавиатуру — немного отвлекает.
Честно — не понимаю, без всякого троллинга. У меня руки сами ложатся как на фываолдж, так и на стрелки, чистый автоматизм.
Ну да. Но только многие думают, что способ выбранный в виме объективно хуже обычного и пытаются найти ради чего пользователи вима готовы его терпеть.
Пока что вы выглядите, как человек, который пытается найти эфемерное преимущество в режимной парадигме, которая проистекает, скорее всего, из ограничений старых терминалов. Эфемерное, потому что рассказы про неудобство переноса кисти — неубедительны. Это выглядит именно как попытка найти преимущество в любимом режиме. Пользоваться можно обоими, кто к чему привык, тому то и любо.mayorovp
12.10.2017 17:03Честно — не понимаю, без всякого троллинга. У меня руки сами ложатся как на фываолдж, так и на стрелки, чистый автоматизм.
У вас ложатся, у меня кладутся, а у кого-то так не получается. Хватит думать что вашими способностями обладает все человечество.
MacIn
12.10.2017 17:05-1У вас ложатся, у меня кладутся, а у кого-то так не получается. Хватит думать что вашими способностями обладает все человечество.
Такими сверх-способностями, разумеется, обладают не все, извините, я забыл.MacIn
12.10.2017 17:11-1Скажи, что ты привык пользоваться командной парадигмой — все, никаких вопросов. Но когда слышишь в качестве преимущества то, что можно позиционировать курсор, не отрывая руки от основного ряда, то первым в голову приходит, простите за грубость, «тупая отмазка».
Ну нравится тебе есть палочками, а не вилкой, ты так привык — да бог тебе судья, на здоровье. Но не надо выдавать возможность проткнуть палочками оба глаза оппоненту за важное преимущество.
poxvuibr Автор
12.10.2017 18:30Честно — не понимаю, без всякого троллинга.
Охотно верю, что не понимаете. Просто поверьте, что возможность не убирать руки с home row меня, и многих других очень радует. Мы её ценим. И с режимами нам работать приятно. Не только по вышеизложенной причине, но и по ней тоже. Я написал статью как раз для того, чтобы сказать, что мы правда любим вим из-за режимов :)
Пока что вы выглядите, как человек, который пытается найти эфемерное преимущество в режимной парадигме, которая проистекает, скорее всего, из ограничений старых терминалов.
Что самое удивительное — нет. Она возникла не из-за этого. Она возникла из-за того, что создатель vi не хотел зажимать Control :)
рассказы про неудобство переноса кисти — неубедительны.
Тем не менее, таковы мои ощущения. Объективно — руку надо часто перемещать к стрелкам. Субъективно — мне жто неудобно.
Это выглядит именно как попытка найти преимущество в любимом режиме. Пользоваться можно обоими, кто к чему привык, тому то и любо.
Большую часть своей жизни я провёл редактируя текст обычными редакторами. Я к этому привык, а потом попробовал vim и он мне понравился больше.
poxvuibr Автор
12.10.2017 16:22+210см в сторону, причем просто сгибая кисть, а не перенося — это далеко?
Очень, очень далеко. Особенно учитывая, что во время работы с кодом это приходится делать постоянно. А если не переносить руку, а сгибать кисть это чревато RSI. После этого программировать станет тяжело.
MacIn
12.10.2017 16:31Особенно учитывая, что во время работы с кодом это приходится делать постоянно
Никаких проблем с переносом не испытваю. Я не машинистка.
extempl
12.10.2017 20:34Вроде где-то читал, что некоторые извращаются с педалями под ноги.
poxvuibr Автор
12.10.2017 20:57Пользы от педалей для ног при переключении режимов в виме нет практически никакой. Педалями можно попробовать заменить шифт и контрол. Не только в виме, а везде, вот от этого польза теоретически может быть.
mdErrDX5341
12.10.2017 21:18-1эти извращенцы используют emacs, не даром его называют редактором для пианистов)
mdErrDX5341
12.10.2017 22:41Ну и от куда минусы, шутка про педали и пианистов как раз пошла от emacs в котором как раз почти огромное количество действий начинаются с ctrl + *, а многие с ctrl + ctrl + *, это просто история…
Я лично после попыток им овладеть через 4 дня почувствовал боль в кистях.
Хотя на сколько я знаю когда создавались vim и emacs ctrl находился там где сейчас находится caps lock, вроде не ошибаюсьkost
12.10.2017 22:54Хотя на сколько я знаю когда создавались vim и emacs ctrl находился там где сейчас находится caps lock, вроде не ошибаюсь
Да: www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys
niya3
12.10.2017 22:54А ещё можно так
" Мапим Esc в режиме ввода set inoremap XXX ^[
На месте XXX любой набор символов, который вам удобно набирать и который не встречается в набираемом вами тексте. Традиционные варианты — jj или ;;
zooks
12.10.2017 12:19Имхо, nano по клавиатурным сокращениям ещё большая дичь, чем vim. Поэтому когда-нибудь пересяду на него.
А с IDE сравнивать vim некорректно. Это консольный текстовый редактор, ни больше, ни меньше.aelaa
12.10.2017 12:53+1Сравнивать с текстовым редактором IDE можно. Правда непонятно что вообще люди подразумевают под IDE.
Vim с нужными плагинами заменяет IDE полностью, и в ряде случаев выигрывает в скоростиVtD
12.10.2017 12:59А что предложите тем, у кого на caps висит переключение раскладки?
aelaa
12.10.2017 13:03мимо, но я тоже на Ctrl+[ и Caps вместо Ctrl :)
А часто во время написания кода нужно раскладку переключать?
poxvuibr Автор
12.10.2017 13:09Лично я предлагаю не переключать раскладку по caps. Это порочная практика, которая больше мешает, чем помогает.
Переключение раскладки по caps нужно, чтобы раскладка переключалась быстро и просто, а переключать её быстро и просто нужно потому, что это приходится делать часто. А когда ты часто переключаешь раскладку, то достаточно быстро перестаёшь понимать, какой язык у тебя включен сейчас. И выходит так, что ты печатаешь символ, понимаешь, что он не от того языка и тогда жмёшь caps. А иногда сначала жмёшь caps и только потом понимаешь, что язык был тот, который надо.
Так вот, чтобы этого избежать лучше сделать одно клавишное сочетание переключением на один язык, а другое на другой. И тогда, когда ты точно знаешь, что сейчас надо печатать на русском — сначала нажимаешь хоткей для русского языка, а потом начинаешь печатать. Идемпотентность рулит!
mdErrDX5341
14.10.2017 02:26а у меня вообще изменение раскладки на C-l, а снизу подсветка, бледно синий цвет это англ., а красный это рус., незнаю, для меня удобно)))
vaniacer
12.10.2017 16:51Они не интуитивны, да, но постоянно на виду и их не надо запоминать а после нескольких повторов сами запоминаются легко и непринужденно.
nizkopal
12.10.2017 12:34Хорошая киллер-фича. Использовать ее я, конечно, не буду. :)
А вообще мне статья понравилась. Я узнал что-то новое — про кнопку «e» в vim. И я улыбнулся, читая ее. Конечно, я не перестану пользоваться теперь IDE.poxvuibr Автор
12.10.2017 12:47Хорошая киллер-фича. Использовать ее я, конечно, не буду. :)
Вооот! Ради этого я и писал статью. Если человеку мешают режимы, то вим ему не нужен .
Danik-ik
14.10.2017 11:59+1Да уж. Всё субъективно. "Кому нравится поп, кому попадья, а кому — попова дочка".
Лично мне, если прислушаться к тому, ради чего люди ценят режимы Вима (сужу по соседним комментариям), то (субъективно) надо бежать со всех ног. Не убирать руки с home row. Почти не шевелиться. Весь день! Я бы взвыл, честно, и никакая высокая скорость для меня этого не оправдает.
У меня два метра до мусорки, четыре — до чайника. Ближе не придвину никогда, просто нужен повод встать и подвигаться.
Движение — жизнь. Руки от движения болят тогда, когда движение для них — это ненормально. Не без исключений, но всё же так.
mklochkov
12.10.2017 13:03Интерфейс vim (вернее, его предшественника vi) спроектировали люди, набирающие текст на клавиатуре десятью пальцами, для других таких же.
И спроектировали достаточно удачно. Действительно, работая с vi/vim, можно не убирать руки из исходного положения, по минимуму использовать различные комбинации Ctrl/Alt, быстро перемещаться к нужному файлу/месту в файле (без всяких Home/End, скроллбаров, мыши) и т. п. Многим это всё достаточно важно.
Ну и ещё одна приятная особенность vim — он нормально относится к файлам большого размера. Для написания кода это не имеет значения, а для обработки каких-нибудь логов — очень даже. Поиск в файле в миллион строк занимает у vim на среднем компьютере не больше 1–2 секунд.mdErrDX5341
12.10.2017 13:29+1добавлю…
удобное перемещение, а так же за счет вкладок, окон для буферов + плагином для удобного сохранения сессии больше комфорта для написания/редактирования.
Именно когда пишешь код не нужны 33 лишних окна которые предоставляет IDE и всякие доп. фишки которые в них есть.
mayorovp
12.10.2017 13:51Есть и альтернативный вариант — научиться возвращать руки в исходное положение. В таком случае даже мышь перестает мешать и начинает помогать :-)
mklochkov
12.10.2017 15:05Мышь удобна, если нужно позиционироваться по «визуальным» объектам (например, работу в графическом редакторе без неё представить вообще невозможно).
Если нужно позиционироваться по «абстрактным» объектам (идентификаторам, скобкам, обозначающим начало/конец блока, именам файлов) — удобнее «горячие клавиши» или даже текстовые поля ввода с подсказками.
С некоторых пор понял для себя, что при работе в той же Windows гораздо проще вызывать программы/открывать документы не блуждая по менюшкам/иконкам, а нажать кнопку с окошками (попадаем в поле Search programs and files) и ввести несколько букв интересующей нас сущности (имени программы или документа).
Аналог в Mac — Spotlight (Ctrl+Space), аналог в vim — просто слэш.mayorovp
12.10.2017 16:18С некоторых пор понял для себя, что при работе в той же Windows гораздо проще вызывать программы/открывать документы не блуждая по менюшкам/иконкам, а нажать кнопку с окошками (попадаем в поле Search programs and files) и ввести несколько букв интересующей нас сущности (имени программы или документа).
Я надеюсь, "кнопкой с окошками" вы обозвали клавишу с окошками? :-)
tyomitch
12.10.2017 19:50Ну и ещё одна приятная особенность vim — он нормально относится к файлам большого размера.
Зато в нём довольно неудобно работать со строками большого размера: если не-текущая строка не помещается на экран целиком, то она не показывается вовсе.
gonzazoid
12.10.2017 13:48+3Беда фанатов вима — они хотят доказать всем правильность своего выбора. Беда хейтеров — они хотят доказать обратное.
Я пользуюсь вимом с десяток лет, доволен настолько что не участвую в холиварах и никому не навязываю. Ничего лучше ДЛЯ СЕБЯ я не нашел (много пишу фронта, шарпы, иногда java и немножко haskell, периодически поигрываю с с/с++ и llvm)
Если программист плотно сидит в одном стеке то естественно что скорее всего под этот стек будет вылизанная IDE. А вот когда стеков несколько — приходится выбирать — несколько IDE или один vim. А когда стеки под разные платформы (винда/мак/никсы) — vim хорош. Только доказывать никому ничего не надо — нравится — пользуйтесь, не нравится — не пользуйтесь.
Kirhgoff
12.10.2017 23:26Спасибо вам за первый разумный комментарий в этой дискуссии. И именно в этом киллерфича вима, на мой взгляд — он есть везде и в нем есть плагины для всех языков и ты сам под себя можешь все настроить, как тебе удобно. Причем настройка представляет собой копирование файла — хоть по ssh программируй.
Если проект использует только java, было бы безумием не пользоваться IDEA, но у меня в проекте есть и ruby и golang и clojure и java, и я, как недовимер прыгаю между rubyMine, IDEA, sublime и vim(использую для go), а много кто сидит или в vim или в emacs и не выходят из них вообще.rkosolapov
13.10.2017 07:50emacs лучше вима в этом. и в большинстве других вещей емакс тоже круче.
вим очень крут двумя вещами — 1. он есть практически на любом сервере с линуксом и 2. он неплохо работает удалённо в случае плохого интернета (когда каждое нажатие клавиши приводит к торможению).
rkfg
12.10.2017 14:05Для меня режимы — это главный минус vim. Печатаю я, конечно, вслепую и давно, но иногда всё же промахиваюсь. При наборе текста это не проблема, удалил символ, написал новый. Но когда в виме я в нормальном режиме, начинается то самое «пищит и портит». Остаётся судорожно жать Esc несколько раз, чтобы точно там не набилось невидимых команд в буфер.
poxvuibr Автор
12.10.2017 14:23Для меня режимы — это главный минус vim.
И поэтому вы используете vim только тогда, когда ничего другого вообще нет, так?
rkfg
12.10.2017 14:26Нет, я использую только его, но для мелких вещей типа правки конфигов. Другие редакторы просто ещё хуже, а тут хотя бы можно строку удалить быстро. В IDE, конечно, ещё быстрее (Ctrl-D вместо Esc,d,d), но для конфигов запускать её — оверкилл.
zloddey
12.10.2017 14:27Ctrl+[в слепом варианте набирать удобнее. Левая рука жамкает наCtrl, правая на скобку. И сдвиг кистей минимальный получается. До того привыкаешь порой, что начинаешь и в браузере эту комбинацию жатьrkfg
12.10.2017 14:32У меня так мизинец не выгибается, чтобы до [ достать, я обычно «х» жму безымянным, смещая руку. А в описанном сценарии проблема именно с промахами, так что тут можно ещё сильнее усугубить. А Esc всегда в углу клавиатуры.
zloddey
12.10.2017 14:52Где-то в комментариях выше рекомендовали также попробовать
Ctrl+c(сам не знал). Может, эта комбинация лучше зайдёт?rkfg
12.10.2017 14:58Да, это удобнее. Но модальные режимы всё равно не выглядят для меня привлекательными, т.к. не вижу задач, где требовалась бы именно набивка больших объёмов текста с максимальной скоростью.
vintage
12.10.2017 14:12+8То есть тянуться до стрелочки мизинчик устаёт, а до эскейпа — нет? Зажимать контрол очень тяжело, а зажимать шифт — легко и просто? Тыкнуть курсором в нужную часть текста долго, а выплясывать на клавиатуре заклинания — быстро? Я правильно всё понял?
poxvuibr Автор
12.10.2017 14:35-1То есть тянуться до стрелочки мизинчик устаёт, а до эскейпа — нет?
До эскейпа тоже устаёт, поэтому либо мапим CapsLock на эскейп, либо мапим CapsLock на Control и потом жмём вместо эскейпа Control + [ .
Зажимать контрол очень тяжело, а зажимать шифт — легко и просто?
Шифт зажимать удобнее, чем контрол, потому что не надо убирать руки с home row. Но вообще рекомендую сделать так, чтобы вместо Контрола был CapsLock
Тыкнуть курсором в нужную часть текста долго, а выплясывать на клавиатуре заклинания — быстро?
Зависит от того, насоколько далеко нужная часть текста от текущей позиции курсора. Но вообще я специально сделал акцент на том, что речь идёт не о скорости, а об удобстве.
Я правильно всё понял?
Нет, не совсем. В этой статье я не пытался объяснить чем режимы хороши, хотел просто сказать, что режимы это именно то, из-за чего люди пользуются вимом. Что они плюс, а не минус.
flastir
12.10.2017 15:06-1До ESC, действительно, сложно тянуться. Раньше мучился с этим при работе в vim или в vim-плагинах IDE, а сейчас открыл для себя Ctrl+[, которая заменяет ESC. В итоге руки находятся в одном положении, не пляшут до мышки, стрелок или тачпада. Меньше движений рук = больше концентрация на коде.
sabio
12.10.2017 14:18+1Редактор Kakoune предлагает дальнейшее развитие идеи "составляемых команд". Вместо "команда-объект", как в vim, он использует подход "объект-команда". Это позволяет сделать работу более интерактивной (вы будете видеть выделенный текст прежде чем введёте команду на его удаление).
Также разработчики прогнозируют более пологую кривую обучения за счёт интерактивной подсказки о набираемой команде.
http://kakoune.org/why-kakoune/why-kakoune.html
sabio
12.10.2017 14:38Ещё интересный взгляд на тему "модальности" Vim: http://www.viemu.com/a-why-vi-vim.html
Если смотреть на 'i' не как на переключение режима, а как на обычную команду, такую же как, например, 'd', то, получается, никаких "режимов" и нет. Вы просто вводите команды:
d10j
G
iHello < Esc >
Дополнительная прелесть в том, что '.' повторяет предыдущую команду редактирования. Т.е. достаточно нажать точку и вы получите ещё одно 'Hello' в позиции курсора. А если вместо 'i' использовать 'A', то перед началом ввода курсор переместится в конец строки.
Статья выше содержит много других подобных примеров. А также разъясняет некоторые другие ошибочные представления о работе с Vim.
brain2xml
12.10.2017 14:40+1Я как раз из тех людей что программируют под vim. Процесс привыкания был недолгим и закончился хорошо, сейчас уже 3й год пошел. Самое основное достоинство это то что какой бы большой, странный файл мне попался, неважно зашел я про ssh, sftp, подмантирова внешний диск, файл гарантированно откроется и корректно сохраниться.
нравиться работа со строками, автовыравнивание, повторение операции по точке, вообщем много чего
divanikus
12.10.2017 14:59+3Главная киллер-фича vi в том, что он есть почти везде. Остальное — вкусовщина.
poxvuibr Автор
12.10.2017 15:05+1Главная киллер-фича vi в том, что он есть почти везде.
Это киллер фича только для тех, кто использует вим исключительно для редактирования конфигов по SSH. Больше ни для кого это не важно.
RomanStrlcpy
12.10.2017 18:35кто вам такую фигню сказал? админы пишут в нём скрипты, редактируют конфиги, программисты код на локальной и удаленной машине, для выполнения слияний в системах контроля версий. И ещё 100500 применений.
И многим (я в их числе) это удобно, когда у тебя один инструмент для выполнения разного рода задач. Возможно кому-то удобно кодить в IDE, мержить код в какой нить спец. тулзе, редактировать конфиги в чём-то ещё.
VIM это мультитул, в некоторых моментах уступающий спец. приложениям, но в большинстве своём его возможностей хватает для всего, а если чего-то не хватает в базе, то скорее всего уже есть плагин.poxvuibr Автор
12.10.2017 18:38+1кто вам такую фигню сказал? админы пишут в нём скрипты, редактируют конфиги, программисты код на локальной и удаленной машине, для выполнения слияний в системах контроля версий. И ещё 100500 применений.
Я не хотел сказать, что vim используется только для редактирования конфигов по ssh. Я хотел сказать, что возможность использования по ssh является киллер фичей только для тех, кто в основном пользуется вимом для работы через ssh в консоли.
OYTIS
12.10.2017 15:02Режимы — это удобно, да, но это скорее преимущество vim перед nano и emacs, а не перед IDE. В сравнении же с IDE для меня главное — это то, что не нужно выходить из командной строки. Сейчас у меня из графических приложений только браузер и просмотрщик pdf в отдельных виртуальных экранах, остальное все делается в терминале.
MacIn
12.10.2017 16:12+1В обычном редакторе для того, чтобы переместить курсор к концу слова нужно зажать Control, а потом, не отпуская его, перенести руку к стрелкам и нажать клавишу вправо. В редакторе получше, можно нажать не вправо, а какую-нибудь клавишу на буквенной часть клавиатуры, например d, но Control всё равно придётся держать зажатым. А в виме нужно просто нажать e
Это «преимущество» убивается необходимостью переключения между режимами.
Считайте знаете что, поклонники vim'а? Что зажатый Ctrl- это и есть переход в другой режим, только временный. Ну, как shift Vs Caps Lock. Чем Esc + e + i лучше, чем Ctrl+RightArrow?poxvuibr Автор
12.10.2017 16:18Это «преимущество» убивается необходимостью переключения между режимами.
Если речь идёт об однократном действии, после которого нужно вернуться в режим вставки, то действительно переключение может быть неприятным. Но чаще всего курсор нужно передвинуть не в конец текущего слова, а достаточно далеко, суммой нажатий клавиш, а не однократным.
Считайте знаете что, поклонники vim'а? Что зажатый Ctrl- это и есть переход в другой режим, только временный.
Да, и держать нажатой клавишу для временного режима, когда ты реально проводишь в этом режиме достаточно долго, это не очень удобно.
Чем Esc + e + i лучше, чем Ctrl+RightArrow?
Тем, что не нужно убирать руку с home row для того, чтобы нажать RightArrow.
MacIn
12.10.2017 16:26-1Если речь идёт об однократном действии, после которого нужно вернуться в режим вставки, то действительно переключение может быть неприятным. Но чаще всего курсор нужно передвинуть не в конец текущего слова, а достаточно далеко, суммой нажатий клавиш, а не однократным.
Ну, звиняйте, пример-то в статье именно такой.
Стандартная строка — 80-100 символов (на мой взгляд), переместиться обычными, не вимовскими способами надо максимум на пол-строки (либо идем от начала, либо через End — с конца). Я лично разницы между «зажать control и нажать три раза стрелку вправо» и «нажать ескейп, набрать команду перемещния вправо на три слова, нажать i» не вижу (такой, что давала бы преимущества вимовской парадигме).
Да, и держать нажатой клавишу для временного режима, когда ты реально проводишь в этом режиме достаточно долго, это не очень удобно.
Как-то… еще там клавиши PgUp PgDown затесались, Home, End, никаких «надолго» не встречается.
Точнее, у вас как в анекдоте: «Ох, сегодня заехал в магазин, купил сцепление, потом во второй, купил колодки, потом захеал в сервис, мне это поменяли, потом сгонял на ТО… и все в разных концах города, как бы я это успел, если бы не машина...»
Тем, что не нужно убирать руку с home row для того, чтобы нажать RightArrow.
Эмм. И? Лично я держу на фыва'е левую руку, правую — на стрелках и тех самых PgUpDownHomeEnd.
Реально, как внизу человек уже написал — ощущение, будто в общество машинисток попал.
Delphinum
12.10.2017 16:20Ну вообще так и есть, от чего становится совсем не понятно, зачем хають режимы, когда они используются повсеместно.
niya3
12.10.2017 22:45Чем Esc + e + i лучше, чем Ctrl+RightArrow?
Например, числовыми модификаторами =)
Сможете переместиться на десять слов вправо, набрав 10Ctrl-RightArrow? (10e)
Сможете быстро удалить весь текст до вхождения следующего символа + в длинной строке? (dt+)
Сможете выделить текст до следующего вхождения слова в файле, не перематывая туда-сюда и не боясь пропустить слово\потерять исходную позицию? Например, выделить с текущей позиции курсора, до слова function, расположенного на N экранов ниже. (v/function)
Сможете повторить предыдущее действие редактирования любой сложности(удаление строки, замена содержимого кавычек) нажатием одной кнопки? (.)
<disclamer>
Vim не IDE, я знаю, но на наших linux-машинах нет ни IDE, ни X-ов, а из mcedit мало что выжмешь, в лучшем случае вызов внешних скриптов из пользовательского меню (я проходил).
</disclamer>
Сможете перейти из файла с ошибками компиляции в нужный файл в строчку, на которой произошла эта ошибка? (gF)
Сможете выполнить любую команду оболочки, не выходя из среды? (:!make)mdErrDX5341
12.10.2017 22:52Хотелось бы поставить +))) но не могу…
Но самое главное что я могу заметить, через какое-то время это делается на автомате и я даже не могу иногда ответить что я нажал что бы добиться нужного результат.
mayorovp
13.10.2017 08:51Чтобы переместиться на десять слов вправо, нужно сначала подсчитать число слов. А слова лично я подсчитываю при помощи Ctrl+Shift+Right :-)
niya3
12.10.2017 23:29Чем Esc + e + i лучше, чем Ctrl+RightArrow?
Ради единственного перемещения нет смысла выходить из режима ввода. Ctrl-o + e(или любая другая команда из нормального режима) и пишем дальше.
Справедливости ради — в режиме ввода все редакторы более-менее одинаковы — нажал на кнопку, появился символ. Прелесть vim в его нормальном режиме.
VMichael
12.10.2017 16:13-1Такое ощущение, что тут общество машинисток.
«Дотянуться мизинцем до… быстрее чем до...».
Я, признаюсь, больше думаю, чем печатаю, когда пишу код.
Конечно удобство ввода это хорошо, но по мне, все таки не самое важное в работе программиста. IDE предоставляют достаточно возможностей.
А из обсуждения видно, что уже пошли настройки ради настроек. Ну еще, что бы выпендриться перед неким пользователем, который не успевает следить за руками фокусника программиста.MacIn
12.10.2017 16:18-2Такое ощущение, что тут общество машинисток.
Жалко, что нельзя 10 плюсов накинуть.
mayma
12.10.2017 16:36+2Я, признаюсь, больше думаю, чем печатаю, когда пишу код.
Конечно удобство ввода это хорошо, но по мне, все таки не самое важное в работе программиста. IDE предоставляют достаточно возможностей.
1. Вы не просто «больше думаете, чем пишете», а постоянно то думаете, то пишите то перемещаетесь, то ищите.
Можете поставить программу специальную — и понаблюдать за своим клавиатурным поведением. И выясниться, что пишете/ищите/перемещаетесь все же вы довольно много.
2. IDE превосходят только более удобной пошаговой отладкой (брейкпойнты и пр).
Если вы отлаживаете через просмотр логов или проверку поведения программы — то между IDE и vim разницы нет.
Все прочее — подсказки, сниппеты и т.д. — функционально одинаковы.
3. Настройки ради настроек это потому что vim является изначально программируемым текстовым редактором, который можно заточить под свою задачу очень и очень индивидуально.
Пользователь vim, который не умеет программировать на VimScript это нормально.
Но пользователь vim, который хотя бы не использовал чужие готовые модуля, не писал (точнее программировал) свою индивидуальную версию конфигурационного файла vim — это нонсенс.VMichael
12.10.2017 16:53+1Тратить мыслительный аппарат еще на заучивание команд Vim — расточительно. Для меня конечно.
У меня собственное рабочее окружение. Мне мои инструменты доступны всегда. Мне по ходу моей работы не нужно шариться по удаленным серверам, где как тут пишут «всегда есть Vim», а других редакторов нет.
И я как то осознал, что не хочется изучать еще какие то инструменты, хочется решать задачи. Я печатаю вслепую 10-ю пальцами и мне достаточно стандартных каких то хоткеев + хоткеи IDE. Режимы какие то, переключения.
Меня в свое время очень бесил переход MS офиса на ленточный интерфейс. Мне он вообще был не нужен. А меня заставили изучать новый интерфейс под предлогом, что так когда нибудь будет быстрее.
Ну нравиться кому то, на здоровье.
Вы знаете, я заметил, что если есть что то безусловно удобное (как например сотовая связь или мессенджеры, или IDE), убеждать использовать это никого не приходиться. А вот если это не очевидно, то возникают холивары бесконечные.
Ну удобно, пользуйтесь на здоровье, для себя я не увидел аргументов, которые заставили бы меня преодолеть барьер освоения Vim.
pashet42
12.10.2017 21:52Заучивать команды Vim не надо. Они сами постепенно входят в подкорку на автомате. Вы ж не тратите мозговые усилия на катание на велосипеде или коньках.
Моя дочь (5 лет) вот тоже ни в какую не желала учиться кататься на велосипеде, хотя мы с ней примерно год пробовали неоднократно. И падала и разбивала коленки сначала. И бросала это дело. Но потом вдруг поехала и теперь испытывает непередаваемое удовольствие от катания! И, Вы знаете, она тоже не может вменяемо объяснить, чем катание на велосипеде так круто. Но она точно знает, что теперь уже всегда обязательно будет стремиться на нём кататься! Примерно такие-же ощущения у меня от работы в Vim.VMichael
12.10.2017 22:47Я давно уже не обращаю внимание на аналогии. Аналогиями можно доказать, что угодно и запудрить мозги.
Я вовсе не против того, что бы кто то работал в Vim и не призываю не делать этого. На здоровье, пусть работают, но тут звучит мысль: нужно просто потратить время на изучение и потом не сможешь оторваться. Эта мысль не верна. Кому то нравиться, а кто то потратил время и не полюбил Vim. Каждому свое.
addnot
12.10.2017 18:34Я уж начал думать, что только я такой тормоз, а все вокруг что фигачат код 10 пальцами весь день, а то статьи про крутость в vim как грибы в последнее время. Обычно, пишешь не столь много, сколько обдумываешь, рисуешь схему себе (да, ручкой, без компьютера с клавиатурой), что-то ищешь в интернете, общаешься с заказчиком. А навигация по проекту — мне с мышкой в студии удобней, можно ещё на спинку кресла откинуться и пить кофе :-)
symbix
12.10.2017 18:46+2Работать с кодом должно быть настолько удобно, чтобы не задумываться над этим вообще и делать это спинным мозгом. Это же относится и к хоткеям IDE и всему остальному. Странно, что вообще об этом требуется говорить, это ведь очевидно.
Что касается конкретно vim-а (или vim-плагинов): насколько сложно к нему привыкнуть, я уже не помню (лет 15 прошло), но вот когда привык, без него очень дискомфортно.
AGARTY
12.10.2017 16:30Как ни нахваливали бы vi(m), но пользуюсь преимущественно простыми редакторами, типа ee и nano. Нет не потому что vi(m) мне не нравится, хотя не скрою это так. Просто потому, что если требуется изменить пару значений конфига, прочитать файл, или сделать простейшую операцию в кроне, то мне нужно просто открыть, изменить, сохранить и выйти. Все. НО у vi(m) есть огромнейший +. От которого я в восторге — он умеет быстро открывать громадные по размеру файлы (например я открывал файл БД в 2 ГБ) и очень быстро производить подмены и поиск в них. Но это бывает очень редко, поэтому vi(m) я использую только для каких-нибудь крупных задач, и не вижу смысла «жить» в нем.
sah4ez32
12.10.2017 16:31Еще к плюсам можно отнести то, что если использовать плагин Vim для любых IDE и программ (Браузер %-), notepad++ ), то получается везде одинаковые сочетания клавиш и единый интерфейс работы с приложением через клавиатуру. И получается надо выучить один раз vim и не надо учить различные шорткаты для разных IDE/программ. А при использовании разных клавиатур Win/MacOS это уже весомый профит.
vaniacer
12.10.2017 16:54-1Хорошая попытка vim но, нет.
Для баша использую гедит с плагинами а для питона пайчарм.
Киллерфича — средняя кнопка мыши)
niya3
12.10.2017 18:33Статьям про vim не хватает опросника с вариантами типа
- Я прошёл vimtutor.
- Я пробовал, но не прошёл vimtutor.
- Что такое vimtutor?
ZyXI
13.10.2017 00:27А смысл такого опроса и вообще о чём он? Вот я пользуюсь Vim, печатая вслепую, но vimtutor не прошёл, и даже печатать вслепую учился без курсов вроде «соло на клавиатуре» (кстати, как раз пробовал, но не прошёл): просто перешёл на другую раскладку (программистский Дворак), подвесил оную под монитором и начал так печатать (заодно узнал, что в linux’овой консоли (той, что по
<C-A-Fn>) оказывается есть таймаут на набор пароля). Но при этом «что такое vimtutor» я примерно знаю. Мне что отвечать?
lomnev
12.10.2017 18:34+11. С помощью Vim можно программировать примерно так, как водить машину или набирать текст десятипальцевым методом.
То есть после периода тренировки мысли переводятся в моторику автоматически, без лишнего слоя визуально-моторной абстракции. Например, в Vim реально написать Hello World на Java с закрытыми глазами, и в отличие от IDE, сделать это с уверенностью и комфортом.
2. Также в некоторых проектах часто приходится открывать файлы в 0.5-10Гб. По крайней мере у меня такая ситуация при работе с различными датасетами. Vim – единственный из найденных мной редакторов, который позволяет работать с такими файлами быстро и удобно.
3. Ясно, что для больших проектов нужны IDE, а вот для скриптов/микросервисов, работающих с большими объемами данных Vim может быть даже предпочтительнее.
Пропиарю немного еще свое единственное видео про «Минимальный набор команд Vim», может кому-нибудь пригодится. www.youtube.com/watch?v=pWuRYwlbNaIZyXI
13.10.2017 00:36Второй пункт означает, что остальные редакторы, что вы нашли, ещё хуже Vim: вообще?то Vim сразу грузит весь файл в память, даже не используя mmap(). Другое дело, что он на C и там простейшие C’шные строки, собранные в структуры; overhead по памяти есть, но не очень большой и тем менее заметен, чем длиннее строка. «Большие датасеты» такой вариант проглатывает, только если есть достаточно памяти, но если память есть, то скорость работы самого Vim не упадёт (другое дело дополнения, особенно если им зачем?то нужно проходиться по всему буферу, иногда синтаксические файлы требую странного вроде
syn sync fromstart).mdErrDX5341
13.10.2017 00:48вим работает на больших файлах так как применяет фичи на небольшие куски, но все плохо складывается с плагинами, так как они работают не асинхронно, но сейчас пилят neovim, там вроде исправляют много legacy кода… опять же это вроде как доказывает что оно кому-то нужно.
ZyXI
13.10.2017 01:17Neovim пилят не столько из?за legacy, сколько из?за Брама и модели разработки вообще: хотя Neovim и нарушает обратную совместимость в некоторых местах, многие его преимущества такого нарушения в принципе не требуют, но через Брама никогда бы не прошли. Теперь ситуация несколько изменилась: Neovim наступает на пятки, поэтому Брам посылает лесом свой же
:h design-not, испытывает прилив энтузиазма и создаёт несовместимые альтернативы. Но модель разработки так и не поменял, поэтому всегда можно обнаружить в master сначала изменение «добавлено X» потом «после добавления X нифига не компилируется» (хотя обычно всё же «не компилируется с определённым набором возможностей»), но нельзя обнаружить метку «это стабильный релиз». И никто не делает review (не публично, во всяком случае), не ждёт результата CI перед тем как засунуть что?то в master и не всегда понятно, что нужно сделать, чтобы ваш вклад оказался в master (и, кстати, автором всех изменений в основном репозитории с т.з. git[hub] всегда выступает Брам, оригинальный автор указывается в комментарии).
Возможность сделать что?то асинхронно — это пример возможности, изначально появившейся в Neovim, а потом переписанной Брамом для Vim, с несовместимым API, конечно.
Впрочем, это не значит, что legacy код у нас не исправляется. К слову, я один из основных авторов Neovim, хотя и не первый по числу кода. И я как раз сейчас очень медленно переписываю большой кусок legacy под названием «VimL»: в идеале в итоге должны быть полностью изменён «парсер/исполнитель» на реальный парсер и виртуальную машину: сейчас код выполняется по мере разбора, таких вещей как «синтаксическое дерево» и «байт?код» нет.
mdErrDX5341
13.10.2017 01:36Отлично)) Я как раз слежу за neovim, но поглядываю не так часто, так как сам почти всегда пользуюсь GVim, я как раз и пишу о том что исправляется legacy код, думаю через пару месяцев перейти и обкатать свой vimrc)) Ну и спасибо за такое дело))
snovazabilparol
12.10.2017 18:34-1Вероятно я должен чувствовать себя пещерным человеком, так как ни разу не слышал про Vim ранее.
akubik
12.10.2017 18:34-2А еще + проектов типа VIM это размер 40Mb (откуда скорость)
и открытый код (независимость от корпораций и цели которые они преследуют это же не ваши цели правда?)
Вот к чему приводят современные IDE
вы считаете что об оптимальности думать не надо если ресурсы позволяют?vintage
12.10.2017 18:44+1Вы правда считаете, что 40мб для консольной утилиты — это мало?
akubik
12.10.2017 21:33всё в нашем мире относительно, сколько весит современный IDE?
да и никто и не говорит что VIM предел совершенства
а VIM в чистом виде 2 Мегабайта всего (консольный)
не консольный, это уже GVIM
serf
12.10.2017 19:25это размер 40Mb (откуда скорость)
Это каким образом размер пакета с программой коррелирует со скоростью ее работы?
вы считаете что об оптимальности думать не надо если ресурсы позволяют?
Я считаю что оптимальный размер программы это далеко не всегда приоритет. По ссылке выше речь идет о мобильных апликухак, например для десктопа как правило размер пакета с программой не так критичен.akubik
12.10.2017 21:45согласен с Вами связь не прямая, но тяжеловесные программы это медленнее, или что там для веса? Медиа? или код который заведомо не нужен, потому что он не исполняется. Критично или не критично не столь и важно, получилось много кода потому что так получилось?
очень много качественного софта написано именно на C (и их вариаций), потому как очень близок к ASM, а на нём долго, но зато качественно, это просто другой уровень многим не надо… а консольные приложения достаточно аскетичны вот за это в том числе их и уважают, есть вообще виртуозы терминалов и командной строки… работает всегда везде и быстро. так что пусть будет многообразие и Мир и дружба и жУвачка
mdErrDX5341
12.10.2017 19:07Автор статьи скорее просто объяснил одну из причин удобства vim, и указал что это не исторический факт.
Я могу сравнить работу в vim и без него с десятипальцевым методом набора текста.
В свое время я печатал достаточно быстро обходясь только 4 пальцами, делал много попыток научится слепому набору текста и первое время приходил к выводу что оно и не особо нужно. Конечно со временем научился, скорость набора не особо возросла, но удобство переоценить не возможно.
Так же и с вимом, пытался научится раза 4…
Но вот так вим это не про скорость набора текста, это про удобство. Десятипальцевый метод не только набора текста, а редактирование, изучение… Многих файлов.
Единый интерфейс работы с файлами, с гитом и т.д. так как буферы ведут себя одинаково.
Без разницы на какой ЯП надо переключится.
Руки всегда в одном удобном положении, по факту вы вообще забываете о руках так как со временем все переходит в моторную память.
Единственный минус это порог вхождения, не каждому оно нужно, не у каждого на это есть время.
Но есть один факт, не знаю еще не одного кто пользовался вимом и окончательно перешел на IDE.
lolipop
12.10.2017 19:23Киллер-фича(пишется через дефис, автор) VIM — то, что задержка между нажатием кнопки и появлением символа на экране — минимальна. Большинство ide имеют весьма существенную задержку.
solarplexus
12.10.2017 19:46+1Не нравится — не ешь(те). Бессмысленно переубеждать пользователей, кто уже юзает vim. Глупо отговаривать новичков попробовать vim и сформировать свое мнение. Я 10 лет назад начал изучать китайский, потому, что его никто не знал (и он не был на тот момент попсовым, как сейчас). 5 лет назад я начал изучать Ruby, потому, что о нем никто не слышал (я до сих пор живых людей не знаю, а тем более в своем городе… Немного утрирую, конечно). Я пользуюсь vim, потому, что это неудобно вам.
maxfox
12.10.2017 19:57Как-то не встречал активно агитирующих вимеров, чаще наоборот — пользователи IDE пытаются доказать, что ты не прав и должен обязательно пользоваться их любимой IDE (возникает ощущение, что у JetBrains есть какая-то секретная реферальная программа). Мне вообще все равно, кто в чем пишет код, главное что мне удобно. А уж то, что вимеры, которых насильно сажают за IDE, начинают нервно материться… Ну, представьте, что вам оставили два пальца из десяти и заставили печатать — ощущения похожие. Это просто привычка, тут нет никакой идейной вражды. Наверное, так же себя ощущают люди, привыкшие к dvorak, если их усадить за машину с qwerty — беспомощно.(Сам я dvorak не пробовал, так что не знаю).
mdErrDX5341
12.10.2017 20:07активно агитирующих вимеров нет по одной причине…
Так как мы понимаем что переход на вим это долгий и в какой-то мере тяжелый труд))
Я лично многим даже советую не пытаться на него переходить, так как знаю настанет момент когда от вима отказаться будет тяжело, но окромя него надо будет знать много дополнительного софта, а в IDE это уже есть да еще и в едином интерфейсе(хотя после вима понятие единого интерфейса очень сильно меняется)
flastir
12.10.2017 20:04Противопоставлять Vim и IDE — это неправильно. Мне приходится работать и в Visual Studio, и в продуктах от JetBrains, и в Vim удаленно через SSH. В итоге во всех IDE я ставлю Vim-плагин, потому что это повышает продуктивность и позволяет править код высокоуровневыми командами. Например, нужно отредактировать кусок JSON ...{«id»:15416999, «mgs»:«Очень длинная строка, которая не помещается на экран»}… — увеличить значение id на единицу и полностью изменить значение поля «msg». Что делает программист в IDE без Vim-плагина? В уме решает задачу id+1, определяет, что нужно поменять 6999 на 7000, тыкает мышью в конец числа, четыре раза нажимает Delete, вводит 7000 (и здесь есть отличная возможность ошибиться в количестве пробелов), затем мышью (или стрелками) выделяет текст, который нужно изменить (эта задача усложняется, если текст не помещается целиком на экране или занимает несколько строк). Куча лишних низкоуровневых действий, которые отвлекают мозг от решаемой задачи. Что делает программист в IDE с Vim-плагином? Нажимает Ctrl+A, чтобы увеличить ближайшее число на единицу (курсом при этом не обязан находиться на числе). Далее нажимает 3f" — перейти (f=find) к третьей двойном кавычке от текущей позиции, курсор теперь находится на двойной кавычке перед словом «Очень». Далее нажимает ci" — изменить (c=change) содержимое (i=inner) внутри двойных кавычек, и при этом не важно, где эти кавычки заканчиваются. Можно сказать, что данный пример синтетический, но он показывает, что Vim — это не редактор, а способ взаимодействия программиста с редактором.
evnuh
12.10.2017 20:47+1Куча лишних низкоуровневых действий, которые отвлекают мозг от решаемой задачи
Это вы сами придумали. И это ложь.
В виме вы сидите и вспоминаете и составляете цепочки клавиш, которые нужно нажать, чтобы добиться результата. Плюс этого только в одном — это можно делать не смотря в монитор.
А я просто использую глаза, смотрю в монитор, жму стрелку с контролом, пока курсор не доедет до кавычки и удаляю что выделил. То есть я просто слежу за курсором, ничего не вспоминаю и не генерирую эти 3f" ci". Ну не люблю я думать, мне проще на экран посмотреть и подвигать мышкой.Delphinum
12.10.2017 20:52Чтобы выполнить замену в кавычках (ci") не нужно ничего вспоминать, мозг прекрасно справляется с этим на уровне подсознания.
flastir
12.10.2017 20:54В виме вы сидите и вспоминаете и составляете цепочки клавиш, которые нужно нажать, чтобы добиться результата.
Это только вначале трудно, как и с любым изучением чего-то нового. Потом мозг привыкает и радуется, что можно виму передавать высокоуровневые команды напрямую (вроде, увеличь ближайшее число на единицу), а не разбивать их на «тыки сюда» и «тыкни туда».
mdErrDX5341
12.10.2017 20:55В vim'е я лично не вспоминаю команды и не пытаюсь делать цепочки, через какое то время это происходит автоматически, я не отрываю взгляда от монитора, не ломаю себе мизинец, не отдергиваю руку к стрелкам или мыши. И вообще счастлив только от того что мой мозг занят только задачей, и не ломаю глаза следя за курсором… и т.д и т.п.
VMichael
12.10.2017 21:09Хм.
А может программист в IDE нажимает Ctrl+R (заменить текст). Вводит 6999 в одну строку, 7000 в другую и редактор сам находит и заменяет?
А потом, откуда программист знает, что Id = 6999, а не 6998, может на него нужно посмотреть?
Я занимаюсь в настоящее время интеграцией разного рода оборудование и проходится постоянно курить мануалы, мозг забит инфой и убейте меня, но не заставите еще выучить тучу комбинаций Vim, что бы сделать элементарные действия.Delphinum
12.10.2017 21:17убейте меня, но не заставите еще выучить тучу комбинаций Vim
Та никто и не пытается, хз чего у людей так печет, когда они узнают, что кто-то пользуется vim.mdErrDX5341
12.10.2017 21:38у людей печет так как у них не получилось, теперь оправдываются как они commit делают мышкой)))
Шутка, это всего лишь шутка...
VMichael
12.10.2017 22:50Как раз у людей не печет. Печет у тех, кто хором утверждает: нужно выучить комбинации Vim и тогда будет счастье кодирования вслепую, не отвлекаясь на оттягивание кисти к цифровым стрелочкам (как будто только это может помешать написать хорошую программу).
mdErrDX5341
12.10.2017 23:00я не заметил таких комментариев, скорее заметил что многим удобно работать по другому, хотя автор просто написал что режимы это одна из фичь, а не пережиток старого…
ну и многие начали мерятся хоткеями)))
Delphinum
12.10.2017 23:04Как же не печет, если к статье уже написали +200 коментов? ) Видать народ считает себя оскорбленным заявлениями вида: «печатать удобнее слепым, десятипальцевым методом без мыши и вспомогательных клавиш типа стрелок»
VMichael
12.10.2017 23:06Скорее наоборот.
Оскорбляют заявления вида: Мне ваш Vim метод вообще не нужен.mdErrDX5341
12.10.2017 23:24Хотя бывает многих бомбит, так как те кто используют IDE пытаются сравнить ее с редактором, показывая окна с функциями далеко которыми редактор не должен обладать, что как-то странно.
Я то сам использую IDE в классическом понимании этого слова, хотя для меня IDE это рабочий пк.
Danik-ik
14.10.2017 13:53Если Вы оскорбляетесь на такие заявления, то это зря. Какое Вам дело, простите за мой нефранцузский, до того, что не нужно МНЕ? Вот если Вам скажут, что ВАМ он не нужен, тогда и будете рефлексировать с полным на это правом.
А мне таки Вим не нужен — ну не полюбил я его, и не хочу. Мне этого достаточно.
Тем не менее, при этом я категорически отвергаю всяческую сегрегацию по признаку отношения к Виму. Хорошо, когда мы разные. Не скучно.
VMichael
14.10.2017 23:01-1Вы не правильно поняли коммент.
Меня ничего не оскорбляет.
Сам я Vim не пользуюсь.
mdErrDX5341
12.10.2017 23:15Не знаю, может кто-то и считает, все люди разные…
Мне удобнее в виме, без стрелок и не смотря на клаву и мыши. Если удобнее по другому, значит выработался другой подход, походки у всех тоже разные))
mdErrDX5341
12.10.2017 21:25Вас не заставляет кто-то учить…
Но такая заметка, в виме комбинации не заучиваются, а строятся.
По этому в нем и легко работать, но переучить свой мозг с вижу и нажимаю, на думаю и строю не дается за 1 день, привычку со стандартной работой в духе блокнота сломать сложно(так как это привито с самого начала работы с текстом за ПК) и с наскока не получается.
Так что работайте как Вам удобнее, тем более если уже сложились определенные паттерны работы с кодом.saboteur_kiev
14.10.2017 01:22Это верно.
Часто публикуют «парочка удобных способов сделать что-то в vi/vim», и просто набор букв. Если их запомнить, не понимаю простые команды из которых строится комбинация — это не самый лучший способо освоить vim.
Лучше все-таки разобраться как эти команды работают, и как только это понимаешь — на ходу можешь составлять конструкции, которые будут выполнены совершенно четко, без необходимости ждать отклика от vim.
Возможно это чаще востребовано при администрировании. ВСЕГДА есть парочка серверов, которые находятся непонятно где, либо на которых крутится что-то тяжелое, что тормозит даже консоль. И вот тут vi на высоте.
jced
12.10.2017 20:30Спасибо, за, очень, интересную, статью. Хоть, и, пользуюсь, вим-ом, почти, каждый, день, а, все равно, нашел, что-то, новое!
ZaitsXL
12.10.2017 22:41Хабр, ну у вас же вроде какая-нибудь модерация есть. Зачем же она пропускает статьи начисто лишенные информативного содержания? Зачем нам эта субъективная ненависть?
poxvuibr Автор
13.10.2017 05:42Зачем нам эта субъективная ненависть?
Вы увидели ненависть в тексте статьи? Процитируйте, пожалуйста, я подредактирую пост и ненависти больше не будет.
ZaitsXL
13.10.2017 12:00У вас во всей статье основной аргумент «мне не нужно/неудобно — значит всем не нужно/неудобно», это аргумент школьников
poxvuibr Автор
13.10.2017 12:06Я ничего такого сказать не хотел. Наоборот, я хотел сказать, что если вам не удобны или не нужны режимы, то скорее всего вам не нужен весь вим и тратить время на выяснение почему другие пользователи терпят наличие реживом — не стоит. Они из-за режимов в виме и сидят.
dmitry_ch
13.10.2017 01:36«У vim есть два режима: в одном он пищит, в другом портит текст.»
mdErrDX5341
13.10.2017 01:41У программиста есть два режима: в одном он спит, в другом он шкодит
dmitry_ch
13.10.2017 01:43«Три года писал только в vim: не мог выйти.»
mdErrDX5341
13.10.2017 02:04Три года шкодил в vim: не мог выйти, на 3 год понял что такое юникс вей)))
xvilka
13.10.2017 03:00Neovim еще удобней — с его встроенным :terminal и асинхронностью. Я часто копаюсь в сторонних исходниках программ на самых разных языках — настроил neovim + vimpager как PAGER и теперь использую просмотр с подсветкой синтаксиса и возможностью сразу перейти в режим редактирования или открыть сплит/таб. Ну и интеграция с tmux и zsh тоже очень удобна. Автодополнение кода тоже при желании можно настроить, для многих языков, но мне, имхо, кажется несколько тормозит, особенно на больших кодовых базах, типа LLVM.
ZyXI
13.10.2017 09:28И :terminal, и асинхронность Брам уже переписал, не очень совместимым образом. IPC API на msgpack или эквивалента как у Neovim нет, и
:terminalболее нов и менее стабилен, но, тем не менее, асинхронные задачи, таймеры и терминал в Vim сейчас есть.
Nondv
13.10.2017 03:03Я пользуюсь имаксом, а некоторые коллеги вимом, по одной причине — нам нужен мощный и удобный текстовый редактор, а не набор плюшек в виде IDE. Это особенно актуально для динамических языков и простого набора текста
Как-то услышал, как какой-то парень сказал: "RubyMine (Idea) — в большей степени хороший текстовый редактор и все его любят в основном за это.". В этот момент еле сдержался, чтобы не засмеяться во весь голос.
IDE хороши. Реально хороши. Но признайте, что работа с текстом намного круче в виме и имаксе. Имакс — это вообще по сути интерпретатор лиспа с интегрированным текстовым редактором.
mdErrDX5341
13.10.2017 03:11emacs это OC спрятанная под редактор текста))
Nondv
13.10.2017 03:16Это забавная шутка, но вот многие пользователи имакса считают, что имакс слишком мало походит на ОС и это плохо.
Я бы вот хотел открывать веб-страницы в имаксе и удобно ими пользоваться, но это не очень реально, хотя в имакс уже внедрили поддержку движков браузерных.
Или в телеграме сидеть из имакса. Или проигрывать фильм/музыку в одном из окон (часть экрана) имакса.
Предвидя комментарии вида "да это уже есть", отвечаю: есть, но корявое и неудобное.
mdErrDX5341
13.10.2017 03:19это старая шутка))) есть такая еще одна…
emacs единственное что не умеет это варить кофе))EvilBlueBeaver
13.10.2017 20:07Вот старая шутка.
Emacs — отличная ОС, жаль в ней нет нормального текстового редактора.
Nondv
13.10.2017 03:18Кстати, стоит упомянуть, что владение имаксом очень помогает при работе в других программах, т.к. основные сочетания клавиш зачастую используют имаксовские.
Примеры:
- bash
- tmux
- Google Chrome
P.S. по-моему, я ошибся постом
mdErrDX5341
13.10.2017 03:26а тут без шуток, после вима от этих горячих клавишь болят руки… действительно тяжко зажимать постоянно ctrl, против emacs не чего не имею, но для моих рук это боль в прямом смысле, хотя играю на гитаре, хотя, на гитаре всегда тоже есть стремление к минимум движению руки и пальцев
Nondv
13.10.2017 03:32Ну это уже вопрос личных предпочтений. Мне больше нравится зажимать мизинцем капс (на котором ctrl забинден) нежели переключаться между режимами. Для меня это стало естественным процессом работы с текстом еще до имакса: либо пишу, либо зажимаю особенную кнопку, чтобы выполнять особенные действия.
Вот кстати. Если бы Вы занимались обычным набором текста (книгу писали, например), то стали бы использовать залипание шифта? Это ведь тоже нечто близкое к режимам.
khim
13.10.2017 04:37либо пишу, либо зажимаю особенную кнопку, чтобы выполнять особенные действия.
Я так понимаю, что позиция сторонников VIM'а заключается в том, что «особенные действия» — это как раз «тупой» ввод текста! То есть большую часть времени вы делаете что-то другое: вставляете управляющие конструкции, двигаете что-то куда-то и так далее. И вот только тогда, когда всей мощи редактора не хватает — вы опускаетесь «на уровень машинных кодов»… и просто «вбиваете» текст!
kiba
13.10.2017 04:32Срываю покровы: основная киллер-фича командного режима — это ".". Без неё все эти J, cit, dw недостаточно эффективны, (т.к. обычный человек редко знает точное число повторений действия), а с «точкой» можно этим пренебречь не в ущерб скорости. Ну и такая работа позволяет перестроить сознание, и думать о тексте, как о наборе сущностей: слово, строка, параграф и т.п. Ну и далее уже более продвинутые техники, типа макросов: qa сделал обработку текста Esc @a @@@@@@ и т.д.
LazyTalent
13.10.2017 05:36Очень люблю vim, но…
Основными инструментами в работе являются pandas и beautifulsoup. Для автокомплита использовал ctag. С пандами еще как-то можно было жить — правда необходимо ждать по полминуте, пока автокомплит очухается, а вот с супом… намертво вешает эмулятор.
YellowRaven
13.10.2017 05:37VIM работает в двух режимах: в одном — бибикает, а в другом — всё портит.)
netch80
13.10.2017 11:05> Речь исключительно о том, что с использованием режимов пользователям вима работать удобнее и приятнее. Или, по крайней мере, они в это искренне верят.
Предпочитаю vim. Считаю, что режимы в описанном виде — не единственный и не обязательный вариант.
Вообще, по местной традиции такую статью следовало бы сопроводить голосованием — считаете ли режимы важнее возможностей, или наоборот.
maydjin
13.10.2017 17:00Для меня у vim есть ещё как минимум одна киллер фича:
с ним можно работать по ssh(не в смысле редактировать удалённые файлы, а в смысле с самим редактором). Учитывая что конфиг мой для bash, vim, tmux и прочего деплоиться примермно так:
git clone vimrc && ./vimrc/deploy.sh
Это дюже удобно, особенно если иметь с десяток другой окружений, меняющихся время от времени.
Код однако, я пишу в IDE (плюсовый), питонячий таки в виме.
mdErrDX5341
13.10.2017 20:10+1Шутки ради…
Надо не проeписать, а проxвместоbackspace.
А также проf{sumbol}vU
ma,'a
qa(.*)
xp
такие элементарные действия, которые работают на автомате, не знаю как это сделать в IDE)))mdErrDX5341
13.10.2017 20:42кстати из того что замечал, так сказать разницу между разработчиками…
не подумайте что это я кого то хочу обидеть, такое обычно встречается у начинающих, а начинающие как правило работают в IDE, так как там более комфортно, так сказать во все оружии…
Вимеры обычно открывают IDE, документацию, накидывают что то в виме, на листочке еще каким то образом…
Те кто используют IDE, обычно пытаются с ходу писать код, полагаясь на подсказки в разных окошках и т.д.
Через какое то время вимер начинает сумашедше стучать по клаве...
Нюанс какой, как правило у вимеров в крови это разделять операции, изучить, подготовить материал, поработать с бд, потестить сервис, переработать схему накиданую ранее,… а потом беспощадно стучать по клавиатуре, от сюда и желание к удобству написания и редактирования текста.
Разработчки в IDE обычно делают все тоже самое за одно и тоже время, но как то строят систему ее наращивая, в чем собственно IDE и помогает.
Повторюсь что обидеть не кого не хочу, просто замечал такое, статистики нет, графиков нет… так что субъективное.
VMichael
13.10.2017 23:32Очень субъективное.
mdErrDX5341
13.10.2017 23:41Очень, очень субъективное…
Опять же субъективно..., так как Vim не позволяет сделать многое через плагины(полноценной работы с гит, работы с БД, построение дерева зависимостей наследования, и многих подсказок...) пользователи вим используют как правило специализированный софт что бы получить полную картину, и куда то в виме ее черкают, в виде набросков, комментов, где то UML, кто как умеет....
в IDE обычно сразу набрасывают код вполне рабочий, но сам процесс совершенно другой, менее дескретный.
это субъективно...
VMichael
14.10.2017 00:53Сначала думать, потом делать свойство любого нормального программиста.
IDE, Vim или еще что то тут совершенно не при чем.
Это другая тема для разговора.mdErrDX5341
14.10.2017 01:28полностью согласен, субъективно… повторюсь(есть любители насрать в карму))) ), дискретность, декомпозиция, разделение на атомарные операции должны быть конечно у каждого программера в голове, просто я часто замечал что у вимеров это как то уже в подкорке мозга, субъективно
с IDE, обычно пишут также разделяя, но обычно не настолько сильно разделяют иммено действия, обычно пишут в потоке, тоесть пользуясь IDE
mdErrDX5341
14.10.2017 01:42Тут даже хочется сделать эксперимент, взять и отобрать IDE и VIM…
скорее всего результат напрашивается…
Vim заставляет думать в духе unix way… одно но хорошо работающее…
СУБЪЕКТИВНО
mdErrDX5341
13.10.2017 22:42прямо с вики…
Другие положительные стороны слепого набора текста:
Физическое здоровье— осанка, зрение (избавляет от сутулости, позволяет разместить клавиатуру и монитор в удобные для такой работы места, в частности поместить монитор на оптимальное для глаз расстояние).
Психическая утомляемость(меньше умственных усилий на набор текста и выполнение необходимой работы, меньше ошибок и связанного с ними раздражения)
Гораздо более высокая производительность. Высвобождение возможностей для более эффективного выполнения большего количества и объёма задач.
И как писали, меньше отвлечения, чем меньше движений и координаций надо делать нашему мозгу, тем проще и меньше усталость… как игра на гитаре, чем правильнее постановка рук тем лучше, как в единоборствах чем короче движение тем оно более быстрее и эффективно...
как правило это все физиология, не каждому дано работать в emacs, но в виме можно даже ребенку работать...
Но учится этому долго, как игре на гитаре, как единоборствам… не всем оно нужно.
mdErrDX5341
14.10.2017 02:56-1а ну и забыл…
Давай минус ананимус)))mdErrDX5341
14.10.2017 03:37вот один уже есть, но ты забыл про карму, она пока стабильна… давай жги ананимус, комментов от тебя не жду)))
Singaporian
14.10.2017 07:11Ваша статья — Esprit de l'escalier.
На самом деле не это киллер-фича vim'а. У него она другая. Заключается она в том, что если тебе часто приходится править код прямо на сервере, тебе не надо «переключать мозг» в режим другого редактора. Например:
- Не надо вспоминать, как работает консольный дебаггер.
- Не надо вспоминать другой комплект комбинации клавиш.
- ...
Но все это уходит в ноль для тех, кто пишет код только на своем десктопе. Неактуально и все равно забудется через неделю.vintage
14.10.2017 10:48Никогда не понимал тех мазохистов, что правят код прямо на сервере.
Singaporian
14.10.2017 11:19Значит либо вы новичок, либо ваши задачи позволяют все делать в IDE.
У вас упало приложение на одной из нод на проде. По логам непонятно, что произошло — дебаг логи отключены в проде. Как воспроизвести в лабораторных условиях, вы тоже не знаете (может оно без нагрузки и не воспроизведется).
Каковы ваши действия по поиску дефекта?vintage
14.10.2017 18:25Конечно же я попрусь править код на сервере, чтобы уронить вообще всё к чертям.
Singaporian
14.10.2017 19:48Сарказм был бы уместен, если бы у вас был ответ, как искать ошибку в условиях, что воспроизводится она только в проде.
VitalKoshalew
16.10.2017 06:39+1Откатить на предыдущую версию. Завести, наконец, Staging. Убрать с Prod (=DMZ, по определению) исходники. Не давать программистам права на запись на Prod.
Нет, я не спорю, без best practices, особенно в плане безопасности, жить порой значительно проще: залез на Prod, вдоволь прямо там поотлаживал, может быть, на самом деле, быстро нашёл ошибку. А, может быть, повредил Prod базу, привёл к потере/повреждению/раскрытию данных клиентов, удлинил простой, привнёс новую уязвимость.Singaporian
16.10.2017 07:34+1Откатить на предыдущую версию. Завести, наконец, Staging. Убрать с Prod (=DMZ, по определению) исходники. Не давать программистам права на запись на Prod.
Вы не поняли проблему. Проблема не в том, что на проде баг и надо срочно суетиться и что-то решать. Нет, все спокойно. Проблема в том, что его надо найти так или иначе. Хоть на проде, хоть на стейдже, хоть за диваном.
1. Откатить на предыдущую версию не получится — вы же не откатите миграции СУБД. Да и баг это вам найти не поможет. Вы от него избавитесь до следующего апгрейда.
2. Стейджинг вам не поможет. Допустим это нашли в стейджинге, а не на проде. Но в стейджинге тоже нет IDE.
3. Убрать исходники — вообще тут причем? Тогда у вас не останется вообще ни одного места, где можно найти этот баг.
4. Не давать программистам права на запись на Prod — и как это дает возможность найти баг?
Прочитал и второй ваш абзац. Решение проблемы так и не увидел. Подчеркиваю: не проблемы безопасности прода, а проблемы поиска бага, который воспроизводится только в боевых условиях и то случайно.VitalKoshalew
16.10.2017 09:33+21. Такие действия, у которых в графе «Backout plan» стоит прочерк, вообще говоря, лучше не предпринимать. Как правило, можно найти чуть менее простой вариант, но с нормальным планом отката. Если же мы всё же избавимся от бага при откате, то апгрейд мы никакой делать не будем до тех пор, пока на Staging не сможем повторить проблему.
2. На Staging мы можем безболезненно выкатывать любые отладочные версии, которые уже дадут нам ответ, где именно и что ломается. В идеале, и в Prod у нас должно быть достаточно обработчиков исключений, assert-ов и т.д., чтобы программа упала с хоть каким-нибудь stack trace. Что же до IDE, то он есть у программистов на их рабочих станциях, с которых они на Staging и деплоят стандартными средствами.
3. Сервер в DMZ по-умолчанию считается потенциально скомпрометированным. Выкладывать на него исходные коды можно только если вашей компании их совсем не жалко. Мне не совсем понятно, как вообще лежащие рядом со скомпилированным байт-кодом исходники могут помочь в поиске ошибки.
4. Следование best practices, как я уже написал выше, не облегчает, а, скорее, усложняет поиск ошибки, это верно. Почему им, всё же, лучше следовать, я тоже уже написал.
Прочитал и второй ваш абзац. Решение проблемы так и не увидел. Подчеркиваю: не проблемы безопасности прода, а проблемы поиска бага, который воспроизводится только в боевых условиях и то случайно.
Лирическое отступление«Чтобы вступить в рукопашный бой боец спецназа должен потерять на поле боя: автомат, пистолет, нож, поясной ремень, лопатку, бронежилет, каску. Найти ровную площадку на которой не валяется ни одного камня, палки. Найти на ней такого же растяпу. И только после этого, вступить с ним в рукопашную схватку.»Singaporian
16.10.2017 08:00+2О! Вот вам пример из жизни. Прямо трехмесячной давности.
Мы протестировали ПО, оно прекрасно даже работало у нескоторых заказчиков. И вот в японской армии перестал обрабатываться MODBUS-траффик. То есть траффик идет, приложение слушает интерфейс, а не видит траффик.
В прод они издалека не пускают — сеть изолирована от интернета вообще. Траффик свой они нам тоже не дадут — он секретный.
Вот когда наш сотрудник туда приехал (с исходниками нашего ПО, кстати), он увидел, что в траффике часть чексамов идет обнуленными из-за того, что пакеты резаные от исходного PLC и бридж их дропает.
Вот мне очень интересно, как такое можно обнаружить было дома в Израиле на расстоянии 9000 километров в сухом и теплом IDE.
__
А в том месяце наше приложение перестало нормально работать в другой организации, потому что они… починили сервер. То есть у них сгорел сетевой интерфейс. Они его поменяли. MAC, соответственно, новый. В udev-persistance он получил свой новый адрес (eth7). А приложение сконфигурено было до ремонта на другой сетевой адрес (eth4). Эту проблему легко найти и легко починить. Но пойдите догадайтесь про udev-persistance в тестовой среде, где интерфейсы не ломаются, не меняют своего имени и не вынуждают копать в этом направлении.VitalKoshalew
16.10.2017 09:50+1… Вот мне очень интересно, как такое можно обнаружить было дома в Израиле на расстоянии 9000 километров в сухом и теплом IDE.
У вас проблема с сетевой инфраструктурой. При чём здесь программисты и IDE/vim?
...MAC, соответственно, новый. В udev-persistance он получил свой новый адрес (eth7). А приложение сконфигурено было до ремонта на другой сетевой адрес (eth4). Эту проблему легко найти и легко починить. Но пойдите догадайтесь про udev-persistance в тестовой среде, где интерфейсы не ломаются, не меняют своего имени и не вынуждают копать в этом направлении.
Мы всё ещё говорим о программистах и их IDE? Программист вообще не должен знать ни о каких eth7, у него максимум переменная из файла конфигурации должна считываться. В идеале, в виртуальной машине, в которой исполняется программа, интерфейсы вообще никуда не могут «убегать».
Всё остальное — забота админов/инженеров.Singaporian
16.10.2017 10:43Собственно, вы только что продемонстрировали непонимание принципов DevOps, в основе которых лежит основополагающая позиция: нет своей территории девов и нет своей территории опсов. Есть только взаимная ответственность на всем протяжении лайфтайма.
YetAnotherSlava
16.10.2017 08:35Да, а давайте на «проду» (слово-то какое мерзкое) еще и maven после этого поставим, чтобы правки собрать.
Ваши советы годны только для php и тому подобных перлов с рубями, где действительно обстановка располагает и даже стимулирует к правкам на проде и тому подобной ереси.
У нас показыватель котиков упал, котострофа! Сделайте что-нибудь вслепую на проде, где мы отключили логи из мелочной экономии! Сделайте в стиле хакера из Swordfish, за две минуты!
Не надо в таких местах работать.
Кстати, правка кода на проде встречается — но совершенно другого вида. Изменение хранимок SQL. Вы их тоже Vim'ом будете править?mayorovp
16.10.2017 08:49
Очевидно, хранимки SQL — это второй случай, когда задача позволяет решать ее в IDE.Значит либо вы новичок, либо ваши задачи позволяют все делать в IDE.
Кстати, правка кода на проде встречается — но совершенно другого вида. Изменение хранимок SQL. Вы их тоже Vim'ом будете править?
mayorovp
16.10.2017 10:05+1О, вот вам пример когда мы правили файлы на сервере. Правда, обходились без vim потому что винда.
Дано: ферма серверов на Sharepoint. У заказчика есть свое ПО, с которым мы обязаны интегрироваться — и мы его третий месяц не можем поставить на Staging (а до этого год не могли допроситься у заказчика актуальной версии этого ПО).
При выкладывании на прод пролезла опечатка, из-за которой одна из страниц не работает. Что делать?
Вариант 1. Передеплоить проект, запросив технологическое окно в 8 часов. Риски — можем не уложиться в это окно; после деплоя могут всплыть еще ошибки.
Вариант 2. Исправить файл на сервере. Риски — в худшем случае поломаем еще одну страничку из сотни; но скорее всего успеем и эту ошибку отловить прежде заказчика.
Ну и какой вариант оптимальнее?
Нет, потом-то мы и staging настроили, и время деплоя сократили до 30 минут (а частичный вообще 5 минут идет всего), и даже CD настроили. Но это было только через полгода...
andrejev
14.10.2017 07:51Автор явно не работал с очень большими проектами, где всеми любимые IDE на Java умирают. Большой проект на C++ в CLion не может съиндексироваться. Про дебаг можно забыть тоже. tmux + vim + gdb || emacs + gdb единственный вариант работы.
hippoage
14.10.2017 15:33Можно посмотреть со стороны сценариев использования редакторов:
— Чтение и навигация по коду
IDE лучше: доп. подсказки (error, warnings), остальное на +- том же уровне, если донастраивать VIM
— Вставка текста (режим INSERT в VIM)
IDE лучше: доп. подсказки (error, warnings), автоисправления, остальное на +- том же уровне, если донастраивать VIM
— Отладка: IDE лучше, очень много всякого в деталях и UI
— Небольшие правки: не важна скорость правок, т.к. примерно то же самое, а вот
доп. анализ как раз хорош (и возможность интеграции с дебагером)
— Более крупные правки: тут как раз VIM заявляет о своем превосходстве. Такие правки
распадаются на вставку текста, рефакторинги и действительно изменения текстаю В IDE
предусмотрены рефакторинги, которые закрывают значительное количество случаев
необходимости правки в нескольких местах (переименование, выделение переменных и методов,
перенос методов между классами, изменение сигнатур методов). При этом исключен
человеческих фактор (опечатки, что-то где-то забыл допереименовать). Т.е. признаю,
что множество мелких правок удобнее делать в VIM, но таких случаев крайне мало
в моей практике крайне мало, а в остальном IDE удобнее.
IDE слабы в поддержке экзотических языков, но для этого есть соверменные
редакторы (по сути полуIDE): Atom/VSCode.
VIM лучше:
— изменение конфигов на сервере через ssh (хотя не очень хорошая практика)
— слабая машина, которая не тянет и современные редакторы Atom/VSCode
— ореол избранности (он на VIM пишет), вполне адекватная причина использования
— действительно приходится много редактировать без возможности использовать
рефакторинги и автопроверки IDE
В остальном все-таки IDE эффективнее.mdErrDX5341
14.10.2017 17:48я уже писал про дискретность операций, все вимеры понимают что вим это редактор, и не пытаются делать то что вы делаете в IDE, для этого всего есть другие приложения которые лучше справятся с этой задачей(и даже лучше чем IDE), по этому и шутка была про unix way…
правда заминусили, наверное не поняли))) но повторюсь
Три года шкодил в vim: не мог выйти, на 3 год понял что такое юникс вей)))
hippoage
14.10.2017 20:19Еще раз: vim может быть эффективней для отдельных видов работ, но их объем в командах (в которых работал) незначителен, а, из-за минусов, программист с VIM проигрывает программистам с IDE (при прочих равных).
Например, даже 1 ошибка, замеченная IDE и исправленная оперативно, может экономить минуты и, иногда, часы времени, а разница в скорости правки столько не даст. Довольно много раз находил NPE в Java проектах при code review таким образом (ну как находил… просто читал подсказку, которую не осилил прочитать первоначальный программист).
Удивляет частая аргументация, что vim лучше, а если кто-то думает не так, то он:
— некомпенентент
— не умеет работать в vim
— если даже умеет (например, использую его для правки настроек на тестовых серверах, хотя все реже с внедрением практик DevOps), то, значит, умеет недостаточно
Не знаю приложений, которые лучше справятся с отладкой, чем IDE. Да и про другие приложения как-то примеры на ум не приходят.
А про Unix way вы сами себе противоречите (ниже в комментарии): то IDE вызывают внешние команды (и это плохо), то IDE реализуют что-то внутри (и это плохо). Понятно, что сейчас никто не будет что-то реализовывать самостоятельно, если есть возможность адекватно переиспользовать что-то существующее.mdErrDX5341
14.10.2017 22:02вы меня слышите? vim дает возможность удобно редактировать текст… а
ваша одна ошибка означает что вы не пишите тестов, это не как не относится к IDE или к Vim… я не писал что плохо вызывать внешние команды… почитайте про интерфейс к CLI программам, про микросервисы, ...codemax
15.10.2017 09:51+1И при чем тут тесты? Понимаете, если человек не увидел возможность использования null-значения и не сделал соответствующую проверку, то он и тест на это не написал бы, т.к. он не видит этого кейса. Тесты обычно пишут, чтобы в будущем не сломать заложенное при изначальной разработке поведение. Ну и пишут еще тест, когда NPE уже всплыло, чтобы больше такого не было.
hippoage
15.10.2017 15:51Мне кажется, вы меня не слышите. Действительно, vim дает возможность удобно редактировать текст. Но разница с современными редакторами (что IDE, что Atom/VSCode/...) незначительна.
Есть проекты в которых не принципиально наличие дополнительных функций из IDE. Например, сам не использовал IDE для Ruby on Rails проектов на несколько разработчиков на несколько лет: и объем кода небольшой, и динамические языки тяжело поддерживаются IDE (при этом был купленный RubyMine, но не пошел).
Если же объем кода большой и язык со строгой типизацией, есть много подсказок в IDE по типичным ошибка программирования на этом языке и на этой платформе (как в IDEA для Java), то слишком расточительно не пользоваться этим.
По поводу обвинений в некомпенетности (тесты, cli, микросервисы), то не надо так. В предыдущем комменте писал, что это моветон. Применение этих техник не означает, что VIM по сумме показателей вдруг становится более эффективным, чем IDE. Вы правда думаете, что новые редакторы (Atom и Visual Studio Code) написали люди, которые ничего не слышали о VIM? Если их написали таким образом, каким написали, то все-таких Emacs победил в споре с VIM, хотя и сам умер.
mdErrDX5341
14.10.2017 17:57я разделяю процесс создания архитектуры и блабаблалалала, до процесса написания кода…
меня раздражают эти долбанутые подсказки IDE мигание на моих 2 мониках всякой ерунды, я и без того знаю где я мог ошибиться, а где сейчас не соответствует код стайлу мой код, зачем мне вся эта мешура? я и без IDE напишу как надо… а когда мне понадобится работать с БД я открою соответствующее приложение, когда мне надо будет закомитить, я воспользуюсь гитом, а не IDE
смысл в том что работа ведется по другому… каждому свое.
hippoage
14.10.2017 19:54Многие не знают. А тем, кто знает, довольно часто приходится делать code review. В этом случае автоматические проверки составляют первый этап.
Кстати, их можно отключить, если все или часть раздражают.
mdErrDX5341
14.10.2017 18:21и чем же хороша IDE, а тем что вам не надо делать рутинных задач при создании проектов на JAVA, QT… добавление картинок в проект, зарисовку UI, вот плюс, когда вы избавляетесь от рутины и отдаете это на автоматическую генерацию кода… Вот плюс IDE, хотя как правило вы просто не знаете что IDE запускает команды за вас, для того что бы вы это не делали вручную. Или как правило взяты алгоритмы с прог которые заточены под определенный функционал.
mdErrDX5341
14.10.2017 18:40Если вам нужно видеть дерево наследования, подсказки аргументов, то обычно у меня в голове два арумента…
либо у человека нет спроектированного решения, слабая память
ну или архитектура приложения овно, так как она не интуитивна...hippoage
14.10.2017 20:32Для проектов 10+ лет в большинстве случаев это не опция, а данность. Даже если оно спроектировано более-менее, то все равно размер и ограниченность в сроках не позволяет сначала досконально понять приложение, а уже только потом что-то в нем дорабатывать.
khim
14.10.2017 23:07все равно размер и ограниченность в сроках не позволяет сначала досконально понять приложение, а уже только потом что-то в нем дорабатывать.
А не является ли это типичным случаем феномена «мне некогда точить топор, мне надо рубить лес»?
Если у вас нет хорошего представления о том что это за код и что он делает — то вы точно уверены, что его «дорабатывания» пойдут проекту на пользу?mayorovp
15.10.2017 12:15Скорее это проявление "мне некогда считать число деревьев в лесу, мне надо вырубить вот эти два".
hippoage
15.10.2017 15:14Такая вероятность есть. Обычно закрывается компромиссным вариантов в виде обучения в течении недели, а затем техническое проектирование перед написанием кода и code review после товарищами, которые более знакомы с проектом.
mdErrDX5341
14.10.2017 23:36Для проектов 10+ и руководитель не понимает что там полный аут…
Скажу вам так бегите с этих проектов, если от вас требуют работать с овном и при этом не понимают что надо переделать, бегите, вы не добъетесь ровным счетам нечего.
У меня такое было, начальник отдела программирования требовал костыли на костылях… не какого гита, не какого рефакторинга, вообще не чего, только кастыли, бегите от туда, ваш ум и практику подымут где то еще...saboteur_kiev
14.10.2017 23:46«вы не добъетесь ровным счетам нечего.»
Кроме крутых проектов, на работе дают зарплату. Почему ВСЕМ программистам обязательно нужно быть стартаперами и мутить проекты с полетом на марс?
Не давайте такие советы всем подряд.
codemax
15.10.2017 10:13+1Есть проекты и 10+, и чуть меньше, и с кодом там все нормально. Не идеально, есть к чему стремиться, но уж точно не говнокод и не полный аут. Но вот беда — кода много, много бизнес-логики и всего такого. И пишет его не один Вася, который вроде бы в состоянии всё запомнить (на самом деле нет), а целая команда из 10+ человек. И чтобы поработать в той части кода, где ты еще ни разу не был/недавно что-то существенно поменяли, очень хорошо помогают все эти плюшки IDE. Можно быстро окинуть взглядом общую структуру и после этого перейти к деталям. Возможно, что-то придется порефакторить — опять же IDE поможет не допустить глупых ошибок. (Тесты еще помогут, но это уже отдельный разговор, тесты не смогут заменить всё.)
И то, что вся структура кода не помещается у человека в голове, не говорит о том, что он недостаточно крут или что это — говнокод. Это всё очень странные попытки пристыдить тех, кто пользуется удобствами IDE.
hippoage
15.10.2017 15:24Работать с плохим руководителем очень плохо для сотрудников, но это не имеет отношения к IDE или сложности проектов на тысячи человеколет с несколькими поколениями программистов в текущем модуле.
VMichael
15.10.2017 00:07Тут с вами не соглашусь.
Особенно касается проектов, которые пилят много лет разные люди.
И архитектура может бы не совершенна и памяти у вас может не хватить, что бы охватить проект.
Про память тоже можно рассмотреть ситуацию. Да, памяти может не хватать, но отлично работает логическое мышление. И вот IDE дает возможность работать в данной ситуации без каких либо негативных последствий.
А советы, в комментариях ниже, отдают юношеским максимализмом: типа бегите с таких проектов, так ситуации могут быть сильно разные. Убежать можно, но вот чем платить за съемную квартиру (продукты, кредиты, учебу, детей… выберите по вкусу).
Бывает человек попал в струю, на хороший проект, получил опыт, далее пошел выше, выше и вот уже ему кажется, что любой неинтересный проект можно бросить. Но не у всех такая ситуация. Конкретная ситуация может сильно отличаться.
Конечно, любой человек будет стремиться найти лучшее, но не всегда это удается сразу и вот приходиться работать в таких условиях, хотя бы какое то время.
Я собеседовал множество разных программистов. И проходили порой товарищи у которых уровень выше, чем нам требовался. Спрашиваешь, чего к нам то, у нас скучно. Ответ — да ситуация такая на рынке, лучше нет по отношению проект/ЗП, а кушать хочется.
VMichael
После прочтения статьи еще меньше захотелось пользоваться Vim
acmnu
Не обязательно использовать сам vim. Почти в каждой популярной IDE есть vim плагин, который покрывает существенную долю функций vim. Кроме плагинов разумеется, но это скорее плюс :)
t0pep0
Пользуюсь vim несколько лет, сколько не пробовал vim-плагины к IDE всегда плевался.
poxvuibr Автор
Я пользуюсь плагином к Intelij IDEA. Не вим, конечно, но без IDE очень тяжело, а с плагином редактировать текст значительно приятнее, если привык к режимам.
Teivaz
Чтобы выйти из него нужно нажать эскейп, а потом :q
Fragster
А через ssh удобно…
VMichael
В статье об этом не говориться.
Автору так и нужно было писать: Через SSH лучше Vima нет. Это его киллер фича.
Но в статье речь о режимах.
Хотя быть может это связано, не знаю, Vim не пользуюсь.
poxvuibr Автор
Нет, работа через SSH киллер фичей вима не является. Многие пользуются вимом, хотя по SSH ходят дай бог раза 2 в неделю. Киллер фича вима именно режимы.
sub31
Через SSH лучше VIM только sed.
AlexWinner
ed, он даже для телетайпа годится.
sshikov
Одно совершенно не отменяет другого. Для SSH нужны другие инструменты, пользоваться IDE по медленному SSH-каналу — это обычно тоже извращение.
powerman
На самом деле — у каждого своя киллер-фича.
Я использую vim уже, наверное, лет 15, может больше. Двигать курсор через hjkl пробовал многократно — внезапно, мне это неудобно. Комбинациями вроде diw владею, но на практике тааак редко нужно делать что-то подобное, а если это нужно редко то изменить текст нужным образом не используя vim-специфичные трюки занимает ненамного больше времени, а выглядит нагляднее. Конечно, на самом деле у меня много комбинаций "в пальцах", и я просто зачастую не понимаю, что делаю какие-то vim-трюки, потому что для меня это не трюки. И только когда возникает ситуация, что я не могу внести необходимое мне изменение в текст используя обычные для других редакторов способы редактирования секунд за 10-15 — вот только тогда я останавливаюсь, нажимаю Esc, и придумываю способ сделать нужное vim-трюками.
Когда я переходил на vim киллер-фичей была подсветка синтаксиса. Не она сама, а её корректность и скорость работы. Аналогов, особенно по скорости работы, в то время не было (Emacs не пробовал, правда).
Сейчас, после многих лет работы, настройки под себя, создания нескольких плагинов для vim — для меня киллер-фичей является единообразность работы с абсолютно любыми типами файлов — не важно, это код на любом языке, или текст, или SQL, или yaml, или конфиг-файл… везде одинаково открывается контекстная помощь по F1, везде одинаково работает автодополнение, везде одинаково проверяется синтаксис при записи файла, etc… Причём работает оно примерно так же, как 15 лет назад — исключая мои собственные изменения конфига vim и установленных плагинов (а вот сколько разных IDE лично Вы сменили за 15 лет, и сколько раз приходилось привыкать к изменениям после выхода новой версии той же IDE?). И, да, как локально так и на удалённом сервере. Ну и ещё возможность допилить настройки, если что-то начинает мешаться под ногами — оно, конечно, время жрёт, но лучше такую возможность иметь и пользоваться когда на это есть время, нежели не иметь ничего кроме кучки чекбоксов в настройках IDE.
Fragster
режимы вима удобны через ссш :)
domix32
nano?
izzholtik
ssh -X 127.0.0.1 gedit=\mogaika
У вас на всех серверах иксы?
Levhav
Много какие редакторы кроме gedit умеют работать с файлом по sftp. И в таком случаи чтоб что то отредактировать на сервере через тот же gedit или gimp достаточно иметь иксы на рабочей машине а не на сервере.
Wendor
На сервере не нужны иксы чтобы запустить gedit по ssh. Иксов хватит и на клиентской машине.
Но такой путь все равно костылевостью отдает (по крайней мере для текстового редактора) :-)
linux_art
С большой вероятностью gedit просто не удастся установить на сервер без иксов :) Пакетный менеджер по зависимостям их притащит :)
netch80
Он может протащить набор клиентских библиотек, но (при нормальных зависимостях) никак не xorg-server и тому подобные собственно отображающие части.
А всякие libX11 может потянуть за собой тот же vim, если собран в «полном» варианте с графической мордой.
linux_art
Эти клиентские библиотеки составляют примерно 90% иксов :)
Fragster
на пинге хотя бы 50 мс вы должны быть очень спокойным.
izzholtik
Я очень спокойный.
алсо, не вижу ничего плохого в редактировании файлов, проброшенных через sshfs, если со связью всё плохо, а графики хочется.
BelBES
webhamster
> Через SSH лучше Vima нет. Это его киллер фича.
Теперь есть micro, по SSH он работает как в нативном терминале. И даже иксовый буфер обмена пробрасывается. Он прекрасен.
firk
Использую mcedit (редактор midnight commander), удобно как по ssh так и локально. Особых недостатков перед графическими IDE не вижу. Vi только там где нет возможности запустить вышеуказанный, либо где настолько плохой коннект что он лагает перерисовкой экрана.
tema_sun
О, я не один такой, кто mc ради mcedit ставит )
easty
Как в мседит скопировать в буфер обмена выделенный блок?
SimonXI
Как вариант: зажать Shift и выделить мышкой кусок текста в терминале.
После этого Ctrl+Insert и можете вставлять скопированные данные в другом окне/интерфейсе.
webhamster
Работа с shift для выделения текста постоянно разламывается то в самом mcedit, то в эмуляторах консолей. Смешно, когда мышкой работает, а клавишами стрелок — нет.
niya3
f3 — выделить кусок — f3 — ctrl-f — Enter — перейти в нужное место — shift-f5 — Enter
webhamster
Это не копирование в буфер обмена. Это копирование внутри редактора.
khim
Ничего не понял. Мы вроде о текстовом режиме говорим — какой-такой «буффер обмена вне редактора» вы нашли в этом режиме???
mayorovp
Так именно в этом и проблема всех без исключения редакторов текстового режима...
webhamster
> Особых недостатков перед графическими IDE не вижу
То есть, для вас нормально в одном месте для копирования текста нажимать Ctrl-C/V, а в другом месте F3/F5? И постоянно об этом помнить и следить за тем где вы выполняете шорткат?
khim
Ну люди же работаю как-то на Mac'е где нужно помнить в какой программе это Ctrl-C/V, а в какой — Command-C/V и ничего.
Наоборот, когда шорткаты отличаются настолько сильно это вызывает меньше когнитивного диссонанса, чем когда отличие минимально — но таки есть…
vintage
Что за бинарное мышление? Наличие неудобства не означает, что его невозможно терпеть. А а возможность человека привыкать к неудобствам не означает, что эти неудобства не стоит устранять.
roller
И в какой же программе на маке это Ctrl-C/V?
firk
А ещё есть третий вариант Ctrl-Ins, Shift-Ins, который причём есть в двух вариантах (кнопки одни и те же, логика работы чуть разная). Это не проблема редактора в любом случае, ну а для меня это не кажется проблемой вообще — всё на автомате.
0xd34df00d
А я поставил к виму плагины ale, neco-ghc, ghc-mod, idris-mode и еще парочку, и теперь писать на хаскеле или идрисе — одно удовольствие. Других аналогичных редакторов не получится, разве что, Atom по части идриса приближается.
На плюсах пишу в clion, впрочем.
evseev
Много лет назад я был на вашем месте. Я читал подобный бред и не мог понять кто вообще в здравом уме использует этот идиотский Vim. А потом я взял себя в руки и просто что бы не оказаться в неприятной ситуации решил пройти vimtutor. Тем более, что обещали, что это всего на 20 минут. И буквально через 20 минут я понял, что хоть это и самый идиотский редактор в мире он при этом еще и одни из самых лучших.
Но при этом нужно сделать одно отступление. Он хорош если вы действительно много работаете с различного рода текстом. Код- лишь малая часть этого. И если с кодом для большинства распространенных языков есть варианты, то со всем остальным- дело может быть совсем плохо. Моя основная работа- инженер-связист. У каждого производителя железа свои закидоны. Например для сетевых элементов Ericsson скрипты нужно писать на языке, у которого даже названия нет. Во всяком случая я его в документации не нашел. И если языка нет, то и подсветки синтаксиса не существует. Как собственно и IDE под него. Но состряпать ее для Vim- совсем не проблема. Или вам нужно на оборудовании Huawei поменять один параметр на базовой станции. Но на каждой. У системы можно получить их список, но каждую строку нужно будет вручную переколбасить. Что-то оставить, что-то переместить в другое место, что-то убрать. И самое страшное в том, что эту операцию нужно будет сделать для каждой из тысячи строк. Vim поддерживает регулярки. Не несчастные вайлдкарды, а по полной программе. Одна команда прямо в редакторе и все готово. Конечно это можно сделать при помощи того-же Python и когда парсинг очень сложный, то я так и делаю, но очень часто хватает просто Vim.
PS: Я не являюсь фанатиком Vim и с удовольствием пользуюсь IDE. Но как по мне IDE + Vim звучит куда лучше, чем IDE или Vim.
vintage
Всё, что вы описали умеет любой современный редактор. И подсветка синтаксиса за 10 минут и рефакторинг по регуляркам и прочие радости жизни.
guai
Все поддерживают регулярки :)
VMichael
Ваш случай достаточно уникален. Возможно для вас Vim прекрасный выход. Хотя регулярки не только Vim поддерживает.
А про мой случай: Я не хочу «брать себя в руки». Инструмент должен быть удобен сразу, без «взять себя в руки».
eov
Уникальность этого случая скорее всего в том, что большая часть телеком оборудования сделана на основе кастрированного Linux и ничего кроме vi на борту такой конструкции просто нет. Гонять туда-сюда конфиг, чтобы поправить один парамерт весьма непродуктивно.
sshikov
Э. Perl, например. Или даже sed. То что вы описали, вполне подоходит под описание автоматизируемой раз и навсегда задачи.