Comments 622
Не обязательно использовать сам vim. Почти в каждой популярной IDE есть vim плагин, который покрывает существенную долю функций vim. Кроме плагинов разумеется, но это скорее плюс :)
Автору так и нужно было писать: Через SSH лучше Vima нет. Это его киллер фича.
Нет, работа через SSH киллер фичей вима не является. Многие пользуются вимом, хотя по SSH ходят дай бог раза 2 в неделю. Киллер фича вима именно режимы.
Многие пользуются вимом, хотя по SSH ходят дай бог раза 2 в неделю.
Одно совершенно не отменяет другого. Для SSH нужны другие инструменты, пользоваться IDE по медленному SSH-каналу — это обычно тоже извращение.
На самом деле — у каждого своя киллер-фича.
Я использую vim уже, наверное, лет 15, может больше. Двигать курсор через hjkl пробовал многократно — внезапно, мне это неудобно. Комбинациями вроде diw владею, но на практике тааак редко нужно делать что-то подобное, а если это нужно редко то изменить текст нужным образом не используя vim-специфичные трюки занимает ненамного больше времени, а выглядит нагляднее. Конечно, на самом деле у меня много комбинаций "в пальцах", и я просто зачастую не понимаю, что делаю какие-то vim-трюки, потому что для меня это не трюки. И только когда возникает ситуация, что я не могу внести необходимое мне изменение в текст используя обычные для других редакторов способы редактирования секунд за 10-15 — вот только тогда я останавливаюсь, нажимаю Esc, и придумываю способ сделать нужное vim-трюками.
Когда я переходил на vim киллер-фичей была подсветка синтаксиса. Не она сама, а её корректность и скорость работы. Аналогов, особенно по скорости работы, в то время не было (Emacs не пробовал, правда).
Сейчас, после многих лет работы, настройки под себя, создания нескольких плагинов для vim — для меня киллер-фичей является единообразность работы с абсолютно любыми типами файлов — не важно, это код на любом языке, или текст, или SQL, или yaml, или конфиг-файл… везде одинаково открывается контекстная помощь по F1, везде одинаково работает автодополнение, везде одинаково проверяется синтаксис при записи файла, etc… Причём работает оно примерно так же, как 15 лет назад — исключая мои собственные изменения конфига vim и установленных плагинов (а вот сколько разных IDE лично Вы сменили за 15 лет, и сколько раз приходилось привыкать к изменениям после выхода новой версии той же IDE?). И, да, как локально так и на удалённом сервере. Ну и ещё возможность допилить настройки, если что-то начинает мешаться под ногами — оно, конечно, время жрёт, но лучше такую возможность иметь и пользоваться когда на это есть время, нежели не иметь ничего кроме кучки чекбоксов в настройках IDE.
а вот сколько разных IDE лично Вы сменили за 15 лет, и сколько раз приходилось привыкать к изменениям после выхода новой версии той же IDE?
В общем-то, я как выбрал для себя Netbeans лет пят назад, так на нём и продолжаю сидеть и по сей день. Даже контрибьютить в него всё хочу начать) Поэтому, всё-таки, ide — тоже вещь неплохая.
Вим почти не знаю и просто не вижу смысла изучать его в силу того, что на своём компе использую ide, а код на своих серверах правлю через Cloud9, когда возникает нужда.
На сервере не нужны иксы чтобы запустить gedit по ssh. Иксов хватит и на клиентской машине.
Но такой путь все равно костылевостью отдает (по крайней мере для текстового редактора) :-)
Автору так и нужно было писать: Через SSH лучше Vima нет.
Можно в emacs через Tramp mode подключаться к удаленному терминалу и работать через него как на локальной машине ;-)
Теперь есть micro, по SSH он работает как в нативном терминале. И даже иксовый буфер обмена пробрасывается. Он прекрасен.
Использую mcedit (редактор midnight commander), удобно как по ssh так и локально. Особых недостатков перед графическими IDE не вижу. Vi только там где нет возможности запустить вышеуказанный, либо где настолько плохой коннект что он лагает перерисовкой экрана.
Как в мседит скопировать в буфер обмена выделенный блок?
То есть, для вас нормально в одном месте для копирования текста нажимать Ctrl-C/V, а в другом месте F3/F5? И постоянно об этом помнить и следить за тем где вы выполняете шорткат?
Наоборот, когда шорткаты отличаются настолько сильно это вызывает меньше когнитивного диссонанса, чем когда отличие минимально — но таки есть…
Ну люди же работаю как-то на Mac'е где нужно помнить в какой программе это Ctrl-C/V, а в какой — Command-C/V и ничего.
Что за бинарное мышление? Наличие неудобства не означает, что его невозможно терпеть. А а возможность человека привыкать к неудобствам не означает, что эти неудобства не стоит устранять.
А ещё есть третий вариант Ctrl-Ins, Shift-Ins, который причём есть в двух вариантах (кнопки одни и те же, логика работы чуть разная). Это не проблема редактора в любом случае, ну а для меня это не кажется проблемой вообще — всё на автомате.
Но при этом нужно сделать одно отступление. Он хорош если вы действительно много работаете с различного рода текстом. Код- лишь малая часть этого. И если с кодом для большинства распространенных языков есть варианты, то со всем остальным- дело может быть совсем плохо. Моя основная работа- инженер-связист. У каждого производителя железа свои закидоны. Например для сетевых элементов Ericsson скрипты нужно писать на языке, у которого даже названия нет. Во всяком случая я его в документации не нашел. И если языка нет, то и подсветки синтаксиса не существует. Как собственно и IDE под него. Но состряпать ее для Vim- совсем не проблема. Или вам нужно на оборудовании Huawei поменять один параметр на базовой станции. Но на каждой. У системы можно получить их список, но каждую строку нужно будет вручную переколбасить. Что-то оставить, что-то переместить в другое место, что-то убрать. И самое страшное в том, что эту операцию нужно будет сделать для каждой из тысячи строк. Vim поддерживает регулярки. Не несчастные вайлдкарды, а по полной программе. Одна команда прямо в редакторе и все готово. Конечно это можно сделать при помощи того-же Python и когда парсинг очень сложный, то я так и делаю, но очень часто хватает просто Vim.
PS: Я не являюсь фанатиком Vim и с удовольствием пользуюсь IDE. Но как по мне IDE + Vim звучит куда лучше, чем IDE или Vim.
Всё, что вы описали умеет любой современный редактор. И подсветка синтаксиса за 10 минут и рефакторинг по регуляркам и прочие радости жизни.
Э. Perl, например. Или даже sed. То что вы описали, вполне подоходит под описание автоматизируемой раз и навсегда задачи.
Что мы узнали из статьи? Что клавишу E нажать быстрее, чем Ctrl+Right. Ок.
Я хотел сказать, что это может быть и не сильно быстрее, но, для многих людей, сильно удобнее.
но, для многих людей, сильно удобнееДополню фразу примером, чтобы было понятнее. Вспомните печатную машинку. Когда человек умеет быстро печатать слепым десятипальцевым методом vim для него гораздо удобнее. Все эти сочетания клавиш не просто медленнее, они мешают.
Там нет такого количества манипуляций с текстом
В Vim есть все, что связано с любыми манипуляциями с текстом. В нем уже реализован любой бред, который вам придет в голову. Даже если вы придумаете это под тяжелыми наркотиками или попросите что-то придумать больного на всю голову психа даже не сомневайтесь. Vim будет на вашей стороне.
Хочу из списка слов разделённых пробелами получить все варианты их перестановок, каждый на отдельной строке.
Хочу по нескольким введённым словам получить осмысленное предложение-палиндром, начинающееся с них.
Хочу по введённой строке текста получить список словосочетаний, которые рифмуются с окончанием строки.
Я не настолько быстро думаю, чтобы десятипальцевый метод что-то ускорил. Серьёзно. Набор текста в программировании — это вообще мизер.
Опечатки… вот где особенно помогает слепой метод печати, так как они исправляются сразу, а не в тот момент когда оторвал взгляд от клавиатуры...
Много вы знаете людей, печатающих не слепым методом, но тупящих в клавиатуру не отрываясь?
Обычно на клавиатуру смотрят пока печатают слово. А опечатки видны уже после того, как посмотришь, что напечатал.
Достаточно, что бы их останавливать когда они пытаются в другой раскладке сообщение печатать...
Меня удивляют такие люди. Почему-то у меня нет "борьбы с клавиатурой" и алгоритм пользования мышью я не обдумываю(ну, знаете, вот этот типичный пример про "снять руку с клавиатуры, найти мышь взглядом, перевести руку на мышь, найти курсор взглядом, перевести курсор, кликнуть, снять руку с мыши, положить руку на клавиатуру").
Почему режимы суть гавно плюс-минус нормально написано у Раскина в его Интерфейсе.
А киллер-фича емакса (и такая фича очень мало у кого есть, что-то подобное есть в Atom/Visual Studio Code, но у них это очень примитивно) — это elisp, то есть возможность работать с кодом не через клавиши, а через команды (как командная строка). У vim-а его язык расширения очень примитивен, поэтому такой метод работы в нём неудобен.
Вообще, я уже давно не пытаюсь никого ни в чем убеждать в подобных спорах. Начинал с K52 для RSX-11M, а сейчас давно уже нахожусь в комфортном для себя балансе между vim и ide, а эту дисуссию посматриваю скорее из ностальгии. Десятки лет проходят, а темы холиваров не меняются :)
Почему режимы суть гавно плюс-минус нормально написано у Раскина в его Интерфейсе.
У Раскина написано, что плохие режимы это такие режимы, при которых пользователь не может чётко понимать в каком режиме он находится на данный момент. К виму это не относится, там забыть в каком режиме ты сейчас находишься достаточно трудно.
Пример плохого переключения режимов — циклическое переключение языков.
Это, мягко говоря, неправда. В виме регулярно люди путаются, в каком именно режиме они находятся. Шутки про тройной долбёж по кнопке esc не на пустом месте, да и внезапно появившийся символ i в странном месте в пулл-реквесте тоже.
Это, мягко говоря, неправда. В виме регулярно люди путаются, в каком именно режиме они находятся.
Поначалу да, путаются.
Шутки про тройной долбёж по кнопке esc не на пустом месте
Во-первых, esc надо нажать не три раза, а два :). А во-вторых это нужно для того, чтобы гарантировано попасть в нормальный режим, в каком бы режиме ты не находился сейчас. Паник кнопка для новичков, которые могут не знать, в каком режиме находятся и для тех, кто отошёл от компа и не помнит что он делал.
О проблемах с символом i в пулл реквесте я не слышал.
Я например когда веду машину, постоянно забываю на какой скорости еду. Особенно путаю вторую и четвертую, ибо по положению ручки понять какая включена почти невозможно.
Так же не понимаю, как можно считать редактор с режимами удобным, если постоянно приходится помнить, в каком режиме находишься. Плюс стандартные действия с текстом во всей системе осуществляются одним образом, а в vi другим. Как это может быть удобно — непонятно.
Как это может быть удобно — непонятно.Тут вопрос не «как», а «кому». Тому, кто не путает вторую и четвёртые передачи, однако.
А профессионалов (причём не только у автогонщиков, но и у дальнобоев, коих несравнимо больше) этих передач может быть и два десятка, представляете?
Это не в упрёк вам — просто люди разные, кто-то в четырёх-пяти передачах путается, а кто-то и в 4-5 режимах VIM'а чувствует себя как «рыба в воде».
Если привыкаешь писать код двумя руками, прерываться на то, чтобы, положить руку на мышь, найти курсор, навести его куда-то, нажать комбинацию кнопок на мыши и клавиатуре, вернуть руку на клавиатуру кажется не самой лучшей тратой времени.
Кроме того, использование только клавиатуры, а особенно если не приходится использовать сочетания, дает возможность по максимуму почти интуитивно использовать бытрые последовательности команд («мышечную память»). То есть я заранее знаю, какой набор действий надо выполнить, и могу это сделать очень быстро. С мышью такое невозможно — каждое перемещение курсора требует сосредоточенности и постоянного контроля, т.к. можно промахнуться.
Условно говоря, мышь — это аналоговый интерсфейс, постоянно требующий коррекции на основе телеметрии с экрана, а клаватура — цифровой, достаточно выбрать клавишу.
Вы не поверите В СКОЛЬКИХ местах IDE глотают нажатия клавиш, если кто-то набирает быстро и не глядя на экран. В VIM вы можете быть уверены, что набрав 100 команд не глядя на экран вы увидите то, на что рассчитывали. IDE (за исключением текстовых) в одном случае из 100 будет что-то глотать. Вроде бы немного, но это значит что ваши действия нужно контролировать после каждой команды. Иначе рано или поздно вы пропустите момент, когда какое-то окно не успело открыться (или закрыться), после чего уже все последующие команды пойдут «мимо контекста».
В том-то и дело, что на самом деле режимов у IDE в 100 раз больше, чем у VIM'а (окно редактирования свойств класса — один режим, окно открытия файла — другой, окно заливки в VCS — третий и так далее… сотни их… если не тысячи...).
Так что разница принципиальна: в IDE вы работаете с компьютером в режиме диалога, в VIM это «я сказал, компьютер сделал».
Никогда об этом не задумывался в таком ключе, хотя и сталкивался не раз. Спасибо за чёткую формулировку.
То есть когда я работал в каким-нибудь седом Turbo Pascal'е, то для меня не предоставляло проблемы нажать «не глядя» что-нибудь типа "<Ctrl+F7> x <Ctrl+F7> y <Ctrl+F8> <Ctrl+F9>" — всё это «не глядя», после чего я мог повернуться и что-то написать на листочке, пока комп всё это будет проделывать (у нас жётских дисков в компьютерном классе не было, а при работе с дискетки одно окно могло окрываться секунд 5). И это не вызывало ощущения «ужасающих тормозов»: думаю-то я всё равно не так быстро, так что после того, как я подал пару десятков команд могу и подумать над чем-нибудь ещё.
А вот в Clion гораздо меньшие тормоза — раздражают ужасно. Потому что я не могу «забросить» кучку команд и глотнуть кофе. Я должен за этим монстром приcматривать… и подавать команды когда он будет готов. Возникает вопрос: кто для кого работает — я для компьютера или компьютер для меня?
На машинке за $10'000 примерно, впрочем, тормозов почти нет и можно работать почти как в Turbo Pascal'е… потому что CLion успевает отреагировать на всё между двумя нажатиями клавиш… но есть ощущение какой-то неадкватности: неужели же вся эта моща нужна только, чтобы компенсировать тот факт, что мы используем GUI?
Обидно как-то…
Нет, тут разница скорее между однопоточностью и многопоточностью. То, что в однопоточной программе получается автоматически, в многопоточной (гуй — это почти всегда несколько потоков) требует намеренной реализации.
А вот то, что это свойство в GUI реализовано намерено — тут вы правы на 100%. При работе с многими программами в этом даже есть какой-то смысл — действительно, не должна же моя среда тормозить из-за того, что в каком-то там браузере в фоне дизайнер навороты, грузящие одно из ядер на 100%, сделал… но почему эта беда должна наблюдаться в рамках одного процесса — мне решительно непонятно.
Потому что гуй к ним писали по тем же принципам что и сайты, там нет основного потока исполнения для формы (как было к примеру у delphi для для winforms) а если ещё и начинают использовать асинхронный js, то это же и выходит по сути страничка браузера. Меня это застало на vs от ms(большой не code) когда ты жмёшь быстро ctrl+f и текст, и первые буквы успевают попасть в файл с кодом т.к. окошко ещё не успело всплыть.
p.s. vim-ом не пользуясь, очень редко нужно писать быстро, и в основном это касается запросов к БД где ключевой ускоритель — подстановка названий полей.
Для администрирования, когда нужно быстро подправить какую-то опцию, учитывая возможности vi/vim в навигации по тексту, это особенно прекрасно в случае медленного коннекта. Например с мобильного телефона за пределами обитаемых мест.
Поклонники vim'а запоминили только, похоже, как выглядели IDE лет 20 назад.
Оно там тоже все есть)))
Разница между Vim и IDE…
Vim изначально рассчитан на горячие клавиши и построение команд, по этому с ходу тяжело научится этим пользоваться…
IDE позволяет постепенно уходить от мышки, меню к неудобным горячим клавишам, которые в команды не строятся.
В виме ведется работа с буферами, не важно что в них отображается, главное что они ведут себя одинаково.
В IDE каждое окно имеет свой интерфейс взаимодействия.
В виме я могу расположить информацию как угодно за счет буферов и вкладок(не только файлы) и перемещатся одними и теми же хоткеями.
В IDE я толком не могу разделить даже файлы в разном виде(горизонтально, вертикально, по 3, по 4, спрятать скрыть) конфигурации, не говоря уже о приятном интуитивном перемещении по ним.
Я не отрицаю, что в IDE можно работать без мыши. Но это не настолько удобно. И шорткаты в разных IDE разные, особенно Visual Studio от других отличается.
Не стоит тратить время. Они просто не понимают о чем Вы. Им нравится "не пробовал но осуждаю" и проходить vimtutor не будут.
Я им так скажу: "10 пальцевый слепой набор. VIM — руки всегда на месте, IDE — как минимум руки скачут к стрелочным кнопкам и/или мыше."
P.S. С условием что Esc на Caps Lock.
Ещё раз — зачем он нужен программисту, ваш десятипальцевый слепой набор? Ну добились вы 500 знаков в минуту, ок. И что? Я за это же время нажал 5 клавиш, а кода у меня получилось больше. В программировании набивка кода — это вообще не главное.
Ещё раз — зачем он нужен программисту, ваш десятипальцевый слепой набор?
Для того, чтобы не переводить глаза на клавиатуру, когда он работает с кодом и для того, чтобы спокойно переписываться с заказчиком в мессенджерах.
По-вашему, существует два вида печати — ваш метод и "уткнулся в клавиатуру, ничего не вижу, страдаю, набираю в час по чайной ложке"?
И зачем программисту вообще переписываться с заказчиком, это работа аналитика и менеджера.
По-вашему, существует два вида печати — ваш метод и "уткнулся в клавиатуру, ничего не вижу, страдаю, набираю в час по чайной ложке"?
Совершенно непонятно, откуда вы сделали такой вывод. Я был бы благодарен за цитату. Мы тут обсуждаем полезность для программиста слепого набора на клавиатуре. Слепой набор это когда программист не смотрит на клавиатуру, когда печатает. Когда программист смотрит на клавиатуру — он немножко теряет контекст. Чем меньше он отвлекается, тем проще ему работать.
И зачем программисту вообще переписываться с заказчиком, это работа аналитика и менеджера.
Значит будет переписываться с аналитиком и менеджером, суть от этого меняется не сильно.
Ну из вашего же комментария следует, что все, кто не владеет десятипальцевым слепым методом, страдают и не могут даже переписку вести нормально.
Кто вам сказал, что теряется контекст при взгляде на клавиатуру? Это ваши домыслы. Программист может смотреть вообще в сторону, не на код, а в окно и не терять контекст. Если для вас контекст — это три строчки кода, у меня плохие новости.
Ну из вашего же комментария следует, что все, кто не владеет десятипальцевым слепым методом, страдают и не могут даже переписку вести нормально.
Из моего комментария следует, что всем, кто владеет десятипальцевым слепым методом переписку вести удобнее, чем тем, кто не владеет.
Кто вам сказал, что теряется контекст при взгляде на клавиатуру? Это ваши домыслы.
Посмотрел на клавиатуру — потерял фокус на месте, где курсор. Когда возвращаешь взгляд надо искать курсор. Когда привык это практически не заметно, но на самом деле это и есть постоянное переключение контекста. Удобно, когда его не происходит.
Домыслы, субъективизм, проецирование личного опыта на других.
Всё, я в этой теме больше не отвечаю, сколько раз зарекался вступать в холивары с фаниатиками.
Домыслы, субъективизм, проецирование личного опыта на других.
Я хотел бы отметить, что это не только мои личные домыслы, а опыт большого количества людей. Кстати, вы умеете печатать вслепую? У вас есть такой опыт?
Всё, я в этой теме больше не отвечаю, сколько раз зарекался вступать в холивары с фаниатиками.
Вы приписали мне слова, которых я не говорил, а потом обозвали фанатиком. Неудивительно, что вам сложно общаться с людьми.
Из моего комментария следует, что всем, кто владеет десятипальцевым слепым методом переписку вести удобнее, чем тем, кто не владеет.
Нет, из него следует что всем, кто владеет слепым методом переписку вести удобнее, чем тем, кто не владеет.
Превосходство десятипальцевого метода над остальными вы не доказали.
Да и, честно говоря, потеря контекста тоже у вас вышла какая-то натянутая. Программист же не просто так набирает что-то, а ожидает после набора получить вполне конкретный результат. И в этот ожидаемый результат входит в том числе ожидаемое положение курсора.
Нет, из него следует что всем, кто владеет слепым методом переписку вести удобнее, чем тем, кто не владеет.
А я что написал?
Да и, честно говоря, потеря контекста тоже у вас вышла какая-то натянутая.
Вы умеете печатать не глядя на клавиатуру?
Вы умеете печатать не глядя на клавиатуру?
Я владею обоими методами слепой печати и не наблюдаю ни разницы в скорости набора, ни потерь контекста. При желании могу писать комментарии смотря в потолок, но тут уже скорость страдает.
Я владею обоими методами слепой печати и не наблюдаю ни разницы в скорости набора, ни потерь контекста.
Меня вот, пока не научился не глядя на клавиатуру печатать, перенос фокуса с экрана на клавиатуру и обратно очень раздражал. И такие ощущения у достаточно большого количества народу. Надо опрос на хабре устроить :)
Меня вот, пока не научился не глядя на клавиатуру печатать, перенос фокуса с экрана на клавиатуру и обратно очень раздражал.
Меня тоже, и именно поэтому я сначала выучился печатать не глядя на экран. Это позволило увеличить скорость печати, в результате чего руки стали постепенно "запоминать" клавиатуру. А там уже получилось перестать на нее смотреть :-)
Но одновременно с этим меня перестал раздражать перевод фокуса между экраном и клавиатурой.
Я без десятипальцевого не смотрю на клавиатуру и пишу почти без ошибок — ЧЯДНТ?
Вы всё делаете так. А с моей стороны — проблема с терминологией. Я говорил про способность печатать не глядя на клавиатуру. Каким методом — неважно. То есть, по моему мнению, владеть именно десятипальцевым методом не обязательно.
Программирование состоит из манипуляций с кодом и обдумывании.
Не набивка — а огромное число перемещений, небольших или больших правок. Но вовсе не из: думал 7 часов не прикасаясь к клавиатуре, потом за 1 час все набил
А в виме нужно просто нажать e
Объясните мне, как не_пользователю_vim, как тогда в этом случае там набирать букву «е»? Или подразумевается, что для того, чтобы переместить курсор к концу слова, надо сначала перейти из режима набора текста в какой-нибудь режим навигации, а уже потом нажать е?
Именно так: из режима «вставки» в «нормальный» режим. Хотя у меня для таких мелких передвижений в режиме набора используются сочетания вроде <C-b>/<C-f> (назад/вперёд на символ), ,b/,w (назад/вперёд на слово), ,B/,W (назад/вперёд на СЛОВО (ограниченное пробелами: первый вариант переносит на f в (foo|, второй — на ()). (Я имею ввиду, не выходя из режима вставки.)
И стрелки с <C- вроде тоже поддерживаются, но до них далеко тянуться и с высокой вероятностью в терминале что‐то из стрелок с модификаторами работать не будет.
Делать под себя набор клавиатурных макросов может быть и удобно, но лишь до тех пор, пока не окажешься на другом компьютере, где их нет.
vim это тот случай когда надо попробовать, также как надо обязательно попробовать хорошую IDE. Составить впечатление по постам в интернетах не получится.
Трагизм ситуации в том, что на первом этапе работать будет очень неудобно и всё будет делаться очень медленно. В случае с хорошей IDE, это обычно не так.
vimtutor в помощь
Ну не знаю. В IDE тоже свой ад связанный с обилием менюшек, которые по началу оказываются совсем не там где ты их ожидаешь.
Как по мне, IDE предоставляют две незаменимые фичи, отсутствие которых куда сильнее бьёт по продуктивности, чем +5% к скорости правки текста. Это навигация по коду а-ля «перейти к определению метода/класса» и рефакторинг.
«перейти к определению метода/класса»
Это есть и в vim, хотя да в IDE сделано лучше из-за того, что IDE держит в код в памяти в разных представлениях.
рефакторинг.
Ну да, тут явно лучше. Но опять таки какой смысл сравнивать ежа с ужом. vim это про редактирование кода, отсюда и популярность vim плагинов в IDE
В вим этого нет. Найти метод по названию можно, но если их десяток в разных классах? IDE анализирует код и знает, какого класса текущий объект. Для вим такого плагина не видел.
В вим этого нет. Найти метод по названию можно, но если их десяток в разных классах?
Нужен плагин для соответствующего языка. Например для Python и Go все это есть: подсказка будет учитывать экземпляром какого класса является эта переменная. По моим ощущениям качество подсказки для Python такое же как в Pycharm.
А вот автоформатирование Python, на мой взгляд в Vim слабее чем в Pycharm или Spacemacs.
А что, мелкий рефакторинг типа "переименовать метод" уже перестал быть редактированием кода?
Банальный Hello World получится написать на раз-два, а потом уже по мере необходимости вникать во все менюшки.
С vim же, насколько я понял, получается ситуация, что нужно изучить толмут по правилам работы с ним, чтобы можно было нормально работать, а потом уже человек сможет что-то сделать. Но возникает вполне закономерный вопрос, а зачем ему это, если под рукой есть текстовые редакторы и IDE с «классическим» алгоритмом печати текста.
Туториал изучается примерно за полчаса. Для начала работы надо запомнить примерно десять действий. Потом начинается процесс адаптации: желательно внимательно прислушиваться к совим дейтвиям и прикидывать а нельзя ли вот это действие, которая делаю постоянно сделать быстрее. И ответ на этот вопрос будет почти наверняка "да, в vim есть уже такая кнопка или команда".
В IDE точно так же надо привыкать к хоткеям (или настраивать их под себя). Елозить по менюшкам-тулбаром мышкой — это несерьезно, разве что поначалу для ознакомления. У меня в IDEA все тулбары отключены к чертям, все делаю хоткеями. Ну и IdeaVIM-плагин стоит, конечно :)
Пользователи вима ценят возможность проводить манипуляции с курсором и текстом без необходимости держать при этом зажатыми клавиши-модификаторы
… сочетания вроде <C-b>/<C-f> (назад/вперёд на символ), ,b/,w (назад/вперёд на слово), ,B/,W ..
Shift то все-равно придется зажимать для заглавных букв?
Shift то все-равно придется зажимать для заглавных букв?
Придётся. Модификаторы используются в виме и другими способами. Общее правило — чем короче действие, тем больше смысла использовать модификатор, а не режим.
Обычно автокомплит помогает
Да, но здесь‐то модификатор всего один! Впрочем, в терминале <ModX-ModY-x> не заработает практически никогда, поэтому если вам (хотя бы иногда) нужен именно терминал с Vim, то ничего назначать на «сложные» сочетания вы не будете, потому что не можете, а не потому что неудобно (я, к примеру, не вижу ничего сложного в <C-S-, нужно просто мизинец чуть больше (Ctrl на CapsLock) согнуть). Поэтому же в стандартных сочетаниях есть <C-буква(лат.)>, верхний регистр, все печатные ASCII символы и немного оставшихся <C-неБуква> из того, что есть в ASCII (вроде U+001D, <C-]>) и вроде даже <F1>, но больше ничего: Брам не любит добавлять возможности, завязанные на GUI, вплоть до того, что сочетание <C-S-x> внезапно означает то же самое, что и <C-x>, потому что именно так поступают все эмуляторы терминалов без настройки (а многие и настроить различать эти два случая нельзя). (В последнем предложении под x понимаются печатные символы из ASCII, <C-S-F1> в GUI нормально работает, иногда даже и в терминале.)
Кроме того автор из первой цитаты намекал на нормальный режим, а я написал, что я использую в режиме вставки. Впрочем, там тоже есть полезные сочетания с <C- и <S-, особенно с shift’ом.
Да, именно так. Кроме того, если вы переместили курсор к концу слова для того, чтобы что-то написать сразу после этого слова — нужно после клавиши e нажать клавишу a для перехода в режим введения текста.
Вопрос был — как сделать так в vim'е, а вы развели демагогию =(
Ваши ответы: «Он сам ставит закрывающую» / «зачем людям IDE?»
Как я и habrahabr.ru/post/339908/#comment_10468622 уже объяснили: «сам ставит» — вообще не выход из ситуации
- vim из коробки не ставит закрывающих скобок.
- можно повесить любое действие на любое сочетание клавиш в любом режиме. Например, эту задачу можно решить так: если в режиме ввода нажать два раза
\, то вставить пару скобок, перейти в командный режим, вместиться на символ влево, вернуться в режим ввода. Комментарий я писал дольше, чем команду.
:inoremap \\ ()^[i
Для такого иногда можно посоветовать всё же дополнение: с таким простым автозакрытием скобок возникают проблемы с undo (вставка скобок создаёт новый узел в дереве undo) и точкой. Лично мне первое не мешает, но вот второе сильно раздражает, хотя дополнение я так и не поставил: они имеют свойство ломаться с обновлениями Vim и не уверен, что сейчас вообще есть с работающей точкой (т.к. следил за vim-dev и иногда ловил сообщения «этот трюк сломался», но соответствующие ветки потом не особо читал).
Сам использую ,s (круглые скобки) / ,h ([]) / ,f ({}) / ,u (<>).
PS: Не нужно говорить про «любое сочетание клавиш» и «в любом режиме»: я знаю очень много контрпримеров, вот два самых простых: на первое достаточно просто <C-S-x>, на второе: вы знаете, что у YouCompleteMe есть «принципиально нерешаемая» проблема с неработающим <C-u>?
Для такого иногда можно посоветовать всё же дополнение
Да, дополнение лучше велосипедов. Команда только для демонстрации лёгкой расширяемости vim, это ни в коем случае не эталонное решение.
PS: Не нужно говорить
Спасибо.
Errata: "большинство сочетаний клавиш в различных режимах" =)
вы знаете, что у YouCompleteMe
Нет, из дополнений у меня только slime.
ага, в Vim также, удобно
Я могу написать Кавычку перед строкой:
string" и вторая не появится, а в остальных случаях появится. Или посередите строки я хочу сделать разрыв и вставить туда переменную, количество кавычек вставленных IDE я иногда предсказать не могу.
Поэтому мне кроме контекста надо всегда помнить, в каких случаях кавычка ставится, а в каких нет, и тратить время на борьбу с IDE. Мне лень, поэтому я отключаю эту шелуху. Скорость набора ну уж точно не падает.
Это страшно бесит, когда ты не пишешь новый код, а редактируешь существующий. Тебе надо поставить открывающую тут, а закрывающую там, а вместо этого ты занимаешься удалением невпопад добавленных закрывающих скобочек, кавычек и прочей ерунды. "Особо умные" редакторы ещё и удаляют эти символы парами, что особенно доставляет.
Нее, "особо умные" редакторы самостоятельно находят пару для скобок и кавычек и ставят их в случайном месте :-)
Неужели экономия одного нажатия рядом стоящей клавиши стоит введения ещё одного "режима"? Это совершенно не то место, где нужно оптимизировать. Вот закрывающие теги в HTML — это да, экономия. Хотя, куда лучше вообще отказ от HTML если не на уровне исходных кодов, то уж на уровне представления при редактировании — точно.
(кстати не только в виме)
Вы второй человек, кто упомянул слово 'стрелка влево', когда вся статья была о том, что стрелки моветон. Кроме того, в комментах звучала мысль, что контрол и шрифт — зло. И тут же были сочетания клавиш с заглавными буквами. Я печатаю вслепую на эргономичной клавиатуре, я понимаю, что такое до стрелок тянуться. Но вы мне весь шаблон рвете… То стрелки зло, то тут же советы со стрелками.
есть такая привычка — сначала набираем две скобки(или кавычки, или любые другие парные символы), потом нажимаем стрелку влево
Погодите, вы чем пользуетесь в 2017 году? Разве не во всех редактора кода уже давно по дефолту, что при наборе парного символа (левой скобки или апострофа) правый добавляется автоматом, а курсор остаётся между ними?
Ещё удобно настроить какое-нибудь сочетание клавиш, которое поставит точку с запятой в конце строки и забьёт Enter, после того, как ты ввёл содержимое последних скобок.
Да проблема-то не в этом. Проблема в том, что иногда нужно обернуть в кавычки или скобки уже написанный блок текста — и тут-то автоматическое закрытие показывает себя во всей "красе".
Пример — гифка в комментарии ниже.
(да, есть replace quotes, surround selection но вот самый очевидный и базовый функционал — без элементарной эвристики, не понимает когда не надо добавлять кавычку)
В Vim этой ереси по‐умолчанию, к счастью, нет. Я люблю вставку открывающей+закрывающей сразу, но у меня это на отдельных сочетаниях клавиш. Плюс дополнение surround.vim, позволяет легко запихивать различные конструкции в скобки/кавычки/… или удалять сразу два парных символа.
Если нет — 2 переключения: Esc, i
Всегда приходится неистово нажимать esc до пиканья в консоли, чтобы случайно не оказать не в том режима и не начала происходить неведомая хрень, что придется вырубать питание))))
Печально, но если задать этот вопрос среднестатистическому гуру вим-гольфа — он его просто не поймёт.
Любой, кто постоянно пользуется вимом и осилил хотя бы базовый набор функций, легко ответит вам на этот вопрос, не нужно утрировать.
Конечно ответит. Он и отвечает, но, насколько я понимаю он сразу отвечает на вопрос — как пользоваться режимами. И у того, кто спрашивал, создаётся впечатление, что режимы это такой пережиток прошлого, но ради других достоинств вима люди терпят.
Буквально в прошлой холиварной статье на хабре писали и про удобную навигацию по тексту, и про возможности кастомизации плагинами, коих сотни, и про быструю развертку своего конфига на удаленном сервере. Режимы просто дают возможности, сами по себе они сомнительные киллер-фичи.
Режимы просто дают возможности, сами по себе они сомнительные киллер-фичи.
Возможности, которые дают режимы, можно предоставить и без них. Но нередко люди хотят именно модального интерфейса.
удобную навигацию по тексту, и про возможности кастомизации плагинами, коих сотни, и про быструю развертку своего конфига на удаленном сервере
Удобство понятие относительное, меня например устраивает вариант ctrl+стрелка.
Остальные «фишки» вполне себе реализуются с использованием классического сейчас интерфейса.
Так какой же ответ, который будет знать любой, кто осилил базовый набор функций?
Перемещение по тексту — это о том, что я могу не брать в руки мышь. В любое место на экране я попадаю практически мгновенно либо через стандартные команды, либо через easymotion плагин когда нужное место где-то далеко внутри строки. Если вам нравится нажимать ctrl-стрелку, чтобы перейти строк на 20 вниз и в сторону, ради бога, только о какой оптимизации мы вообще тогда говорим?
Кастимиированная версия вима переезжает на удаленный сервер ровно за то время, которое требуется, чтобы сделать clone из моего репозитория.
Плюс интеграция с tmux.
Очень даже хорошо пишется код в Vim, уже лет 10 им пользуюсь, 6 из них пишу код.
Надо просто понимать что Vim это продвинутый редактор с удобным интерфесом за счет режимов и кучей плагинов.
Но если нужно изучить код, то конечно лучше IDE
Сначала в статье был длинный кусок на эту тему, но в конце концов я понял, что для нормального объяснения нужно 3 таких статьи с прикреплёнными видеороликами. Поэтому я оставил ооооочень маленький кусок про необходимость переключаться между режимами с помощью клавиш i и эскейп, а также про перемещение курсора без клавиш-модификаторов в режиме вставки. Придумать, как хорошо продемонстрировать, что такое режимы, не смещая при этом фокуса статьи я не смог :(
Но тогда, получается, статья лишилась смысла.
Статья писалась для того, чтобы те, кто хочет выяснить чем хорош вим — выясняли чем хороши режимы, а не пытались понять ради чего пользователи их терпят.
Я хотел, чтобы из статьи было понятно, что причина использовать вим — режимы. Я лично знаю несколько человек, которые узнали что такое режимы, знают, как ими пользоваться и при этом считают их досадным пережитком старины и продолжают попытки выяснить в чём всё-таки настоящая сила vim.
Из моей статьи нельзя понять, что такое режимы и как ими пользоваться. Но можно понять, что, если вы разобрались что такое режимы и они вам не понравились, то дальше причины, по которым люди пользуются вимом, можно не искать.
Режимы это нехорошо только тогда, когда пользователь путает, в каком режиме находится в данный момент. Например — плохо переключать язык по одному сочетанию клавишь. С модальным интерфейсом вима такой проблемы нет.
Нет с вимом таких проблем. Текущий режим считывается одним взглядом в левый нижний угол.
И про это там тоже есть. Можете поискать по "не находится в локусе внимания".
В каком режиме ты находишься как правило легко понять по форме курсора, который как раз находится в этом самом локусе. Проблем с пониманием в каком режиме сейчас находится пользователь в виме нет.
Про блокнот, видно что 3 страницы текста по ссылке вы осилить не способны, чтобы дочитать до понятия квазирежимов, например, позволяющих сохранять файлы через Ctrl+S, которое есть хоть в блокноте, хоть в саблайме, а в куче редакторов вообще автосохранение.Автосохранение с автопридумываением имена файла, я так понял? Речь идёт о том, что выполняя определённое действие вы попадает в другое окно, в котором у вас другой мир и старые команды не работают. Работает только… барабанная дробь клавиша ESC. А иногда, кстати, и она не работает.
Так чем эти режимы (коих десятки в так восхваляемом вами Sublime) лучше того, что в VIM'е? Тем что там нет отдельного режима редактирования и ввобда текста? Но есть отдельные режимы (без всяких «квази», я статью прочитал, не беспокойтесь) для ввода имени нового класса, строки для поиска и прочих интересных вещей? Чем режим поиска текста в Sublime лучше командного режима в VIM'е? Тем что Sublime вам нравится, а VIM — нет?
Причем тут режим поиска текста и окна сохранения? Это альтернативные режимы работы других редакторов что ли?Таки да. При редактировании текста я поиском очень часто пользуюсь.
И еще, может быть, где-то придумали, как в этих местах модальности избежать?Дык разумеется! Вы тут поминаете всуе Раскина, а Canon Cat когда-либо видели? Ну хоть на картинке? Вот у него как раз всё сделано «по феншую»: поиск — это не отдельный режим, а отдельный квазирежим.
Вся статья про то, что в виме два основных режима, и это типа хорошо.Это не мы говорим. Это ваш «гуру» говорит:
Иногда разработчики говорят, что режимы нужны потому, что число необходимых программных функций превышает число жестов, которые пользователь может выполнить с помощью клавиатуры и графического устройства ввода, поэтому жесты должны использоваться многократно. Однако число команд, исполняемых с помощью монитора (например, меню), и команд, вводимых с клавиатуры в командную строку и содержащих множество символов, может быть неограниченным и потому позволяет избежать упомянутой трудности.
И? Где в вашем Сублиме командная строка, позволяющая избежать перегрузки интерфейса режимами?
Вся статья про то, что в виме два основных режима, и это типа хорошо.Именно так. Имеющиеся в VIM'е три режима позволяют обойтись без десятков и сотен режимов и режимчиков, которые имеются в других редакторах — тем и хороши.
Попытки же борьбы за «интерфейс без режимов» под руководством Раскина так ни к чем популярному не привели, как вы верно заметили.
У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд. С сохранением то же самое. «Тем более» в начале я сказал, потому что именно у поиска есть несколько отличий, в т.ч. несколько дополнительных клавиатурных сочетаний, тогда как сохранение делается только командой без каких‐либо особенностей. И «команда» здесь в смысле «выражение на языке программирования, выполняемое ради побочных эффектов (т.е. без возвращаемого значения)», какое выражение прекрасно сочетается с другими командами, если нужно, а не что‐то, позволяющее только написать имя файла и больше ничего.
PS: «плагинчики для гиков» почему‐то есть в стандартной поставке: то же https://github.com/JetBrains/ideavim откуда‐то имеет бейджик «JB official» (хотя и требует отдельной установки) и упомянуто в официальной документации, а не в редакторах, но интерактивных оболочках вроде bash, zsh и fish (последнее ещё и называет себя «friendly interactive shell») аналог есть без установки каких‐либо дополнений. Зачем JetBrains внезапно официально поддерживает «плагинчик для гиков», вам не кажется это странным?
Режим ввода команд начинается в том числе с /, но вопрос не в этом: в sublime есть именно режим поиска, который не основной, и который сделан с одной узкой целью со своим узкоспециализированным элементом интерфейса. Сохранение тоже позволяет только сохранять, и тоже имеет отдельный интерфейс. В Vim есть режим для ввода команд редактору, но он не настолько узко специализирован и интерфейс для ввода поисковой строки практически не отличается от интерфейса для ввода команды сохранения. Кроме того, командный режим официально признаётся режимом, и при том одним из основных.
И ещё, нет такой вещи, как «поле ввода имени файла», оно часть команды. Внимание смещается просто в командную строку.
Где я или кто‐то ещё говорил про «одну точку входа»? Она там не одна, режим там один на много разных вещей. С необходимостью или наличием модальности я не спорил, я спорил только с определением количества режимов.
(А spotlite-like окошки — это хорошо, но это не вопрос «CLI vs GUI», на ncurses для своей программы при желании можно и такое написать, просто пока никто одновременно хочет и способен это сделать, да и приложений, где такое было бы оправданно, для терминала не слишком много. Да и не то что ncurses, специально для Vim можно подпилить какое‐нибудь дополнение вроде ctrlp.)
Наличие второго основного режима тут преподносится как невероятный подарок. А на самом деле это просто лишний режим на ровном месте, там где его могло и не быть. В нормальных редакторах его и нет, либо он опциональный(см. «плагины для гиков»).Но зато там есть куча режимов и режимчиков, которых тоже могло бы и не быть. Начиная хотя бы с того факта, что почти все редакторы, которые я видел имеют режим вставки и режим замены.
Единственное концептуальное отличие VIM'а от других редакторов является то, что режим ввода текста тут не является основным. Хорошо это или плохо — зависит от вашего стиля редактирования: если вы из тех, кто заголовок в Word'е центрует пробелами, то вам VIM точно ни к чему.
У Vim’а нет «режима поиска» и, тем более, «режима сохранения». Вместо первого вы входите в «режим ввода команд» и там пишете регулярное выражение: при этом работают все клавиатурные сочетания, определённые для режима ввода команд.
Мнэээ… но ведь результаты применения разные — после '/' будет поиск по регулярному выражению, а после ':' — выполнение команды.
Даже если редактирование одинаково, это таки вполне соответствует понятию "режим".
(И я не говорю, что это плохо.)
Кэнон Кэт я видел вживую в Музее компьютерной истории, и что? Причем тут Кэнон Кэт?Мы вроде как о поиске тут говорили? Ну так вот у него — такие большие красные клавиши есть. Их очень сложно не заметить. Именно для того, чтобы этот самый поиск без создания режимов производить.
Режима задания имени файла том тоже не было (могли бы поинтересоваться тем, как это было сделано, раз уж вы такой фанат).
Исследования Раскина и других привели к тому, что ни один современный текстовый редактор не идет по пути вима.Neovim, первая версия которого вышла в 2015 году — для вас недостаточно современен?
Или вы про то, что все современные модальные редакторы используют подход VIM'а? Ну так и с немодальными та же история — сплошной Ctrl+C/Ctrl+V, куда ни плюнь.
А вот попытки избавиться от режимов в принципе (и от режима ввода имени файла и от режима поиска подстроки и от командного режима) — не удалось настолько, что когда вам в это, я извиняюсь, тыкают носом — вы начинаете кипятится и пороть чушь:
Режим сохранения файлов требует ввода имени, если файл новый. Хоть в блокноте, хоть в виме, хоть где-то еще.Не требует, если система соответствующим образом спроектирована. Ни в Canon Cat, ни в Archy этого не требуется.
Мой «Гуру», в кавычках, подмена понятий, как мило.Где я подменил понятия? Если бы Раскин для вас был настоящим Гуру, без кавычек, то, уж наверное, если бы не пользовались средой, воплотившей его идеи (отказ от окон, команды вместо программ, ZUI и прочее), то, как минимум, знали бы о них.
А так получается что вы носитесь с его книгой, но открыть её и почитать — похоже так и не удосужились. Такой подход сектантством попахивает, уж извините.
А тот факт, что об идеях Раскина даже его самоназваный фанат не подозревает — по моему характеризует «величие» его наследия лучше, чем что-либо ещё.
Раскин в ветке появился как самый известный человек, описавший проблемы режимов
И я считаю, что для вима эти проблемы либо не свойственны, либо преимущества режимов с лихвой компенсируют их недостатки.
Поспорьте с Википедией
Хорошо, давайте поспорим с википедией :). Прежде всего в качестве самых ярких примеров проблем с режимами там приведены примеры использования клавиш CapsLock и Insert. Но эти клавиши не вредны, а просто бесполезны. Проблемы с ними возникают когда ты случайно нажал одну из этих клавиш и пытаешься понять, что произошло. Намеренно их используют очень редко. Поэтому в контексте проблемы режимов о них говорить особого смысла нет.
Кроме этого википедия упоминает проблемы с внезапно появляющимися модальными окнами и проблему отдельного режима ввода сообщений в компьютерных играх, из за которого ты можешь не успеть вовремя среагировать на хедшот. Тут тоже не поспоришь, но в виме таких проблем нет, а с тем, что режимы могут вредить я в общем согласен.
И наконец, речь заходит о vi. Википедия упоминает, что для новичка vi сложен из-за режимов. Опять же, согласен :). Для новичка привыкнуть к режимам непросто. Для того, кто привык без них уже тяжело.
Немного о влиянии работ Раскина на текстовые редакторы
И отдельно хочется обсудить последний пункт из википедии. Где-то выше по ветке вы упомянули, что таких редакторов, как вим больше не делают благодаря работам Раскина. По-моему это называется социальным доказательством.
Так вот, реальный пример повседневного использования режимов, который причиняет вред и мешает работать большому количеству людей это циклическое переключение раскладки клавиатуры. И, несмотря на наличие работ Раскина, дискуссия о переключении раскладки как правило сводится к тому, какой клавишей её лучше переключать.
Те, кто не хочет заморачиваться используют дефолтный Alt+Shift, более продвинутые меняют его на Control+Shift, постигшие дзен слепой печати возвращаются обратно к Alt+Shift, потому что это позволяет не двигать руку, а маководы сидят на Command+Space, не знаю почему.
Самые решительные и радикальные настраивают переключение раскладки на клавишу CapsLock.
А, между тем, по уму нужно от циклического переключения раскладки отказаться и забить хоткей на один язык и хоткей на другой. Однако тех, кто делает так, можно перечесть по пальцам.
Как же так вышло, что в случае с текстовыми редакторами, рекомендациям Раскина последовали, а в случае с переключением раскладки — забили на них большой болт? По моему мнению, Раскин тут вообще не при чём. Модель редактирования текста, используемая большинством текстовых редакторов исторически появилась раньше, чем модель, используемая в виме и для начинающего пользователя она гораздо проще. Поэтому она и распространена. С переключением раскладки точно так же.
Кстати, интересно, как вы переключаете раскладку?
В защиту циклического переключения раскладки. При использовании правильного метода слепой печати (который "не глядя на клавиатуру") ошибка режима заметна сразу же, и очень просто исправляется. Это не летательный аппарат который нужно сначала суметь удержать в воздухе прежде чем делать что-нибудь еще.
Я привык переключать раскладку через RAlt+Shift и не испытываю никаких проблем (кроме того что с некоторого момента винда из коробки не поддерживает этот способ, а также раздолбанного шифта — но эти недостатки сохраняются и при переключении раскладки через два разных хоткея).
В защиту циклического переключения раскладки. При использовании правильного метода слепой печати (который "не глядя на клавиатуру") ошибка режима заметна сразу же, и очень просто исправляется.
Если не печатаешь вслепую, циклическое переключение раскладки это вообще ад :). Но даже, если сразу понимаешь, что с раскладкой что-то не так, к этому моменту уже обычно напечатано две-три буквы. Их надо удалять, потом переключаться. И я часто забываю, какой язык сейчас активен, особенно, когда пишу текст в котором надо использовать англоязычные термины.
Вы зря переключение языка по разным клавишам считаете решением. Предлагаемый вами подход приводит к одному из 2 сценариев:
- Если пользователь переключает раскладку лишь когда думает, что сейчас не та, то получает одни и те же проблемы что с одной клавишей переключения, что с двумя.
- Если пользователь переключает на нужную раскладку каждый раз начиная ввод, то это очень дофига ритуализированных нажатий. Любое сколь угодно краткое вырывание из потока ввода текста и надо снова актуализировать выбранную раскладку. Кстати, идея для вима: переходить в режим ввода текста, не по нажатию на i, а по выбору конкретного языка ввода. ir и ie, например.
На мой взгляд проблему режимов языков (а от них не избавиться без педальки или второй клавы) лучше решать через превентивный фидбек. Например, цветоформой курсора и/или поля ввода (в случае однострочных полей). То есть собираясь ввести куда-то текст ты автоматически считываешь информацию о том, на каком языке будешь печатать. Плюс пунтосвичер, если вдруг всё же ошибся.
Тем не менее, я согласен, что переключение языков разными клавишами удобнее, особенно, если языков больше, чем 2. У меня под досом была такая тема, как включение русского по правому альту, а английского по левому. После этого привыкать ко всяким альт-шифт было очень тяжело.
Где-то выше по ветке вы упомянули, что таких редакторов, как вим больше не делают благодаря работам Раскина. По-моему это называется социальным доказательством.
Neovim?
Самые решительные и радикальные настраивают переключение раскладки на клавишу CapsLock.
Гм… меня когда-то просто приучили к CapsLock, и я не вижу тут ничего радикального :) Это банально удобно. В отличие от
А, между тем, по уму нужно от циклического переключения раскладки отказаться и забить хоткей на один язык и хоткей на другой. Однако тех, кто делает так, можно перечесть по пальцам.
Да, и именно потому, что
Режим клавиатуры всё равно надо помнить, хотя бы краем одной извилины. Собственно наличие одной клавиатуры (а не двух, или даже одной восьмирядной) вынуждает к этому. Набор не в том режиме приводит к неверному результату. Punto Switcher не вспоминать — это костыль, не работающий в сложных случаях (а для программиста не пригодный, считаем, во всех практически важных случаях).
- Все эти хоткеи будут значительно тяжелее набираться, чем один кивок левым мизинцем (или, для ниасиливших десятипальцевый набор, как я — левым безымянным). Ограничивающее условие: две постоянные раскладки по кругу. Если иной вариант (например, KDE позволяет строить какие-то по кругу, а какие-то вне круга, или на кругу 3 или больше) — то хоткеи таки настраиваются. Я пока что обошёлся. Но у меня есть второй уровень режимов ввода — выбор между наборами en,ru <-> en,uk <-> en,ru(ruu), переключается в среднем пару раз в день.
Собственно, это всё даёт ответ на более общий вопрос — почему от режимов не уходят совсем. Я бы ещё добавил, что это невозможно в принципе — режимы вождения самолёта, светского приёма и интима в постели различаются естественным образом и радикально. Почему вообще ставят вопрос, что не должно быть режимов, когда этого достичь невозможно?
Режим клавиатуры всё равно надо помнить, хотя бы краем одной извилины.Совершенно не нужно. Считаем, что переход в английский режим ввода в VIM — это «Caps, i», переход в русский режим ввода «Shift+Caps, i».
В других редакторах = просто «Caps» и «Shift+Caps».
Все эти хоткеи будут значительно тяжелее набираться, чем один кивок левым мизинцемНеправда. Включение английского — одно нажатие мизинцем на клавишу «Caps», включение русского — одно нажатие мизинцем на клавишу «чуть ниже Caps» (хотя если клавиатура тугая, то это может быть не так удобно).
Почему вообще ставят вопрос, что не должно быть режимов, когда этого достичь невозможно?Это вы у Раскина и его последователей спросите — он на это всю жизнь потратил.
А vim уже умеет понимать команду "Shift+Caps, ш"? :)
langmap (для восьмибитных кодировок) или map каждой клавиши отдельно для utf-8.
А нажатие Shift+Caps он поймёт?
(Скорее он и не услышит такое нажатие. У gvim было бы больше шансов — в иксы поступают все нажатия, это уже на уровне юзерской libxkb отфильтровываются непечатные. Тот, что в терминале, не получит, потому что терминал не передаст это событие через PTY discipline.)
Думаю, нет.
Вот и я думаю, что нет :(. Вы там в предыдущих комментариях подразумевали, что Shift+Caps обработакт операционная система, да?
А надо?
Надо! Это же кратно увеличивает количество возможных комбинаций клавиш!
Это ведь событие, которое не транслируется в печатаемый символ.
В консоли не будет видно, да, но может хотя бы в графической версии. Может в neovim сделают...
Вот и я думаю, что нет :(. Вы там в предыдущих комментариях подразумевали, что Shift+Caps обработакт операционная система, да?
Да. А как иначе? (на реальных системах)
Надо! Это же кратно увеличивает количество возможных комбинаций клавиш!
Мне кажется, их и так больше, чем можно запомнить за разумное время.
А что именно вы предполагаете? Чтобы он понял цепочку из переключения ввода и входа в режим вставки как нечто целое?
Раскин в ветке появился как самый известный человек, описавший проблемы режимов, даже для таких лососей, как автор поста или вы, бегающие и вещающие, какие в виме они офигенные.
Раскин — экстремист (как и Вы, судя по ad hominem лексике). Один пример Canon Cat чего стоит. Поиск документа по содержимому в одной огромной простыне — нормально работает только для ситуации "домохозяйка со списком закупок", для чего-то более сложного он уже не годится. Вот у меня версия документа 1.12, а тут прислали исправленную соседним отделом версию 1.05, надо сравнить и смержить правки — как будем отличать, где какая? А вот пришли требования к софтине, что в них, ещё не знаем, выкладываем в память… ой, и как их искать? (Видимо, потому Canon Cat и остался только в музее.)
То же самое с режимами. Факт, что человек в принципе переключается между режимами — (повторяюсь) режим ведения самолёта, светского раута и интима в постели — мягко говоря, отличаются во всём. Или к собственно компьютерной тематике — какой именно файл редактируете, пока в редакторе. Это ведь тоже режим, как ни удивительно кому-то! (И Раскин как-то об этом не упоминает. Странно, да?) Но есть и тысячи кратковременных микрорежимов — тут вы дали подкурить (сложное, между прочим, действие, роботы ещё не справляются), тут ответили диспетчеру… и существенная разница не в том, что вообще кто-то отвлёкся от основного действия, а в том, насколько это вывело его из прошлого основного режима.
с Дональдом Норманом из Nielsen Norman Group и еще с кучей ученых, изучавших эту область поплотнее
А не надо сразу спорить с ними. Надо спорить с теми, кто потом бесконтрольно, без измерений переносит эти общие результаты на конкретное применение. (А потом можно и на исходные внимательнее посмотреть...)
В случае vim, сам по себе факт режимов банален и ключевым фактором является лишь привычка к их существованию — и их учёт ровно в той же мере, как Вы не начинаете на рауте поднимать закрылки или целовать собеседника, извините за пример :) Кому непривычно — сходит с ума и орёт про режимы, кому привычно — он всего лишь держит в голове текущий режим в том механизме мозга, который для этого предназначен (не хочу вспоминать слово "локус", тем более что этих локусов всегда много и они обычно складываются в многоуровневую структуру). А если отвлёкся (сходил за кофе, etc.) — то всегда есть указание текущего режима — для vim это нижняя строка терминала.
Вот если бы Вы вспомнили классический vi, по виду которого никак нельзя было понять, мы в insert или в vi commands, и который не показывал полунабранную vi command — я бы понял жалобы. Но к vimʼу это слабо применимо, у него всё показывается как надо. Во многих IDE бо́льшая проблема увидеть факт overwrite mode — они это показывают или совсем бледным подчёркиванием чего-то далеко скраю, или вообще не показывают, и сиди гадай.
К слову, ещё про Раскина и квазирежимы. Вот та же идея "поиск работает, пока мы держим кнопку", и как она согласуется с тем, что для облегчения работы некоторых категорий вводят "залипающие" модификаторы вроде Shift? На какую из… мнэээ… disability мы сегодня работаем? ;)
Но выдавать за киллер-фичу то, чего в любом букваре для дизайнеров рекомендуется избегать — это ломать мозг неофитам. Нефиг.
Киллер фича — это такая штука, из за которой пользователи любят приложение. Которая его "продаёт". Если при этом в букваре для дизайнеров рекомендуется её избегать — она из-за этого не перестаёт быть фичей, из за которой приложение вообще нужно людям.
В вашем понимании пользователи — это только люди, преодолевшие порог вхождения, появившийся из-за этой киллер-фичи.
С чего вы это взяли? Пользователи вполне могут пользоваться приложением и его не любить. Вим вот любят за режимы. Не любят — тоже за них :). Но вообще приложение, которое ты не любишь — лучше не использовать, если есть такая возможность.
А остальные по-вашему — например те, кто честно хотел или был вынужден работать с вимом, но сдал назад из-за проблем редактора с юзабилити и умеет только поменять текст и написать :wq — это типа уже и не пользователи.
Всё зависит от того, используют они вим, или нет.
Или люди типа меня, которые таки осилили мануал(к текстовому редактору, sic), использующие вим в работе, но не считающие режимы его киллер-фичей или преимуществом, а наоборот — минусом — это по-вашему тоже не пользователи.
Мне кажется, вам имеет смысл определить почему мы пользуетесь вимом и найти редактор, в котором есть это самое "почему", но нет режимов. Это сильно облегчит жизнь.
Но все приведенные мной аргументы против неоправданного использования режимов никуда не пропадут, а в пользу них — не прибавится.
Я в этой статье не хотел рассказать почему режимы, это очень хорошо, даже что это просто хорошо не хотел сказать (хотя я, конечно, так думаю). Я хотел сказать только, что вим любят из-за режимов.
Собсно аргумент-то у вас сквозь статью и комменты ровно один — надо привыкнуть к режимам и все станет хорошо.
Нет, основная мысль статьи — "Если вам не нравятся режимы, не нужно искать, что в виме компенсирует их наличие. Ничего такого там нет. Если режимы раздражают, то лучше не пользоваться вимом — ничего не потеряете"
Тут два момента.
Во-первых, какое заявление ничем не подкреплено? Что режимы это нехорошо когда пользователь не понимает, в каком режиме находится в данный момент? Так вроде у Раскина и написано, что модальный интерфейс — зло, потому что пользователь путает режимы.
Или вы про утверждение, что с модальным интерфейсом вима эта проблема отсутствует? Оно подкреплено моим личным опытом и опытом других любителей вима.
И второй момент. Вы только что говорили о том, что сквозит через всю статью, а потом вдруг съехали в "да я про комментарий из ветки, а не про статью". А с тем, что проблема для новичков есть, я об этом тут же и писал.
То есть не подтверждено ничем, кроме ваших слов, в отличие от хотя бы статьи на википедии, что вы только что сами в очередной раз подтвердили.
Не только моих слов, а ещё слов большого количества пользователей вима.
С другой стороны, ваше мнение о том, что опытные пользователи вима путаются с режимами точно также не подтверждено ничем, кроме мнения тех, кто с вами согласен. Они, в большинстве своём, что характерно, опытными пользователями vim не являются.
Раскин, люди из википедии — они там не про вим рассуждают, они говорят — режимы — это плохо. Везде, всегда, старайтесь их избегать, когда возможно.
Почтайте Раскина, он, в отличии от вас, обосновывает свою позицию тем, что пользователи путаются в режимах. Если бы пользователи в них не путались, проблем с режимами бы не было.
Опытные пользователи вима не путаются в режимах, следовательно у них проблем с режимами нет.
Вот такой вот простой силлогизм.
Приведите ссылки не на мнения своих друзей, а на исследования, показывающие, что в виме модальность является исключительной и не попадает под рамки приведенных исследований.
Про то, почему модальность в виме не вредна с точки зрения Раскина я уже объяснил, а тут хочу сказать, что вим тут не исключителен. Раскин, например, приводит пример фонарика, который включается и выключается одной кнопкой, я добавлю сюда пример с электической дрелью. Режимы есть, они не мешают, хотя можно было бы обойтись без них. Такие дела.
А вот насчёт исследований, на которые вы ссылаетесь. Мне интересно, это были такие исследования в которых взяли 100 опытных пользователей вима и 100 опытных пользователей notepad++, попросили их сделать примерно одинаковые вещи и замеряли количество ошибок, которые пользователи вима сделали из-за того, что не понимали в каких режимах они находятся? А самим пользователям сказали, что замеряют их производительность в зависимости от марки напитка, который им выдали перед испытанием?
Ну, чтобы цель исследования не влияла на подопытных?
Ссылка на исследования юзабилити веба.
Да, теперь многое понятно. Жаль, что вы оказались не в состоянии ответить на простой вопрос про методику исследований, если бы вы прочитали книгу на которую ссылаетесь, вы вне всякого сомнения ответили бы без особых пробем.
Почитайте букварь, объяснятель.
Так и скажите, про исследования слышал где-то, как они проводились не знаю, объяснить ничего не могу, буду давать ссылки, пока вы не поймёте, что кроме них у меня ничего нет.
Нет, что вы видите себе Д'Артаньяном было понятно практически сразу, но что вы ещё не читаете, что я вам пишу, это я понял только сейчас.
Я: Вот пруф, что все путаются
Пруф, что все путаются в режимах вима? А то там у Раскина написано, что могут и не путаться.
Вы: Раскин не знает о чем пишет
Раскин пишет, что режимы плохи потому, что в них путаются. С вашей стороны неплохо бы цитату, в которой я говорю, что Раскин не знает о чём пишет.
Я: Вот еще куча пруфов
Нет, не куча пруфов, а ссылка на википедию, в которой написано, что неопытные пользователи путаются в режимах вима. С этим я, что интересно, не спорил.
Мои ссылки показывают, что все путаются
В виме? А то последняя ваша ссылка рассказывает о методиках исследования веб интерфейсов.
Асилили, асилили. Но заодно увидели насколько же у вас узок «локус». Потому что вы одно слово заметили, а соседнее — уже нет:Тем не менее, безопаснее всегда избегать применения режимов в разработке интерфейсов.Ниасилили?
Тем не менее, безопаснее всегда избегать применения режимов в разработке интерфейсов.Заметьте — не удобнее, не быстрее, а именно безопаснее.
Вся работа Раскина была нацелена на решение одной проблемы: как-бы-это-так-сделать-эту-хитромудрую-технику-доступной 40-50-60-летним дядям, которые её тупо боятся.
На за прошедшие с тех пор 30 с гаком лет ситуация изменилась: нет уже больше тех людей, которые про компьютер ничего не знают и пугаются режимов. Просто нету. И потому «безопасные» среды — никому не нужны. А нужны удобные. А удобство — в первую очередь зависит от того, какие режимы есть в вашей программе.
Кому-то подход VIM'а с «командным режимом» и режимом ввода текста нравится, кому-то — не нравится, кому-то удобнее так, кому-то — эдак. Но вот среды, которые избегают режимов в принципе — нету. Неудобны они, потому что.
За попытку доказать, что в виме уникальный случай применения режимов — в нем результаты прошлых лет не работают, невероятное открытие — за 30 лет существования методики почему-то пока никто не заплатил.И это — много о чём говорит, не так ли? Все ваши исследования — предназначены не для создания удобного интерфейса, а для созданияпродаваемого интерфейса. А это — я извиняюсь, далеко не одно и то же.
Разуйте глаза, там есть отличный пример ошибки опытного пользователя — катастрофа самолета:Отличная идея — вырезать ровно самое важное. А давайте-ка посмотрим на оригинальный репорт, а? Какие-такие там пуковки были вырезаны, а?
«According to the NTSB, one of the factors contributing to Asiana Airlines Flight 214 crash was „the complexities of the autothrottle and autopilot flight director systems … which increased the likelihood of mode error“.»
Contributing to the accident were; (1) the complexities of the autothrottle and autopilot flight director systems that were inadequately described in Boeing’s documentation and Asiana’s pilot training, which increased the likelihood of mode error
Ути-как-интересно-то, а?
Это был неопытный пилот, ага.Недостаточно тренированный, да. Во всяком случае так комиссия решила. И предписала провести тренировки и обновить документацию — а вот про отказ от разных режимов в рекомендациях нет ни звука.
Интересно, не так ли?
Раскин — экстремист
С языка сняли. По этой же ссылке Раскин выступает против возможности пользовательских настроек, якобы они могут привести к путанице и вообще, после этого система находится в состоянии, не описанном в документации.
Основная мысль этого утверждения заключается в том, что если мы являемся опытными разработчиками интерфейсов и можем в максимальной степени оптимизировать данный интерфейс, то пользовательские настройки могут только ухудшить работу этого интерфейса. Поэтому следует с осторожностью предоставлять пользователю возможности по установке личных настроек. Если пользователь может действительно улучшить работу интерфейса, внеся в него всего лишь несколько полезных изменений, – это значит, что, вероятно, мы плохо сделали свою работу.
Возможно, это правильно по отношению к кабине самолёта — нельзя давать возможности пилоту переместить тумблеры и кнопки так, как это будет ему удобно, ведь тогда в случае чего стюардесса не сможет посадить самолёт по указаниям с земли. Если говорить о софте, то такой запрет может касаться программ управления реакторами, медицинскими роботами — там, где цена ошибки велика, а ошибка необратима. Но нет смысла устанавливать диктат безопасности над удобством в 99.9% программ.
К тому же, пока что я ещё не встречал программ, который бы мне не хотелось настроить под себя. Видимо, все дизайнеры плохо сделали свою работу (конечно же, нет).
У Раскина я прочёл "режимы — плохо, квазирежимы — туда-сюда". Допустим. Предложите текстовый редактор без режимов. ЕМНИП, при жизни и участии Раскина, а так же в течении нескольких лет после его смерти, у команды программистов Raskin Center for Humane Interfaces эту задачу решить не получилось — проект заглох на стадии альфы. Получившимся недо-Emacs'ом с квазирежимами оказалось неудобно пользоваться. https://en.wikipedia.org/wiki/Archy
Есть ещё ссылки?
Я видел людей, которые делают офигенные вещи через vi/vim, через notepad++, через встроенный редактор в FAR. У каждого свои «механически задроченные комбинации», за которыми посторонний не всегда успевает уследить глазом. Но они стали такими не сразу, а после того, как человек близко познакомился с функционалом.
То есть вопрос удобства не всегда должен рассматриваться как «мгновенное улучшение».
Переходить с привычного инструмента на совершенно новый ради одной или двух-трех киллерфич — не всегда работает.
В большинстве случаев гораздо проще найти аналог такой фичи в инструментах, которые ты уже используешь — о чем и идут постоянные холиворы.
Ну вот лично мне в какой-то момент мышка стала тупо мешаться — лишний контроллер, на который иногда приходится отвлекаться… в итоге перешел на Emacs (до этого программировал в VS, Eclipse, QT Creator) и теперь бОльшую часть времени работы за компьютером я вообще не задумываюсь над тем, что и как делать — все делается при помощи хоткеев, которые пальцы сами помнят) И сейчас единственное, чего не хватает в OS для полного счастья — это интеграции своего emacs-конфига на уровне OS, чтобы всякие браузеры и мессенджеры с ними умели работать)
Попросили описать личный опыт, почему мне хотелось не пользоваться мышью(тачпадом)/стрелками, описал, получил минусы, причём даже в карму судя по всему) Причём, что характерно, никаких гневных комментариев разъясняющих в чём я не прав и где задел чьи-то чувста, просто тупо минусы.
Дело в том что объяснять это действительно тяжело. В первую очередь из-за того, что сторонние наблюдатели считают режим вставки основным, вимеры считают таковы командный режим (он не зря здесь называется нормальным).
Вот какие фокусы доступны в нормальном режиме:
dt. — удалить все до символа точки
d10j — удалить 10 строчек вниз
50a#ESC — вставить 50 симоволов #
G — перейти в конце файла
dG — удалить все до конца файла.
5J — объеденить пять строк в одну, разделив пробелом
В этих дейтвия можно лекго увидеть некую систему:
- Каждое действие можно повторить N раз: dj — удалит десять строчек вниз, d10j удалит 10 строк.
- Действие можно связать с навигацией: dk — удалит строчку вверх, dG все до конца файла.
- Действие можно произвести над выделеным блоком: выделение бывает произвольное, строчное и что особо удобно блочное
Действий довольно много:
- d — удаляет
- с — удаляет и переходит в режим вставки
- r — меняет символ без перехода в режим вставки (звучит бредом, но в некоторых случаях очень удобно)
- p — вставляет из буфера обмена
- y — копирует в буфер
- u/U — меняет регистр вниз/вверх
и ещё стопицот.
Навигации ещё больше:
- hjkl — аналог стрелочек
- t — до симовола
- g — до строчки номер N
w/e — по словам
Ситуация с плагинами довольно нелепая. На этапе создания vimscript никто не подполагал, что на нем будут пытаться выразить чего-нибудь сложнее макросов. На деле вышло как вышло. Есть прослойка фанбоев, который рассказываютс про крутость эти плагинов, но их реальная крутость в одном: нативность для vim.
Лично я не пользуюсь плагинами, которые пытаются прератить vim в IDE. Если мне нужна IDE, то я беру Интелижжж и ставлю туда vim плагин.
Большие по объёму кода дополнения часто пишут на Python, lua и ruby; в основном первое.
Ну это появилось в семерке, которой не так много лет ещё, поэтому реальных, хороших плагинов пока мало. Активно эту идею продвигает nvim: вот там больше возможностей для построения IDE на +nvim.
Vim-7.0 появился в 2004 (точнее, тогда появился первый commit в mercurial репозитории, а он содержит исходные коды начиная с 7.0, но не более ранние). Первый commit, позволяющий запуск powerline (которому нужен +python) — 7.0.112 — октябрь 2006.
А у Neovim есть API на основе msgpack для взаимодействия с внешними процессами, что позволяет писать на любом языке.
Значит для меня будет лучше посвятить время изучению Emacs
Хаха, тоже так когда-то думал. Но руки сделали свой выбор сами. Главная киллер-фича vim для меня — руки меньше болят после целого дня работы с текстом (в сравнении с "традиционными" редакторами, IDE и тем же Emacs). Это эффект именно модального режима, благодаря которому все эти Ctrl, Alt, Shift приходится жать на порядок реже. Как итог, существенно меньше напрягаются кисти.
Русский язык, к примеру.
Впрочем, бывает, что в состоянии потока код прёт как бешеный. Но это не зависит от ЯП, только от степени понимания задачи и наличия времени для спокойного погружения в кодинг.
Не исключено, что тут влияет дополнительная нагрузка на кисти. Я в те годы активно барабанами занимался. В комментах ниже гитарист тоже на Emacs жалуется.
Ну и, опять же, физиология у всех разная. Кто-то более предрасположен к RSI, кто-то меньше. Возраст тоже влияет: чем старше пациент, тем больше шансов поиметь проблем со связками.
Хаха, тоже так когда-то думал. Но руки сделали свой выбор сами.
А evil-mode не пробовали?
Знаю про него, но так руки и не дошли. Привык уже к классическому vim.
Главная киллер-фича vim для меня — руки меньше болят после целого дня работы с текстом
У меня одно время тоже начали побаливать руки, когда много на встроенной клаве ноута фигачил, держа их на весу. Подключил классическую внешнюю клаву, кинул перед ней силиконовую подушку, на которой руки лежат практически неотрывно (и ни малейших проблем ни с какими комбинациями не испытывают) и всё прошло. Но возможно мне просто повезло с длинной пальцев (я бы с удовольствием добавил между цифрами и F-клавишами ещё один программируемый ряд полноразмерных кнопок и мне было бы не менее комфортно).
Естественно, как любой нормальный емаксер, я control перемапил на caps lock, ну и клава должна быть не сильно плохая (сейчас у меня макбук, на декстопе когда сидел — была майкрософт натурал, потом майкрософт 4к).
Если есть возможность я бы сейчас смотрел на Atom/Visual Studio Code, мне кажется это очень перспективные вещи, возможно, лет через 20 даже emacs начнут догонять.
Т.е. vim притягивает тем, что можно писать мэджик команды для редактирования текста и ощущать себя грёбаным Гэндальфом?
Совсем не проблематично. Но вопрос — зачем ставить vim плагин и портить им замечательную IDE останется открытым :)
Ваш Кэп.
P.S. Все лучше чем раскладка Visual Studio без Rider.
После его установки отпадает потребность в использование оригинального Vim для разработки.
Использование режимов и возможность ввести команду не шевеля кистями распространяется не только на редактирование текста, но и на команды IDE. Есть сочетания типа Ctrl+Shift+Alt+T, после которых болят пальцы, и которые не всегда имеются на нужную команду. А в vim всё просто, одна клавиша — одна команда, другого способа её выполнить просто нет.
Более удобные — да, но столь же семантичные? Например замапил git clone на Ctrl+Y и git push на Ctrl+U (потому что Ctrl+P занят чем-то ещё). И нужен тебе внезапно git rebase(раз в году и rebase нужен). А он не замаплен. И куда его вставить чтобы вспомнить потом что он там? Или мышкой тянуться?
По философии vim нужная комбинация существует заранее, и требует не столько вспомнить, сколько логически вывести. Сильно упрощённый пример: жмёшь клавишу-лидер (функциональная клавиша для разных сочетаний, мапится куда угодно), какой-нибудь g для вызова команды плагина (git же, логично) и r (rebase).
По этой же философии разрабатываются все плагины. Перемапить тоже можно что угодно, но лучше этим не увлекаться
И, если вы хотите понять, что хорошего в виме ...
Значит у вас на самом деле нет настоящей работы которую нужно делать, и от нечего делать вы решили попробовать приобщиться к сообществую мифического вима.
А, если вы хотите обосновать кому-нибудь, что вим — полный отстой ...
Опять же от нечего делать.
Vim это ведь редактор текста, а не кода, и в своей области возможно он удобен
Как редактор текста (именно текста, художественного) он не шибко удобен, поскольку все действия заточены именно на структурированный текст
Vim это ведь редактор текста, а не кода, и в своей области возможно он удобен, но IDE это далеко не просто редактор текста, не нужно путать понятия.
Мне кажется, я писал статью как раз для того, чтобы донести свою точку зрения до вас. Да, вим это просто редактор текста, но редактировать текст в нём настолько субъективно удобно, что пользователи своими руками превращают его в IDE. Или пишут плагины для эмуляции vim к другим IDE.
Что касается отсутствия настоящей работы, то редко можно найти человека, который занят 24/7 и совсем не имеет свободного времени.
В чём проблема использовать плагин "как vim" в IDE? И вообще проводились ли какие-нибудь исследования по влиянию на продуктивность этих киллер-фич vim?
Новая научная истина торжествует не потому, что ее противники признают свою неправоту, просто ее оппоненты со временем вымирают, а подрастающее поколение знакомо с нею с самого начала.
Аргумент «в виме быстрее и удобнее печатать» — это не актуально для программистов.
"Быстрее" — не актуально. А вот "удобнее" — очень актуально.
Программисты на самом-то дела пишут мало
Зависит от проекта и вообще специфик работы.
Я как-то поймал себя на том, что пользуюсь девятью буферами одновременно — так много в коде бывает повторяющихся кусков.
Признак говнокода.
Всегда обходился одним буфером и одним монитором, даже когда выбор железа самый любой, при этом более продуктивен чем большая часть коллег.
Аргумент «в виме быстрее и удобнее печатать» — это не актуально для программистов.
Зато аргумент «в виме быстрее и удобнее выполнять команды» — это актуально.
Ну так работайте в screen-сессии, проблему-то нашли.
Имхо, тут проблема от того, что редакторами аля Vim/Emacs сложно пользоваться, если пытаешься запоминать команды/хоткеи… вот когда начинаешь с ним работу с чистого конфига и по мере необходимости добавляешь функционал, то в конечном счете получается минималистичный редактор, весь функционал которого запоминается пальцами и не приходится ничего вспомнинать.
Оооо, этот вопрос имеет множество решений.
- Замапить клавишу CapsLock на ESC
- Вместо ESC жать Control + C
- Вместо ESC жать Control + [
Лично я замапил CapsLock на Control и использую третий вариант. Руки с home row убирать не надо :)
Проблема комбинации Ctrl + Right — не в Ctrl, а в Right. Эта кнопка находится довольно далеко.
В случае с вариантом 3 клавиша [ в свете расположения (по крайней мере, в стандартной раскладке) не очень удобна для зажимания одновременно с Ctrl — или надо занимать обе руки, или удобство не лучше, а то и хуже, кмк, чем передвижение правой кисти на Ctrl + Right.
У вас какая-то уменьшенная клавиатура. Сгибая кисть без переноса я разве что до Left дотягиваюсь, а Right уже за пределами доступности.
Я не набираю код с такой скоростью, чтобы необходимость переноса кисти становилась узким местом.
Я в очередной раз хочу отметить, что речь не идёт о скорости. Речь идёт об удобстве.
Вообще, по большому счету, оба метода — отстой. Ведь программисту что нужно, если мы говорим о курсоре? Чтобы машина шарахнула курсор вооон туда, между теми двумя словами.
Было б здорово — о, идея для стартапа — чтобы были очки, которые следят за зрачком. Смотришь на позицию в тексте, жмакнул Ctrl и курсор туда прыгнул. Вот это — удобно.
А обсуждаемые методы — оба инвалидские.
Один — итеративный — мы жмем клавиши раз за разом, последовательно приближая текущую позицию курсора к желаемой; второй — делает то же, но мы мысленно загодя вычисляем разницу и компонуем команду, это так же неудобно.
А уж какой из двух неудобных инвалидских способов использовать — дело каждого.
Мой мозг отказывается понимать, в чем здесь неудобство, если откинуть фактор времени и скорости.
В том, что нужно часто двигать руку к стрелкам и всему такому. Это реально напрягает после того, как понял, что это можно не делать. Искать стрелки не глядя на клавиатуру — немного отвлекает. Искать пупырышки на home row — тоже. Немного, но это приходится делать постоянно.
А обсуждаемые методы — оба инвалидские.
Тут не поспоришь. Хотя метод с очками, предложенный вами, наверное требует нелохой концентрации. А тут есть какая-то дискретность.
А уж какой из двух неудобных инвалидских способов использовать — дело каждого.
Ну да. Но только многие думают, что способ выбранный в виме объективно хуже обычного и пытаются найти ради чего пользователи вима готовы его терпеть.
В том, что нужно часто двигать руку к стрелкам и всему такому.
Что в этом неудобного?
Это реально напрягает после того, как понял, что это можно не делать.
Теоритически, можно переопределить все ключевые слова и идентификаторы так, чтобы они укладывались в символы home row. Это будет еще удобнее — вообще пальцы отрывать не надо.
Искать стрелки не глядя на клавиатуру — немного отвлекает.
Честно — не понимаю, без всякого троллинга. У меня руки сами ложатся как на фываолдж, так и на стрелки, чистый автоматизм.
Ну да. Но только многие думают, что способ выбранный в виме объективно хуже обычного и пытаются найти ради чего пользователи вима готовы его терпеть.
Пока что вы выглядите, как человек, который пытается найти эфемерное преимущество в режимной парадигме, которая проистекает, скорее всего, из ограничений старых терминалов. Эфемерное, потому что рассказы про неудобство переноса кисти — неубедительны. Это выглядит именно как попытка найти преимущество в любимом режиме. Пользоваться можно обоими, кто к чему привык, тому то и любо.
Честно — не понимаю, без всякого троллинга. У меня руки сами ложатся как на фываолдж, так и на стрелки, чистый автоматизм.
У вас ложатся, у меня кладутся, а у кого-то так не получается. Хватит думать что вашими способностями обладает все человечество.
У вас ложатся, у меня кладутся, а у кого-то так не получается. Хватит думать что вашими способностями обладает все человечество.
Такими сверх-способностями, разумеется, обладают не все, извините, я забыл.
Ну нравится тебе есть палочками, а не вилкой, ты так привык — да бог тебе судья, на здоровье. Но не надо выдавать возможность проткнуть палочками оба глаза оппоненту за важное преимущество.
Честно — не понимаю, без всякого троллинга.
Охотно верю, что не понимаете. Просто поверьте, что возможность не убирать руки с home row меня, и многих других очень радует. Мы её ценим. И с режимами нам работать приятно. Не только по вышеизложенной причине, но и по ней тоже. Я написал статью как раз для того, чтобы сказать, что мы правда любим вим из-за режимов :)
Пока что вы выглядите, как человек, который пытается найти эфемерное преимущество в режимной парадигме, которая проистекает, скорее всего, из ограничений старых терминалов.
Что самое удивительное — нет. Она возникла не из-за этого. Она возникла из-за того, что создатель vi не хотел зажимать Control :)
рассказы про неудобство переноса кисти — неубедительны.
Тем не менее, таковы мои ощущения. Объективно — руку надо часто перемещать к стрелкам. Субъективно — мне жто неудобно.
Это выглядит именно как попытка найти преимущество в любимом режиме. Пользоваться можно обоими, кто к чему привык, тому то и любо.
Большую часть своей жизни я провёл редактируя текст обычными редакторами. Я к этому привык, а потом попробовал vim и он мне понравился больше.
10см в сторону, причем просто сгибая кисть, а не перенося — это далеко?
Очень, очень далеко. Особенно учитывая, что во время работы с кодом это приходится делать постоянно. А если не переносить руку, а сгибать кисть это чревато RSI. После этого программировать станет тяжело.
Вроде где-то читал, что некоторые извращаются с педалями под ноги.
Пользы от педалей для ног при переключении режимов в виме нет практически никакой. Педалями можно попробовать заменить шифт и контрол. Не только в виме, а везде, вот от этого польза теоретически может быть.
эти извращенцы используют emacs, не даром его называют редактором для пианистов)
Ну и от куда минусы, шутка про педали и пианистов как раз пошла от emacs в котором как раз почти огромное количество действий начинаются с ctrl + *, а многие с ctrl + ctrl + *, это просто история…
Я лично после попыток им овладеть через 4 дня почувствовал боль в кистях.
Хотя на сколько я знаю когда создавались vim и emacs ctrl находился там где сейчас находится caps lock, вроде не ошибаюсь
Хотя на сколько я знаю когда создавались vim и emacs ctrl находился там где сейчас находится caps lock, вроде не ошибаюсь
Да: www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys
А ещё можно так
" Мапим Esc в режиме ввода
set inoremap XXX ^[На месте XXX любой набор символов, который вам удобно набирать и который не встречается в набираемом вами тексте. Традиционные варианты — jj или ;;
А с IDE сравнивать vim некорректно. Это консольный текстовый редактор, ни больше, ни меньше.
Vim с нужными плагинами заменяет IDE полностью, и в ряде случаев выигрывает в скорости
А часто во время написания кода нужно раскладку переключать?
Лично я предлагаю не переключать раскладку по caps. Это порочная практика, которая больше мешает, чем помогает.
Переключение раскладки по caps нужно, чтобы раскладка переключалась быстро и просто, а переключать её быстро и просто нужно потому, что это приходится делать часто. А когда ты часто переключаешь раскладку, то достаточно быстро перестаёшь понимать, какой язык у тебя включен сейчас. И выходит так, что ты печатаешь символ, понимаешь, что он не от того языка и тогда жмёшь caps. А иногда сначала жмёшь caps и только потом понимаешь, что язык был тот, который надо.
Так вот, чтобы этого избежать лучше сделать одно клавишное сочетание переключением на один язык, а другое на другой. И тогда, когда ты точно знаешь, что сейчас надо печатать на русском — сначала нажимаешь хоткей для русского языка, а потом начинаешь печатать. Идемпотентность рулит!
Радоваться тому что им завидуют те, кто использует 3 раскладки а не 2. :)
А вообще мне статья понравилась. Я узнал что-то новое — про кнопку «e» в vim. И я улыбнулся, читая ее. Конечно, я не перестану пользоваться теперь IDE.
Хорошая киллер-фича. Использовать ее я, конечно, не буду. :)
Вооот! Ради этого я и писал статью. Если человеку мешают режимы, то вим ему не нужен .
Да уж. Всё субъективно. "Кому нравится поп, кому попадья, а кому — попова дочка".
Лично мне, если прислушаться к тому, ради чего люди ценят режимы Вима (сужу по соседним комментариям), то (субъективно) надо бежать со всех ног. Не убирать руки с home row. Почти не шевелиться. Весь день! Я бы взвыл, честно, и никакая высокая скорость для меня этого не оправдает.
У меня два метра до мусорки, четыре — до чайника. Ближе не придвину никогда, просто нужен повод встать и подвигаться.
Движение — жизнь. Руки от движения болят тогда, когда движение для них — это ненормально. Не без исключений, но всё же так.
И спроектировали достаточно удачно. Действительно, работая с vi/vim, можно не убирать руки из исходного положения, по минимуму использовать различные комбинации Ctrl/Alt, быстро перемещаться к нужному файлу/месту в файле (без всяких Home/End, скроллбаров, мыши) и т. п. Многим это всё достаточно важно.
Ну и ещё одна приятная особенность vim — он нормально относится к файлам большого размера. Для написания кода это не имеет значения, а для обработки каких-нибудь логов — очень даже. Поиск в файле в миллион строк занимает у vim на среднем компьютере не больше 1–2 секунд.
добавлю…
удобное перемещение, а так же за счет вкладок, окон для буферов + плагином для удобного сохранения сессии больше комфорта для написания/редактирования.
Именно когда пишешь код не нужны 33 лишних окна которые предоставляет IDE и всякие доп. фишки которые в них есть.
Есть и альтернативный вариант — научиться возвращать руки в исходное положение. В таком случае даже мышь перестает мешать и начинает помогать :-)
Я так и делал до Vim, а после Vim возникает вопрос "Зачем?"
Если нужно позиционироваться по «абстрактным» объектам (идентификаторам, скобкам, обозначающим начало/конец блока, именам файлов) — удобнее «горячие клавиши» или даже текстовые поля ввода с подсказками.
С некоторых пор понял для себя, что при работе в той же Windows гораздо проще вызывать программы/открывать документы не блуждая по менюшкам/иконкам, а нажать кнопку с окошками (попадаем в поле Search programs and files) и ввести несколько букв интересующей нас сущности (имени программы или документа).
Аналог в Mac — Spotlight (Ctrl+Space), аналог в vim — просто слэш.
С некоторых пор понял для себя, что при работе в той же Windows гораздо проще вызывать программы/открывать документы не блуждая по менюшкам/иконкам, а нажать кнопку с окошками (попадаем в поле Search programs and files) и ввести несколько букв интересующей нас сущности (имени программы или документа).
Я надеюсь, "кнопкой с окошками" вы обозвали клавишу с окошками? :-)
Ну и ещё одна приятная особенность vim — он нормально относится к файлам большого размера.
Зато в нём довольно неудобно работать со строками большого размера: если не-текущая строка не помещается на экран целиком, то она не показывается вовсе.
Я пользуюсь вимом с десяток лет, доволен настолько что не участвую в холиварах и никому не навязываю. Ничего лучше ДЛЯ СЕБЯ я не нашел (много пишу фронта, шарпы, иногда java и немножко haskell, периодически поигрываю с с/с++ и llvm)
Если программист плотно сидит в одном стеке то естественно что скорее всего под этот стек будет вылизанная IDE. А вот когда стеков несколько — приходится выбирать — несколько IDE или один vim. А когда стеки под разные платформы (винда/мак/никсы) — vim хорош. Только доказывать никому ничего не надо — нравится — пользуйтесь, не нравится — не пользуйтесь.
Если проект использует только java, было бы безумием не пользоваться IDEA, но у меня в проекте есть и ruby и golang и clojure и java, и я, как недовимер прыгаю между rubyMine, IDEA, sublime и vim(использую для go), а много кто сидит или в vim или в emacs и не выходят из них вообще.
Для меня режимы — это главный минус vim. Печатаю я, конечно, вслепую и давно, но иногда всё же промахиваюсь. При наборе текста это не проблема, удалил символ, написал новый. Но когда в виме я в нормальном режиме, начинается то самое «пищит и портит». Остаётся судорожно жать Esc несколько раз, чтобы точно там не набилось невидимых команд в буфер.
Для меня режимы — это главный минус vim.
И поэтому вы используете vim только тогда, когда ничего другого вообще нет, так?
Ctrl+[ в слепом варианте набирать удобнее. Левая рука жамкает на Ctrl, правая на скобку. И сдвиг кистей минимальный получается. До того привыкаешь порой, что начинаешь и в браузере эту комбинацию жать
У меня так мизинец не выгибается, чтобы до [ достать, я обычно «х» жму безымянным, смещая руку. А в описанном сценарии проблема именно с промахами, так что тут можно ещё сильнее усугубить. А Esc всегда в углу клавиатуры.
То есть тянуться до стрелочки мизинчик устаёт, а до эскейпа — нет? Зажимать контрол очень тяжело, а зажимать шифт — легко и просто? Тыкнуть курсором в нужную часть текста долго, а выплясывать на клавиатуре заклинания — быстро? Я правильно всё понял?
То есть тянуться до стрелочки мизинчик устаёт, а до эскейпа — нет?
До эскейпа тоже устаёт, поэтому либо мапим CapsLock на эскейп, либо мапим CapsLock на Control и потом жмём вместо эскейпа Control + [ .
Зажимать контрол очень тяжело, а зажимать шифт — легко и просто?
Шифт зажимать удобнее, чем контрол, потому что не надо убирать руки с home row. Но вообще рекомендую сделать так, чтобы вместо Контрола был CapsLock
Тыкнуть курсором в нужную часть текста долго, а выплясывать на клавиатуре заклинания — быстро?
Зависит от того, насоколько далеко нужная часть текста от текущей позиции курсора. Но вообще я специально сделал акцент на том, что речь идёт не о скорости, а об удобстве.
Я правильно всё понял?
Нет, не совсем. В этой статье я не пытался объяснить чем режимы хороши, хотел просто сказать, что режимы это именно то, из-за чего люди пользуются вимом. Что они плюс, а не минус.
Редактор Kakoune предлагает дальнейшее развитие идеи "составляемых команд". Вместо "команда-объект", как в vim, он использует подход "объект-команда". Это позволяет сделать работу более интерактивной (вы будете видеть выделенный текст прежде чем введёте команду на его удаление).
Также разработчики прогнозируют более пологую кривую обучения за счёт интерактивной подсказки о набираемой команде.
http://kakoune.org/why-kakoune/why-kakoune.html
Ещё интересный взгляд на тему "модальности" Vim: http://www.viemu.com/a-why-vi-vim.html
Если смотреть на 'i' не как на переключение режима, а как на обычную команду, такую же как, например, 'd', то, получается, никаких "режимов" и нет. Вы просто вводите команды:
d10j
G
iHello < Esc >
Дополнительная прелесть в том, что '.' повторяет предыдущую команду редактирования. Т.е. достаточно нажать точку и вы получите ещё одно 'Hello' в позиции курсора. А если вместо 'i' использовать 'A', то перед началом ввода курсор переместится в конец строки.
Статья выше содержит много других подобных примеров. А также разъясняет некоторые другие ошибочные представления о работе с Vim.
нравиться работа со строками, автовыравнивание, повторение операции по точке, вообщем много чего
Главная киллер-фича vi в том, что он есть почти везде.
Это киллер фича только для тех, кто использует вим исключительно для редактирования конфигов по SSH. Больше ни для кого это не важно.
И многим (я в их числе) это удобно, когда у тебя один инструмент для выполнения разного рода задач. Возможно кому-то удобно кодить в IDE, мержить код в какой нить спец. тулзе, редактировать конфиги в чём-то ещё.
VIM это мультитул, в некоторых моментах уступающий спец. приложениям, но в большинстве своём его возможностей хватает для всего, а если чего-то не хватает в базе, то скорее всего уже есть плагин.
кто вам такую фигню сказал? админы пишут в нём скрипты, редактируют конфиги, программисты код на локальной и удаленной машине, для выполнения слияний в системах контроля версий. И ещё 100500 применений.
Я не хотел сказать, что vim используется только для редактирования конфигов по ssh. Я хотел сказать, что возможность использования по ssh является киллер фичей только для тех, кто в основном пользуется вимом для работы через ssh в консоли.
В обычном редакторе для того, чтобы переместить курсор к концу слова нужно зажать Control, а потом, не отпуская его, перенести руку к стрелкам и нажать клавишу вправо. В редакторе получше, можно нажать не вправо, а какую-нибудь клавишу на буквенной часть клавиатуры, например d, но Control всё равно придётся держать зажатым. А в виме нужно просто нажать e
Это «преимущество» убивается необходимостью переключения между режимами.
Считайте знаете что, поклонники vim'а? Что зажатый Ctrl- это и есть переход в другой режим, только временный. Ну, как shift Vs Caps Lock. Чем Esc + e + i лучше, чем Ctrl+RightArrow?
Это «преимущество» убивается необходимостью переключения между режимами.
Если речь идёт об однократном действии, после которого нужно вернуться в режим вставки, то действительно переключение может быть неприятным. Но чаще всего курсор нужно передвинуть не в конец текущего слова, а достаточно далеко, суммой нажатий клавиш, а не однократным.
Считайте знаете что, поклонники vim'а? Что зажатый Ctrl- это и есть переход в другой режим, только временный.
Да, и держать нажатой клавишу для временного режима, когда ты реально проводишь в этом режиме достаточно долго, это не очень удобно.
Чем Esc + e + i лучше, чем Ctrl+RightArrow?
Тем, что не нужно убирать руку с home row для того, чтобы нажать RightArrow.
Если речь идёт об однократном действии, после которого нужно вернуться в режим вставки, то действительно переключение может быть неприятным. Но чаще всего курсор нужно передвинуть не в конец текущего слова, а достаточно далеко, суммой нажатий клавиш, а не однократным.
Ну, звиняйте, пример-то в статье именно такой.
Стандартная строка — 80-100 символов (на мой взгляд), переместиться обычными, не вимовскими способами надо максимум на пол-строки (либо идем от начала, либо через End — с конца). Я лично разницы между «зажать control и нажать три раза стрелку вправо» и «нажать ескейп, набрать команду перемещния вправо на три слова, нажать i» не вижу (такой, что давала бы преимущества вимовской парадигме).
Да, и держать нажатой клавишу для временного режима, когда ты реально проводишь в этом режиме достаточно долго, это не очень удобно.
Как-то… еще там клавиши PgUp PgDown затесались, Home, End, никаких «надолго» не встречается.
Точнее, у вас как в анекдоте: «Ох, сегодня заехал в магазин, купил сцепление, потом во второй, купил колодки, потом захеал в сервис, мне это поменяли, потом сгонял на ТО… и все в разных концах города, как бы я это успел, если бы не машина...»
Тем, что не нужно убирать руку с home row для того, чтобы нажать RightArrow.
Эмм. И? Лично я держу на фыва'е левую руку, правую — на стрелках и тех самых PgUpDownHomeEnd.
Реально, как внизу человек уже написал — ощущение, будто в общество машинисток попал.
Чем Esc + e + i лучше, чем Ctrl+RightArrow?
Например, числовыми модификаторами =)
Сможете переместиться на десять слов вправо, набрав 10Ctrl-RightArrow? (10e)
Сможете быстро удалить весь текст до вхождения следующего символа + в длинной строке? (dt+)
Сможете выделить текст до следующего вхождения слова в файле, не перематывая туда-сюда и не боясь пропустить слово\потерять исходную позицию? Например, выделить с текущей позиции курсора, до слова function, расположенного на N экранов ниже. (v/function)
Сможете повторить предыдущее действие редактирования любой сложности(удаление строки, замена содержимого кавычек) нажатием одной кнопки? (.)
<disclamer>
Vim не IDE, я знаю, но на наших linux-машинах нет ни IDE, ни X-ов, а из mcedit мало что выжмешь, в лучшем случае вызов внешних скриптов из пользовательского меню (я проходил).
</disclamer>
Сможете перейти из файла с ошибками компиляции в нужный файл в строчку, на которой произошла эта ошибка? (gF)
Сможете выполнить любую команду оболочки, не выходя из среды? (:!make)
Хотелось бы поставить +))) но не могу…
Но самое главное что я могу заметить, через какое-то время это делается на автомате и я даже не могу иногда ответить что я нажал что бы добиться нужного результат.
Чтобы переместиться на десять слов вправо, нужно сначала подсчитать число слов. А слова лично я подсчитываю при помощи Ctrl+Shift+Right :-)
Чем Esc + e + i лучше, чем Ctrl+RightArrow?
Ради единственного перемещения нет смысла выходить из режима ввода. Ctrl-o + e(или любая другая команда из нормального режима) и пишем дальше.
Справедливости ради — в режиме ввода все редакторы более-менее одинаковы — нажал на кнопку, появился символ. Прелесть vim в его нормальном режиме.
Такое ощущение, что тут общество машинисток.
Жалко, что нельзя 10 плюсов накинуть.
Просто печатать код — это самая неприятная сторона работы программиста, думать намного приятнее. Вот и оптимизируем то что нравится меньше :-)
Я, признаюсь, больше думаю, чем печатаю, когда пишу код.
Конечно удобство ввода это хорошо, но по мне, все таки не самое важное в работе программиста. IDE предоставляют достаточно возможностей.
1. Вы не просто «больше думаете, чем пишете», а постоянно то думаете, то пишите то перемещаетесь, то ищите.
Можете поставить программу специальную — и понаблюдать за своим клавиатурным поведением. И выясниться, что пишете/ищите/перемещаетесь все же вы довольно много.
2. IDE превосходят только более удобной пошаговой отладкой (брейкпойнты и пр).
Если вы отлаживаете через просмотр логов или проверку поведения программы — то между IDE и vim разницы нет.
Все прочее — подсказки, сниппеты и т.д. — функционально одинаковы.
3. Настройки ради настроек это потому что vim является изначально программируемым текстовым редактором, который можно заточить под свою задачу очень и очень индивидуально.
Пользователь vim, который не умеет программировать на VimScript это нормально.
Но пользователь vim, который хотя бы не использовал чужие готовые модуля, не писал (точнее программировал) свою индивидуальную версию конфигурационного файла vim — это нонсенс.
Моя дочь (5 лет) вот тоже ни в какую не желала учиться кататься на велосипеде, хотя мы с ней примерно год пробовали неоднократно. И падала и разбивала коленки сначала. И бросала это дело. Но потом вдруг поехала и теперь испытывает непередаваемое удовольствие от катания! И, Вы знаете, она тоже не может вменяемо объяснить, чем катание на велосипеде так круто. Но она точно знает, что теперь уже всегда обязательно будет стремиться на нём кататься! Примерно такие-же ощущения у меня от работы в Vim.
Я уж начал думать, что только я такой тормоз, а все вокруг что фигачат код 10 пальцами весь день, а то статьи про крутость в vim как грибы в последнее время. Обычно, пишешь не столь много, сколько обдумываешь, рисуешь схему себе (да, ручкой, без компьютера с клавиатурой), что-то ищешь в интернете, общаешься с заказчиком. А навигация по проекту — мне с мышкой в студии удобней, можно ещё на спинку кресла откинуться и пить кофе :-)
Работать с кодом должно быть настолько удобно, чтобы не задумываться над этим вообще и делать это спинным мозгом. Это же относится и к хоткеям IDE и всему остальному. Странно, что вообще об этом требуется говорить, это ведь очевидно.
Что касается конкретно vim-а (или vim-плагинов): насколько сложно к нему привыкнуть, я уже не помню (лет 15 прошло), но вот когда привык, без него очень дискомфортно.
Еще к плюсам можно отнести то, что если использовать плагин Vim для любых IDE и программ (Браузер %-), notepad++ ), то получается везде одинаковые сочетания клавиш и единый интерфейс работы с приложением через клавиатуру. И получается надо выучить один раз vim и не надо учить различные шорткаты для разных IDE/программ. А при использовании разных клавиатур Win/MacOS это уже весомый профит.
Для баша использую гедит с плагинами а для питона пайчарм.
Киллерфича — средняя кнопка мыши)
Статьям про vim не хватает опросника с вариантами типа
- Я прошёл vimtutor.
- Я пробовал, но не прошёл vimtutor.
- Что такое vimtutor?
А смысл такого опроса и вообще о чём он? Вот я пользуюсь Vim, печатая вслепую, но vimtutor не прошёл, и даже печатать вслепую учился без курсов вроде «соло на клавиатуре» (кстати, как раз пробовал, но не прошёл): просто перешёл на другую раскладку (программистский Дворак), подвесил оную под монитором и начал так печатать (заодно узнал, что в linux’овой консоли (той, что по <C-A-Fn>) оказывается есть таймаут на набор пароля). Но при этом «что такое vimtutor» я примерно знаю. Мне что отвечать?
Второй пункт означает, что остальные редакторы, что вы нашли, ещё хуже Vim: вообще‐то Vim сразу грузит весь файл в память, даже не используя mmap(). Другое дело, что он на C и там простейшие C’шные строки, собранные в структуры; overhead по памяти есть, но не очень большой и тем менее заметен, чем длиннее строка. «Большие датасеты» такой вариант проглатывает, только если есть достаточно памяти, но если память есть, то скорость работы самого Vim не упадёт (другое дело дополнения, особенно если им зачем‐то нужно проходиться по всему буферу, иногда синтаксические файлы требую странного вроде syn sync fromstart).
вим работает на больших файлах так как применяет фичи на небольшие куски, но все плохо складывается с плагинами, так как они работают не асинхронно, но сейчас пилят neovim, там вроде исправляют много legacy кода… опять же это вроде как доказывает что оно кому-то нужно.
Neovim пилят не столько из‐за legacy, сколько из‐за Брама и модели разработки вообще: хотя Neovim и нарушает обратную совместимость в некоторых местах, многие его преимущества такого нарушения в принципе не требуют, но через Брама никогда бы не прошли. Теперь ситуация несколько изменилась: Neovim наступает на пятки, поэтому Брам посылает лесом свой же :h design-not, испытывает прилив энтузиазма и создаёт несовместимые альтернативы. Но модель разработки так и не поменял, поэтому всегда можно обнаружить в master сначала изменение «добавлено X» потом «после добавления X нифига не компилируется» (хотя обычно всё же «не компилируется с определённым набором возможностей»), но нельзя обнаружить метку «это стабильный релиз». И никто не делает review (не публично, во всяком случае), не ждёт результата CI перед тем как засунуть что‐то в master и не всегда понятно, что нужно сделать, чтобы ваш вклад оказался в master (и, кстати, автором всех изменений в основном репозитории с т.з. git[hub] всегда выступает Брам, оригинальный автор указывается в комментарии).
Возможность сделать что‐то асинхронно — это пример возможности, изначально появившейся в Neovim, а потом переписанной Брамом для Vim, с несовместимым API, конечно.
Впрочем, это не значит, что legacy код у нас не исправляется. К слову, я один из основных авторов Neovim, хотя и не первый по числу кода. И я как раз сейчас очень медленно переписываю большой кусок legacy под названием «VimL»: в идеале в итоге должны быть полностью изменён «парсер/исполнитель» на реальный парсер и виртуальную машину: сейчас код выполняется по мере разбора, таких вещей как «синтаксическое дерево» и «байт‐код» нет.
и открытый код (независимость от корпораций и цели которые они преследуют это же не ваши цели правда?)
Вот к чему приводят современные IDE
вы считаете что об оптимальности думать не надо если ресурсы позволяют?
Вы правда считаете, что 40мб для консольной утилиты — это мало?
это размер 40Mb (откуда скорость)
Это каким образом размер пакета с программой коррелирует со скоростью ее работы?
вы считаете что об оптимальности думать не надо если ресурсы позволяют?
Я считаю что оптимальный размер программы это далеко не всегда приоритет. По ссылке выше речь идет о мобильных апликухак, например для десктопа как правило размер пакета с программой не так критичен.
очень много качественного софта написано именно на C (и их вариаций), потому как очень близок к ASM, а на нём долго, но зато качественно, это просто другой уровень многим не надо… а консольные приложения достаточно аскетичны вот за это в том числе их и уважают, есть вообще виртуозы терминалов и командной строки… работает всегда везде и быстро. так что пусть будет многообразие и Мир и дружба и жУвачка
Автор статьи скорее просто объяснил одну из причин удобства vim, и указал что это не исторический факт.
Я могу сравнить работу в vim и без него с десятипальцевым методом набора текста.
В свое время я печатал достаточно быстро обходясь только 4 пальцами, делал много попыток научится слепому набору текста и первое время приходил к выводу что оно и не особо нужно. Конечно со временем научился, скорость набора не особо возросла, но удобство переоценить не возможно.
Так же и с вимом, пытался научится раза 4…
Но вот так вим это не про скорость набора текста, это про удобство. Десятипальцевый метод не только набора текста, а редактирование, изучение… Многих файлов.
Единый интерфейс работы с файлами, с гитом и т.д. так как буферы ведут себя одинаково.
Без разницы на какой ЯП надо переключится.
Руки всегда в одном удобном положении, по факту вы вообще забываете о руках так как со временем все переходит в моторную память.
Единственный минус это порог вхождения, не каждому оно нужно, не у каждого на это есть время.
Но есть один факт, не знаю еще не одного кто пользовался вимом и окончательно перешел на IDE.
активно агитирующих вимеров нет по одной причине…
Так как мы понимаем что переход на вим это долгий и в какой-то мере тяжелый труд))
Я лично многим даже советую не пытаться на него переходить, так как знаю настанет момент когда от вима отказаться будет тяжело, но окромя него надо будет знать много дополнительного софта, а в IDE это уже есть да еще и в едином интерфейсе(хотя после вима понятие единого интерфейса очень сильно меняется)
Куча лишних низкоуровневых действий, которые отвлекают мозг от решаемой задачи
Это вы сами придумали. И это ложь.
В виме вы сидите и вспоминаете и составляете цепочки клавиш, которые нужно нажать, чтобы добиться результата. Плюс этого только в одном — это можно делать не смотря в монитор.
А я просто использую глаза, смотрю в монитор, жму стрелку с контролом, пока курсор не доедет до кавычки и удаляю что выделил. То есть я просто слежу за курсором, ничего не вспоминаю и не генерирую эти 3f" ci". Ну не люблю я думать, мне проще на экран посмотреть и подвигать мышкой.
В виме вы сидите и вспоминаете и составляете цепочки клавиш, которые нужно нажать, чтобы добиться результата.
Это только вначале трудно, как и с любым изучением чего-то нового. Потом мозг привыкает и радуется, что можно виму передавать высокоуровневые команды напрямую (вроде, увеличь ближайшее число на единицу), а не разбивать их на «тыки сюда» и «тыкни туда».
В vim'е я лично не вспоминаю команды и не пытаюсь делать цепочки, через какое то время это происходит автоматически, я не отрываю взгляда от монитора, не ломаю себе мизинец, не отдергиваю руку к стрелкам или мыши. И вообще счастлив только от того что мой мозг занят только задачей, и не ломаю глаза следя за курсором… и т.д и т.п.
убейте меня, но не заставите еще выучить тучу комбинаций Vim
Та никто и не пытается, хз чего у людей так печет, когда они узнают, что кто-то пользуется vim.
у людей печет так как у них не получилось, теперь оправдываются как они commit делают мышкой)))
Шутка, это всего лишь шутка...
я не заметил таких комментариев, скорее заметил что многим удобно работать по другому, хотя автор просто написал что режимы это одна из фичь, а не пережиток старого…
ну и многие начали мерятся хоткеями)))
Хотя бывает многих бомбит, так как те кто используют IDE пытаются сравнить ее с редактором, показывая окна с функциями далеко которыми редактор не должен обладать, что как-то странно.
Я то сам использую IDE в классическом понимании этого слова, хотя для меня IDE это рабочий пк.
Если Вы оскорбляетесь на такие заявления, то это зря. Какое Вам дело, простите за мой нефранцузский, до того, что не нужно МНЕ? Вот если Вам скажут, что ВАМ он не нужен, тогда и будете рефлексировать с полным на это правом.
А мне таки Вим не нужен — ну не полюбил я его, и не хочу. Мне этого достаточно.
Тем не менее, при этом я категорически отвергаю всяческую сегрегацию по признаку отношения к Виму. Хорошо, когда мы разные. Не скучно.
Не знаю, может кто-то и считает, все люди разные…
Мне удобнее в виме, без стрелок и не смотря на клаву и мыши. Если удобнее по другому, значит выработался другой подход, походки у всех тоже разные))
Вас не заставляет кто-то учить…
Но такая заметка, в виме комбинации не заучиваются, а строятся.
По этому в нем и легко работать, но переучить свой мозг с вижу и нажимаю, на думаю и строю не дается за 1 день, привычку со стандартной работой в духе блокнота сломать сложно(так как это привито с самого начала работы с текстом за ПК) и с наскока не получается.
Так что работайте как Вам удобнее, тем более если уже сложились определенные паттерны работы с кодом.
Часто публикуют «парочка удобных способов сделать что-то в vi/vim», и просто набор букв. Если их запомнить, не понимаю простые команды из которых строится комбинация — это не самый лучший способо освоить vim.
Лучше все-таки разобраться как эти команды работают, и как только это понимаешь — на ходу можешь составлять конструкции, которые будут выполнены совершенно четко, без необходимости ждать отклика от vim.
Возможно это чаще востребовано при администрировании. ВСЕГДА есть парочка серверов, которые находятся непонятно где, либо на которых крутится что-то тяжелое, что тормозит даже консоль. И вот тут vi на высоте.
Спасибо, за, очень, интересную, статью. Хоть, и, пользуюсь, вим-ом, почти, каждый, день, а, все равно, нашел, что-то, новое!
Я пользуюсь имаксом, а некоторые коллеги вимом, по одной причине — нам нужен мощный и удобный текстовый редактор, а не набор плюшек в виде IDE. Это особенно актуально для динамических языков и простого набора текста
Как-то услышал, как какой-то парень сказал: "RubyMine (Idea) — в большей степени хороший текстовый редактор и все его любят в основном за это.". В этот момент еле сдержался, чтобы не засмеяться во весь голос.
IDE хороши. Реально хороши. Но признайте, что работа с текстом намного круче в виме и имаксе. Имакс — это вообще по сути интерпретатор лиспа с интегрированным текстовым редактором.
emacs это OC спрятанная под редактор текста))
Это забавная шутка, но вот многие пользователи имакса считают, что имакс слишком мало походит на ОС и это плохо.
Я бы вот хотел открывать веб-страницы в имаксе и удобно ими пользоваться, но это не очень реально, хотя в имакс уже внедрили поддержку движков браузерных.
Или в телеграме сидеть из имакса. Или проигрывать фильм/музыку в одном из окон (часть экрана) имакса.
Предвидя комментарии вида "да это уже есть", отвечаю: есть, но корявое и неудобное.
Кстати, стоит упомянуть, что владение имаксом очень помогает при работе в других программах, т.к. основные сочетания клавиш зачастую используют имаксовские.
Примеры:
- bash
- tmux
- Google Chrome
P.S. по-моему, я ошибся постом
а тут без шуток, после вима от этих горячих клавишь болят руки… действительно тяжко зажимать постоянно ctrl, против emacs не чего не имею, но для моих рук это боль в прямом смысле, хотя играю на гитаре, хотя, на гитаре всегда тоже есть стремление к минимум движению руки и пальцев
Ну это уже вопрос личных предпочтений. Мне больше нравится зажимать мизинцем капс (на котором ctrl забинден) нежели переключаться между режимами. Для меня это стало естественным процессом работы с текстом еще до имакса: либо пишу, либо зажимаю особенную кнопку, чтобы выполнять особенные действия.
Вот кстати. Если бы Вы занимались обычным набором текста (книгу писали, например), то стали бы использовать залипание шифта? Это ведь тоже нечто близкое к режимам.
либо пишу, либо зажимаю особенную кнопку, чтобы выполнять особенные действия.Я так понимаю, что позиция сторонников VIM'а заключается в том, что «особенные действия» — это как раз «тупой» ввод текста! То есть большую часть времени вы делаете что-то другое: вставляете управляющие конструкции, двигаете что-то куда-то и так далее. И вот только тогда, когда всей мощи редактора не хватает — вы опускаетесь «на уровень машинных кодов»… и просто «вбиваете» текст!
.
Пересаживаясь на Spacemacs с Vim мне в первую очередь нравится ощущение целостности: все детали ребуса довольно хорошо работают друг с другом. Заставить также слаженно работать разношерстные плагины Vim довольно тяжко. В принципе такое же ощущение от Idea.
Но какая это боль, когда я временами не попадаю в парадигмы Emacs, которых у него довольно много. Например я ненавижу функцию автоматической смены директории при открытии файла. С Java кодом это очень неудобно, а нормального решения по отключению этой фичи нет, есть только обходные костыли, которые как и положенно костылям работают не всегда предсказуемо и удобно.
Основными инструментами в работе являются pandas и beautifulsoup. Для автокомплита использовал ctag. С пандами еще как-то можно было жить — правда необходимо ждать по полминуте, пока автокомплит очухается, а вот с супом… намертво вешает эмулятор.
Предпочитаю vim. Считаю, что режимы в описанном виде — не единственный и не обязательный вариант.
Вообще, по местной традиции такую статью следовало бы сопроводить голосованием — считаете ли режимы важнее возможностей, или наоборот.
Для меня у vim есть ещё как минимум одна киллер фича:
с ним можно работать по ssh(не в смысле редактировать удалённые файлы, а в смысле с самим редактором). Учитывая что конфиг мой для bash, vim, tmux и прочего деплоиться примермно так:
git clone vimrc && ./vimrc/deploy.sh
Это дюже удобно, особенно если иметь с десяток другой окружений, меняющихся время от времени.
Код однако, я пишу в IDE (плюсовый), питонячий таки в виме.
Шутки ради…
Надо не про e писать, а про x вместо backspace.
А также про f{sumbol}vU
ma, 'a
qa (.*)
xp
такие элементарные действия, которые работают на автомате, не знаю как это сделать в IDE)))
кстати из того что замечал, так сказать разницу между разработчиками…
не подумайте что это я кого то хочу обидеть, такое обычно встречается у начинающих, а начинающие как правило работают в IDE, так как там более комфортно, так сказать во все оружии…
Вимеры обычно открывают IDE, документацию, накидывают что то в виме, на листочке еще каким то образом…
Те кто используют IDE, обычно пытаются с ходу писать код, полагаясь на подсказки в разных окошках и т.д.
Через какое то время вимер начинает сумашедше стучать по клаве...
Нюанс какой, как правило у вимеров в крови это разделять операции, изучить, подготовить материал, поработать с бд, потестить сервис, переработать схему накиданую ранее,… а потом беспощадно стучать по клавиатуре, от сюда и желание к удобству написания и редактирования текста.
Разработчки в IDE обычно делают все тоже самое за одно и тоже время, но как то строят систему ее наращивая, в чем собственно IDE и помогает.
Повторюсь что обидеть не кого не хочу, просто замечал такое, статистики нет, графиков нет… так что субъективное.
Очень, очень субъективное…
Опять же субъективно..., так как Vim не позволяет сделать многое через плагины(полноценной работы с гит, работы с БД, построение дерева зависимостей наследования, и многих подсказок...) пользователи вим используют как правило специализированный софт что бы получить полную картину, и куда то в виме ее черкают, в виде набросков, комментов, где то UML, кто как умеет....
в IDE обычно сразу набрасывают код вполне рабочий, но сам процесс совершенно другой, менее дескретный.
это субъективно...
полностью согласен, субъективно… повторюсь(есть любители насрать в карму))) ), дискретность, декомпозиция, разделение на атомарные операции должны быть конечно у каждого программера в голове, просто я часто замечал что у вимеров это как то уже в подкорке мозга, субъективно
с IDE, обычно пишут также разделяя, но обычно не настолько сильно разделяют иммено действия, обычно пишут в потоке, тоесть пользуясь IDE
Тут даже хочется сделать эксперимент, взять и отобрать IDE и VIM…
скорее всего результат напрашивается…
Vim заставляет думать в духе unix way… одно но хорошо работающее…
СУБЪЕКТИВНО
прямо с вики…
Другие положительные стороны слепого набора текста:
Физическое здоровье — осанка, зрение (избавляет от сутулости, позволяет разместить клавиатуру и монитор в удобные для такой работы места, в частности поместить монитор на оптимальное для глаз расстояние).
Психическая утомляемость (меньше умственных усилий на набор текста и выполнение необходимой работы, меньше ошибок и связанного с ними раздражения)
Гораздо более высокая производительность. Высвобождение возможностей для более эффективного выполнения большего количества и объёма задач.
И как писали, меньше отвлечения, чем меньше движений и координаций надо делать нашему мозгу, тем проще и меньше усталость… как игра на гитаре, чем правильнее постановка рук тем лучше, как в единоборствах чем короче движение тем оно более быстрее и эффективно...
как правило это все физиология, не каждому дано работать в emacs, но в виме можно даже ребенку работать...
Но учится этому долго, как игре на гитаре, как единоборствам… не всем оно нужно.
а ну и забыл…
Давай минус ананимус)))
На самом деле не это киллер-фича vim'а. У него она другая. Заключается она в том, что если тебе часто приходится править код прямо на сервере, тебе не надо «переключать мозг» в режим другого редактора. Например:
- Не надо вспоминать, как работает консольный дебаггер.
- Не надо вспоминать другой комплект комбинации клавиш.
- ...
Но все это уходит в ноль для тех, кто пишет код только на своем десктопе. Неактуально и все равно забудется через неделю.
Никогда не понимал тех мазохистов, что правят код прямо на сервере.
У вас упало приложение на одной из нод на проде. По логам непонятно, что произошло — дебаг логи отключены в проде. Как воспроизвести в лабораторных условиях, вы тоже не знаете (может оно без нагрузки и не воспроизведется).
Каковы ваши действия по поиску дефекта?
Конечно же я попрусь править код на сервере, чтобы уронить вообще всё к чертям.
Нет, я не спорю, без best practices, особенно в плане безопасности, жить порой значительно проще: залез на Prod, вдоволь прямо там поотлаживал, может быть, на самом деле, быстро нашёл ошибку. А, может быть, повредил Prod базу, привёл к потере/повреждению/раскрытию данных клиентов, удлинил простой, привнёс новую уязвимость.
Откатить на предыдущую версию. Завести, наконец, Staging. Убрать с Prod (=DMZ, по определению) исходники. Не давать программистам права на запись на Prod.
Вы не поняли проблему. Проблема не в том, что на проде баг и надо срочно суетиться и что-то решать. Нет, все спокойно. Проблема в том, что его надо найти так или иначе. Хоть на проде, хоть на стейдже, хоть за диваном.
1. Откатить на предыдущую версию не получится — вы же не откатите миграции СУБД. Да и баг это вам найти не поможет. Вы от него избавитесь до следующего апгрейда.
2. Стейджинг вам не поможет. Допустим это нашли в стейджинге, а не на проде. Но в стейджинге тоже нет IDE.
3. Убрать исходники — вообще тут причем? Тогда у вас не останется вообще ни одного места, где можно найти этот баг.
4. Не давать программистам права на запись на Prod — и как это дает возможность найти баг?
Прочитал и второй ваш абзац. Решение проблемы так и не увидел. Подчеркиваю: не проблемы безопасности прода, а проблемы поиска бага, который воспроизводится только в боевых условиях и то случайно.
2. На Staging мы можем безболезненно выкатывать любые отладочные версии, которые уже дадут нам ответ, где именно и что ломается. В идеале, и в Prod у нас должно быть достаточно обработчиков исключений, assert-ов и т.д., чтобы программа упала с хоть каким-нибудь stack trace. Что же до IDE, то он есть у программистов на их рабочих станциях, с которых они на Staging и деплоят стандартными средствами.
3. Сервер в DMZ по-умолчанию считается потенциально скомпрометированным. Выкладывать на него исходные коды можно только если вашей компании их совсем не жалко. Мне не совсем понятно, как вообще лежащие рядом со скомпилированным байт-кодом исходники могут помочь в поиске ошибки.
4. Следование best practices, как я уже написал выше, не облегчает, а, скорее, усложняет поиск ошибки, это верно. Почему им, всё же, лучше следовать, я тоже уже написал.
Прочитал и второй ваш абзац. Решение проблемы так и не увидел. Подчеркиваю: не проблемы безопасности прода, а проблемы поиска бага, который воспроизводится только в боевых условиях и то случайно.
В случае, если все звёзды на небе сошлись не в нашу пользу, несмотря на все обработчики исключений и assert-ы мы всё же получаем «молчаливое» падение, никак не можем воспроизвести его на Staging и дополнительный code review последних изменений никаких идей не дал, можно в спокойной обстановке принять решение об изменении конфигурации Prod сервера(ов), например, о включении отладочных логов, выкатить на Prod утыканную assert-ами верисию, или даже версию с сохранением отладочного trace. В любом из этих случаев ничего править на ходу прямо на сервере не надо.
Но в реальном же мире ассертами все не обложишь. Изменение конфигурации прода в реальном мире в спокойной обстановке не сделаешь.
На правильное построение цепочки деплоймента и конфигурации ресурсов, будь то деньги или время, не выпросишь.
Но если каким-то чудом это все будет сделано, то следующим же днем это будет испорчено 20-ю новыми людьми, вносящими энтропию в систему быстрее, чем вы от нее избавитесь. И всю дорогу вас будет сопровождать давление бизнес-составляющей. Потому что правильные вещи с технической точки зрения не являются рациональными с точки зрения бизнеса.
И я не вижу, чем моё описание базовых best practices вас так напугало. В век автоматизации деплоймента и виртуализации создать Staging — дело минут, ну максимум пары часов. Ресурсов на минимальный Staging в условиях горизонтально масштабируемых систем нужно минимум. И без assert-ов stack trace должен сохраниться, пусть и на более позднем этапе. А молчаливое падение, скорее всего, результат кода типа
catch (Exception e) {//TODO}Это уже не «энтропия», это — вредительство.
Изменение конфигурации прода в реальном мире в спокойной обстановке не сделаешь.
Если самому себя загнать в ситуацию, когда всё упало, а Backout plan отсутствует, то да — нервы, и героическое превозмогание препятствий. По моему опыту, вменяемый бизнес не впечатляется романтикой a-la «я всю ночь упавший сервер поднимал сидя по SSH из леса по GPRS».
В век автоматизации деплоймента и виртуализации создать Staging — дело минут, ну максимум пары часов.
Ну-ну, попробуйте поставить Sharepoint на сервер за пару часов.
Чтобы клонировать виртуалку надо сначала поднять виртуалку. Если же вы предлагаете клонировать прод — это ни разу не вариант, потому что
- ПО на проде лицензировано для использования Заказчиком а не нами;
- мы не знаем пароля доменного администратора на проде — а значит, и клоном управлять не сможем;
- не так-то просто объяснить шарику что у него теперь другое доменное имя.
1. ПО на проде лицензировано для использования Заказчиком а не нами;
Какое ПО? Sharepoint и SQL? А у вас лицензий нет? Ну тогда правьте прямо в Prod, раз вы/ваш заказчик можете себе это позволить… (см. выше о стоимости простоя) Чем вам vim поможет, правда, не очень понятно.
SQL, кстати, лёгким непринуждённым движением руки превращается в Developer Edition.
2. мы не знаем пароля доменного администратора на проде — а значит, и клоном управлять не сможем;
Вы без спроса, что ли, чужую машину клонируете? Попросите заказчика создать вам локального админа с известным вам паролем, потом клонируйте и выводите/вводите в домен (можно с тем же именем домена).
3. не так-то просто объяснить шарику что у него теперь другое доменное имя.
Не надо другое, Staging от Prod должен быть начисто изолирован, а чем меньше отличий, тем лучше. Но, в принципе, и переименовать не так уж и сложно.
Там доменная авторизация на шарике. И еще куча завязок на домен, которые после клонирования надо перенастроить, и это далеко не пара минут.
В общем, полтора года мы мучались на вот так склонированной машине, которая все больше расходилась с продом — а потом подняли нормальный Staging другим методом.
Что касается доменной авторизации — в нормальном Staging, естественно, должен быть доступ к аналогичному домену. Это может быть клон домен-контроллера (можно RODC с жёстко заданным списком доступных учётных записей), может быть свой домен, дублирующий необходимые Sharepoint записи. В крайнем случае, это может быть тот же домен при условии соблюдения дополнительных процедур.
Мы протестировали ПО, оно прекрасно даже работало у нескоторых заказчиков. И вот в японской армии перестал обрабатываться MODBUS-траффик. То есть траффик идет, приложение слушает интерфейс, а не видит траффик.
В прод они издалека не пускают — сеть изолирована от интернета вообще. Траффик свой они нам тоже не дадут — он секретный.
Вот когда наш сотрудник туда приехал (с исходниками нашего ПО, кстати), он увидел, что в траффике часть чексамов идет обнуленными из-за того, что пакеты резаные от исходного PLC и бридж их дропает.
Вот мне очень интересно, как такое можно обнаружить было дома в Израиле на расстоянии 9000 километров в сухом и теплом IDE.
__
А в том месяце наше приложение перестало нормально работать в другой организации, потому что они… починили сервер. То есть у них сгорел сетевой интерфейс. Они его поменяли. MAC, соответственно, новый. В udev-persistance он получил свой новый адрес (eth7). А приложение сконфигурено было до ремонта на другой сетевой адрес (eth4). Эту проблему легко найти и легко починить. Но пойдите догадайтесь про udev-persistance в тестовой среде, где интерфейсы не ломаются, не меняют своего имени и не вынуждают копать в этом направлении.
… Вот мне очень интересно, как такое можно обнаружить было дома в Израиле на расстоянии 9000 километров в сухом и теплом IDE.
У вас проблема с сетевой инфраструктурой. При чём здесь программисты и IDE/vim?
...MAC, соответственно, новый. В udev-persistance он получил свой новый адрес (eth7). А приложение сконфигурено было до ремонта на другой сетевой адрес (eth4). Эту проблему легко найти и легко починить. Но пойдите догадайтесь про udev-persistance в тестовой среде, где интерфейсы не ломаются, не меняют своего имени и не вынуждают копать в этом направлении.
Мы всё ещё говорим о программистах и их IDE? Программист вообще не должен знать ни о каких eth7, у него максимум переменная из файла конфигурации должна считываться. В идеале, в виртуальной машине, в которой исполняется программа, интерфейсы вообще никуда не могут «убегать».
Всё остальное — забота админов/инженеров.
Собственно, вы только что продемонстрировали непонимание принципов DevOps, в основе которых лежит основополагающая позиция: нет своей территории девов и нет своей территории опсов. Есть только взаимная ответственность на всем протяжении лайфтайма.
Если у вас внутри программы захардкожен «eth4», то, извините, но на мой взгляд, это бардак, а не DevOps.
у него максимум переменная из файла конфигурации должна считываться
Смотрим на слова собеседника:
приложение сконфигурено было до ремонта на другой сетевой адрес (eth4)
Я однозначно это понимаю, что про eth4 было сказано в конфигурации, а не в коде.
Или в Вашем окружении "сконфигурено" это hardcoded?
В идеале, в виртуальной машине, в которой исполняется программа, интерфейсы вообще никуда не могут «убегать».
Простите, какая "в идеале" виртуальная машина? Привязка к конкретному интерфейсу вообще-то делается не просто так и не ради обычных приложений (которым максимум что задаётся это IP+порт), а или ради потока мультикастов, или специального IP стека, и/или особых транспортов типа Infininand/Myricom/etc. (которые могут тоже часть функций отдавать под видом обычного Ethernet). В виртуалку такое часто не сажают, даже при надёжно работающем VT-d.
Простите, какая «в идеале» виртуальная машина?
В идеале — любая. Но и в тех считаных случаях, когда действительно виртуализация создаёт ненадуманные проблемы — делаются старые-добрые тестовые стенды, и тестовый код выкатывается на них, а не правится на Prod.
Разговор начался с того, что программный код молча падает в Prod, и там же его программисты «героически» правят прямо на сервере с помощью vim.
Зато потом укатился на то, что есть вещи, которые по ряду причин никак не лечатся описанным Вами способом постепенно проката по пути dev -> staging -> production, распространяя devop-скриптами из тёплой идеальной IDE-подобной обстановки (кстати, а devop-скрипты эти кто и как отлаживал?) Почему так — где-то админзапреты, где-то недостаток времени и т.п. — уже вопрос не самый главный.
И вот тут Вы начали возражать по принципу "так не быва-а-ает!"
Ну ладно, не бывает. И вообще мы тут не работаем на результат (включая денежный), а просто собрались чего-то нажать на клавиатуре и посмотреть на искры, не так ли?
Но и в тех считаных случаях, когда действительно виртуализация создаёт ненадуманные проблемы — делаются старые-добрые тестовые стенды, и тестовый код выкатывается на них, а не правится на Prod.
И опять пропускаете главный тезис Вашего оппонента, что полной гарантии от всех проблем это всё равно не даёт, а часто и в принципе не могло работать.
Ваши советы годны только для php и тому подобных перлов с рубями, где действительно обстановка располагает и даже стимулирует к правкам на проде и тому подобной ереси.
У нас показыватель котиков упал, котострофа! Сделайте что-нибудь вслепую на проде, где мы отключили логи из мелочной экономии! Сделайте в стиле хакера из Swordfish, за две минуты!
Не надо в таких местах работать.
Кстати, правка кода на проде встречается — но совершенно другого вида. Изменение хранимок SQL. Вы их тоже Vim'ом будете править?
Очевидно, хранимки SQL — это второй случай, когда задача позволяет решать ее в IDE.Значит либо вы новичок, либо ваши задачи позволяют все делать в IDE.Кстати, правка кода на проде встречается — но совершенно другого вида. Изменение хранимок SQL. Вы их тоже Vim'ом будете править?
А чего вы не используете средства миграции для обновления хранимок?
Ctrl+F: MODBUS
О, вот вам пример когда мы правили файлы на сервере. Правда, обходились без vim потому что винда.
Дано: ферма серверов на Sharepoint. У заказчика есть свое ПО, с которым мы обязаны интегрироваться — и мы его третий месяц не можем поставить на Staging (а до этого год не могли допроситься у заказчика актуальной версии этого ПО).
При выкладывании на прод пролезла опечатка, из-за которой одна из страниц не работает. Что делать?
Вариант 1. Передеплоить проект, запросив технологическое окно в 8 часов. Риски — можем не уложиться в это окно; после деплоя могут всплыть еще ошибки.
Вариант 2. Исправить файл на сервере. Риски — в худшем случае поломаем еще одну страничку из сотни; но скорее всего успеем и эту ошибку отловить прежде заказчика.
Ну и какой вариант оптимальнее?
Нет, потом-то мы и staging настроили, и время деплоя сократили до 30 минут (а частичный вообще 5 минут идет всего), и даже CD настроили. Но это было только через полгода...
Респект и уважуха!
DevOps существует там, где Вы его внедряете.
Например, лично я любой новый проект начинаю с того, чтобы настроить CI/CD для пустого, ничего не делающего проекта (ну, он может выводить что-то в лог или, если это веб-сервис, 200 OK и helloworld в теле — но это просто чтобы проверить что он реально запускается на стейдже и заодно доступ к логам). Если в компании нет стейджа — либо внедряю, либо честно предупреждаю что прод будет по факту использоваться как стейдж и настраиваю выкат этого пустого проекта на прод. Если возможности лично у меня настраивать прод нет, а ответственные за это дело админы слишком заняты — настраиваю деплой в локальный docker swarm или через docker-compose. Если не дают CI — настраиваю выполнение тестов в том же локальном докере. Позднее эту конфигурацию будет достаточно просто выкатить куда угодно и чем угодно (даже если в проде не используется докер, то мои Dockerfile чётко покажут как и какое окружение должно быть настроено чтобы проект работал).
С нашим проектом так бы не прокатило :-) Но подход нравится.
Дело не в везении. Я пишу микросервисы, они обычно… микро, более или менее. Так что "с нуля" по факту что-то пишется каждые пару недель. Разгребать чужой мусор иногда приходилось, но разгребание тоже нужно начинать с настройки (или доведения до ума) CI/CD, написания минимальных док и тестов.
Ну и кроме того — а кто Вас заставляет приходить на такую работу, где нужно за кем-то разгребать, да ещё и без возможности делать это нормально? У нас рабства пока нет, если квалификация достаточно высокая вполне можно позволить себе выбирать интересные проекты, а если недостаточно высокая — выбирать такие проекты, которые помогут её быстро поднять.
Но в большинстве случаев проблема не в проектах, чужом мусоре, и прочих "причинах". Обычно проблема в нас самих. Кто хочет делать нормально — ищет способ/возможность делать именно так, кто не хочет — ищет причину почему так делать нельзя.
Я начинаю с настройки CI/CD не потому, что мне так хочется, а потому, что если кому-то нужен тот код, который меня попросили написать, то это значит, что этот код: a) должен корректно работать, а значит нужны тесты, которые нужно регулярно запускать, и b) должен работать не у меня на машине, а где-то на проде, а значит его нужно будет туда как-то деплоить, и в 99% случаев далеко не один раз, а значит это надо делать автоматизированно. Иными словами необходимость в CI/CD ничем не отличается от необходимости в Vim или IDE — это то, без чего просто нельзя эффективно делать свою работу. Необходимость в наличии CI/CD до начала работы, а не ближе к её концу — вызвана ровно тем же самым (как вы посмотрите, если вам скажут начинать писать код, но текстовый редактор или IDE пообещают выдать ближе к концу проекта?).
как вы посмотрите, если вам скажут начинать писать код, но текстовый редактор или IDE пообещают выдать ближе к концу проекта?И так бывает. Когда с железом общаешься — то ситуация когда вначале проекта есть только доки, а компилятор (или, что хуже, IDE) появляются уже ближе к концу проекта — достаточно типична.
В конце-концов с этого Билл Гейтс со своим знаменитым Бейсиком начинал.
Но это не значит, конечно, что нужно после этого код на доске писать (в той же истории с Бейсиком фигурировал эмулятор, если вспомните).
а кто Вас заставляет приходить на такую работу, где нужно за кем-то разгребать, да ещё и без возможности делать это нормально?
Чтобы писать что-то с нуля, нужно подловить компанию на самой первой стадии. Компании — не грибы. Они не рождаются каждую секунду, чтобы на месяцок там поработать.
А говорить, что каждый микросервис вы пишете с нуля… ну это вранье или компания просто крошечная и вы там один себе король. Даже если вы начнете с нуля, через месяц 20 других разработчиков, управляемых как собственной халатностью, так и давлением бизнес-нужд, превратят ваш продукт из микросервиса в адовую помойку.
Вы наверно в НИИ работаете, раз у вас там такой покой, чистота и идилия. Не иначе.
Чтобы писать с нуля достаточно иметь такую архитектуру, которая позволит принять решение следующую фичу делать в виде отдельного микросервиса. От размера компании это не зависит, от архитектуры приложения — да.
Если 20 разработчиков месяц будут ковырять один микросервис — это уже не микросервис.
Я работаю в разных местах, потому что фрилансер. Но НИИ пока не попадались, всё больше обычные коммерческие компании.
Что касается гита — тоже неверно. Какая вам разница в какой ветке какя фича, если в конце концов все это сливается в нестабильную ветку?
Проще, когда один мастер и он должен быть стабилен всегда.
Мастер похороните. Не трогайте мастер. Туда сливают только из стабильных веток между сменой мажорных версий. То есть дико редко.
— Чтение и навигация по коду
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 эффективнее.
я уже писал про дискретность операций, все вимеры понимают что вим это редактор, и не пытаются делать то что вы делаете в IDE, для этого всего есть другие приложения которые лучше справятся с этой задачей(и даже лучше чем IDE), по этому и шутка была про unix way…
правда заминусили, наверное не поняли))) но повторюсь
Три года шкодил в vim: не мог выйти, на 3 год понял что такое юникс вей)))
Например, даже 1 ошибка, замеченная IDE и исправленная оперативно, может экономить минуты и, иногда, часы времени, а разница в скорости правки столько не даст. Довольно много раз находил NPE в Java проектах при code review таким образом (ну как находил… просто читал подсказку, которую не осилил прочитать первоначальный программист).
Удивляет частая аргументация, что vim лучше, а если кто-то думает не так, то он:
— некомпенентент
— не умеет работать в vim
— если даже умеет (например, использую его для правки настроек на тестовых серверах, хотя все реже с внедрением практик DevOps), то, значит, умеет недостаточно
Не знаю приложений, которые лучше справятся с отладкой, чем IDE. Да и про другие приложения как-то примеры на ум не приходят.
А про Unix way вы сами себе противоречите (ниже в комментарии): то IDE вызывают внешние команды (и это плохо), то IDE реализуют что-то внутри (и это плохо). Понятно, что сейчас никто не будет что-то реализовывать самостоятельно, если есть возможность адекватно переиспользовать что-то существующее.
вы меня слышите? vim дает возможность удобно редактировать текст… а
ваша одна ошибка означает что вы не пишите тестов, это не как не относится к IDE или к Vim… я не писал что плохо вызывать внешние команды… почитайте про интерфейс к CLI программам, про микросервисы, ...
тесты… я не беру классическое ТDD, но все же если разработка ведется через разработку интерфейсов то скорее всего начинают с тестов которые отображают требования, а в данном случае IDE не нужно, так как вы требования выкатываете в виде тестов, а потом пишете код… это другой подход к программированию.
Есть проекты в которых не принципиально наличие дополнительных функций из IDE. Например, сам не использовал IDE для Ruby on Rails проектов на несколько разработчиков на несколько лет: и объем кода небольшой, и динамические языки тяжело поддерживаются IDE (при этом был купленный RubyMine, но не пошел).
Если же объем кода большой и язык со строгой типизацией, есть много подсказок в IDE по типичным ошибка программирования на этом языке и на этой платформе (как в IDEA для Java), то слишком расточительно не пользоваться этим.
По поводу обвинений в некомпенетности (тесты, cli, микросервисы), то не надо так. В предыдущем комменте писал, что это моветон. Применение этих техник не означает, что VIM по сумме показателей вдруг становится более эффективным, чем IDE. Вы правда думаете, что новые редакторы (Atom и Visual Studio Code) написали люди, которые ничего не слышали о VIM? Если их написали таким образом, каким написали, то все-таких Emacs победил в споре с VIM, хотя и сам умер.
я разделяю процесс создания архитектуры и блабаблалалала, до процесса написания кода…
меня раздражают эти долбанутые подсказки IDE мигание на моих 2 мониках всякой ерунды, я и без того знаю где я мог ошибиться, а где сейчас не соответствует код стайлу мой код, зачем мне вся эта мешура? я и без IDE напишу как надо… а когда мне понадобится работать с БД я открою соответствующее приложение, когда мне надо будет закомитить, я воспользуюсь гитом, а не IDE
смысл в том что работа ведется по другому… каждому свое.
и чем же хороша IDE, а тем что вам не надо делать рутинных задач при создании проектов на JAVA, QT… добавление картинок в проект, зарисовку UI, вот плюс, когда вы избавляетесь от рутины и отдаете это на автоматическую генерацию кода… Вот плюс IDE, хотя как правило вы просто не знаете что IDE запускает команды за вас, для того что бы вы это не делали вручную. Или как правило взяты алгоритмы с прог которые заточены под определенный функционал.
Если вам нужно видеть дерево наследования, подсказки аргументов, то обычно у меня в голове два арумента…
либо у человека нет спроектированного решения, слабая память
ну или архитектура приложения овно, так как она не интуитивна...
все равно размер и ограниченность в сроках не позволяет сначала досконально понять приложение, а уже только потом что-то в нем дорабатывать.А не является ли это типичным случаем феномена «мне некогда точить топор, мне надо рубить лес»?
Если у вас нет хорошего представления о том что это за код и что он делает — то вы точно уверены, что его «дорабатывания» пойдут проекту на пользу?
Скорее это проявление "мне некогда считать число деревьев в лесу, мне надо вырубить вот эти два".
Для проектов 10+ и руководитель не понимает что там полный аут…
Скажу вам так бегите с этих проектов, если от вас требуют работать с овном и при этом не понимают что надо переделать, бегите, вы не добъетесь ровным счетам нечего.
У меня такое было, начальник отдела программирования требовал костыли на костылях… не какого гита, не какого рефакторинга, вообще не чего, только кастыли, бегите от туда, ваш ум и практику подымут где то еще...
Кроме крутых проектов, на работе дают зарплату. Почему ВСЕМ программистам обязательно нужно быть стартаперами и мутить проекты с полетом на марс?
Не давайте такие советы всем подряд.
И то, что вся структура кода не помещается у человека в голове, не говорит о том, что он недостаточно крут или что это — говнокод. Это всё очень странные попытки пристыдить тех, кто пользуется удобствами IDE.
для этого есть декомпозиция и модульность… и изучение в данном случае проходит быстрее для конкретной задачи. Как правило при хорошем разделение на модули или пакеты все это хорошо документируется.
Декомпозиция и модульность не отменяет необходимости разобраться в новом чужом коде/модуле. Если детали реализации не нужны, хватит и документации. А если я хочу узнать, как это сделано (ищу причину дефекта, например), удобные средства навигации по коду + отладка помогут мне сделать это эффективнее. Ничего постыдного в этом не вижу.
Если често я незнаю…
Может про это забывают но проект начинается с подхода сверху-вниз, разработка идет через интерфейсы, лучше дать 2 хороших public метода чем 20 непонятно каких, всегда проще давать чем забирать, черный ящик вам дает возможность переделать что-то внутри класса, а не в 5000 файлах, декомпозиция задач вам всегда укажет как делить и на что делить. Структурирование файлов, кода эта статья http://sergeyteplyakov.blogspot.ru/2016/11/horizontal-and-vertical-architectural.html должна намекнуть на выход из таких ситуаций…
Обычно проблема в хреномвом проектировании или менеджменте.
Можно быстро окинуть взглядом общую структуру и после этого перейти к деталям.Для этого давным-давно были изоберетены ctags.
Возможно, что-то придется порефакторить — опять же IDE поможет не допустить глупых ошибок.А вот тут — как раз и «порылась проблема»: глупых ошибок вы, может быть, и не допустите — но зато «умные» можете устроить легко. А если вы будете, как и положено, производить рефакторинг только глубоко разобравшись в коде, который вы собрались рефакторить, то выигрыш от всех средств быстрого рефакторинга окажется уже куда как менее существенным.
Но в общем и целом вы, конечно, правы: если бы VIM превосходил IDE по всем параметрам — то кто бы вообще использовал IDE, в принципе?
я пользовался IDE, когда еще был не опытен и могу сказать ОГОГО как помогало, но потом я понял что оно не важно, а более того иногда мешает задуматься над архитектурой, так как слишком много позволяет, это точно также как я изучал Ruby и мне язык нравился, но понял что он слишком многое позволяет сделать, и я перешел на более строгие языки, сейчас могу и Ruby занятся, но и создание программ у меня другое, совершенно другой процесс и я на многие вещи смотрю по другому
Тем не менее, имея надежные автоматические средства, делать это удобнее и быстрее. Мне в этом помогает IDE, кому-то — vim с соответствующими плагинами и конфигом.
Мне лишь довольно странно читать от некоторых участников дискуссии комментарии вида: «если вы используете IDE, значит, вы либо в говнокоде по уши, либо разработчик хреновый, либо и то, и другое».
меня лично просто раздражает… что когда пишут о режимах вим почему то набегают люди использующие IDE и начинаю писать что оно классно так как можно быстро поменять имя метода в 500+ файлов, что у них сразу окружение для VCS, БД… и крутое автодополнение и еще куча всего всего...
Речь то не об этом в статье, по этому я и пишу что IDE не обязательно, кому что удобно…
Я сам использую IDE когда понимаю что там с какой-то проблемой проще разобраться, но 99,999% времени использую vim
Мне лишь довольно странно читать от некоторых участников дискуссии комментарии вида: «если вы используете IDE, значит, вы либо в говнокоде по уши, либо разработчик хреновый, либо и то, и другое».Нет. Тут логика другая. У нормального разработчика нет нужны в постоянных рефакторингах. Соответственно воспевание инструментов, усложнающие локальные правки и упрощающих «беспорядочное движение сущностей в коде» — свидетельствует о низкой квалификации.
Но тут во многом всё зависит от того, где простые локальные правки удобнее делать. И тут я не вполне уверен, что VIM выиграет — но, по крайней мере у нас, люди, которые им пользуются порождают ничуть не худший код, чем те, что пользуются IDE, так что думаю тут скорее вопрос привычки.
Другое дело, что у меня нет достаточной статистики для того, чтобы однозначно сказать — VIM'еры это «настоящие профи» или «вымирающий вид».
Точно так же сам факт использования Vim'а не делает никого ни «настоящим профи», ни «вымирающим видом». Настоящий профи использует свои инструменты для эффективного достижения качественного результата. Какими бы эти инструменты ни были. Капитанство, но тем не менее.
Я лично не писал что все вимеры профи или наоборот.
Единственное на что я указал… если уж так часто важны такие вещи как изменения имени одного метода в 500+ файлов, то скорее всего проблема с кодом, дизайном, менеджментом…
И я уточнял одним из комментариев что вим заставляет изначально менять рабочий процесс. Я уточнял что часто начинающие программисты не могут без IDE, так как многие вещи им даются нелегко, но я не где не писал что начинающие программисты не вырастают до спецов пользуясь IDE
я так сказать основываюсь на своем опыте и наблюдении...
я долго работаю в vim, и в какой то момент все же начал разрабатывать код. Долго мучился, всегда чего то не хватало.
Я начал пользоваться IDE, да был огромный восторг от возможностей, плагинов, но вима не хватало, вроде решение было… установка вим-мод плагина. Но все равно чего-то не хватало. Так я проработал почти год, причем меня одну IDE на другую.
В конечном итоге было понятно, что я толком не умел читать документацию, проектировать, всегда размазывал код по проекту, вечно спешил с решением, правда скорости разработки это не увеличивало, а в дальнейшем только тормазило разработку, не делал должного рефакторинга… ну и мне не кому было бить по рукам за такое вот программирование. А самое фиговое что IDE мне позволяло все это делать и вим далеко там был не причем(таких проблем у многих начинающих разработчиков я вижу полно). Так вот как итог, я не осуждаю или говорю что IDE это плохо или хорошо… я утверждаю что проблема где-то еще...
так и чем вам вим мешает это изучить, если честно то меня уже бомбит, вим то чем в этом мешает? найдите другое приложение для изучения кода если.....
Модульность… декомпозиция… дока и еще куча всяких непонятных слов.
Не надо рефакторить в более менее спроектированом приложении 100 файлов, для этого есть понятие черный ящик и проектирование через интерфейс. Если студенты разрабатывали это приложение 10+ лет, то я бы даже не взялся, там скорее архитектурных ошибок настолько много что проще переписать, а скорее всего проще собрать из готовых решений и допилить до нужного.....
У меня такое было, я сейчас не о ситуации в семье и т.д. даже могу сказать что у меня второй год оч. не хорошо проходит…
Но если есть возможность ищите там где будут вам помогать специалисты умнее чем вы(множественное число).
я сам пробираясь к этой профессии работал когда платили зарплату иногда по 2-1-5 тысячи несколько раз за месяц в место того что бы выдать нормальную ЗП раз в месяц или как положено 2 раза в месяц…
Я это все понимаю, но и толку от такого места работы почти ноль, понятно что жрать хочется и жена косо будет смотреть…
Но стремление к лучшему должно быть.
меня уже бомбит… хоть минусы хоть в карму похер…
если вам не нравятся режимы и вим, то не пользуйтесь…
для таких и была написана статья…
те кто оценили вим не пользуются IDE, но вим это не ide — это пилять редактор… и мне пох чем вы там пользуетесь, ни я не один вимер вас не заставляет и не пытается уговорить...
это как игра на гитрае, нужно очень много потратить времени на постановку, уменьшение движений пальцев… вы готовы? нет… так пользуйтесь IDE...
нам всем вимерам просто похеру… как вам удобнее так и кодируйте....
еще раз повторюсь меня бомбит…
я незнаю сколько у нас дибилов программистов которые не могут понять строк текста из статьи…
черным по белому написано… если вам не нравится переключение между режимами то вим не для вас… дибилыыыыы остановитесь, вы себя действительно считаете программистами когда вы простой текст понять не можете?...
Киллер фича Vim