Посмотрите мой комментарий выше, где я объясняю в чём суть. Вы также всё неправильно поняли и додумали свою версию того, что в стайл-гайде, которая ничего общего не имеет с реальностью, а плигин режет мусор и пробелы на концах строк, где отступы табами, являются мусором, как и табы на концах не пустых строк, за исключением комментариев (опять же смотрите ссылку на мой другой комментарий.
Вы выдумали какие-то свои аргументы, основываясь на выдуманных обстоятельствах, но тем не менее оправдывать ограниченность своей IDE плохим стайл-гайдом, потому что IDE не может под него подстроиться, — я не уверен, что это сколько-нибудь положительный или хотя бы оправдывающий пункт для обсуждаемой IDE.
Вы опять неправильно поняли суть, не допускает стайл-гайд смеси табов и пробелов, а плагин режет просто мусор, не трогая при этом того, что резать не нужно.
Требование наличия отступов в пустых строках тоже выглядит странно: автоотступ умеют почти все нормальные редакторы (e. g., set cindent).
Это не требование, по стайл-гайду мы оставляем табы на пустых строках (например для того, чтобы при подсвеченых символах таба визуально видеть цельный не раздробленный блок), а в комментариях я их не вырезаю именно чтобы потом снова их не добавлять, в случае если код будет раскомментирован. То-есть опять же вы всё поняли неправильно.
Добавлю слово про производительность vim, как-то в одном jabber-чатике люди обсуждали у кого на сколько редакторы лагают открывая один большой SQL файл (в миллион строк или что-то около того), я открыл для фана в vim, с подсветкой, свободно перемещался в начало-конец, осуществлял поиск и совершенно никаких лагов не заметил.
Нет, вы неправильно поняли идею плагина. Он режет пробелы/табы на концах строк, но не режет их если в строке ничего кроме табов нет (когда отступы оформляются в виде табуляции), при этом режет пробелы, на концах строк, где есть отступы табами (не трогая при этом табы). При этом не режет табы (но пробелы режет) в закомментированных кусках, т.к. коммент — это уже не пустая строка. В общем в одно предложение суть мне сложно уложить, но делает оно именно то, что я хотел, я уверен, ни в одной IDE нет столько отработанного механизма по крайней мере из коробки.
Честно говоря — понятия не имею, я знаю как минимум пятерых пользователей WebStorm (из разных компаний), и от всех от них постоянно какие-то проблемы, их IDE постоянно портит им работу, как её укротить они по всей видимости не знают, может быть это невозможно, может быть это слишком сложно и проще написать плагин для vim (как это сделал однажды я например, чтобы соответствовать стайл-гайду, после чего у меня никаких проблем не было), может быть стоит усомниться в компетенции разработчиков, кого винить, я не знаю, меня это мало интересует, я вижу лишь тенденцию среди пользователей этой IDE, которая убеждает меня в том, что я как минимум ничего не теряю, не используя её.
Лично у меня порядка 50-и плагинов (туда же входят плагины подсветки синтаксиса различных ЯП), из постоянно и часто-используемых плагинов (именно которые добавляют функционал), штук 15 перечислить по памяти могу, много кастомных хоткеев, большинство так или иначе регулярно использую, но обращаю внимание, что соль работы в vim (за что его многие и любят), — это не 5-и ступенчатые аккорды, а гибкие и мутабельные последовательности, таким образом какие-то несколько даже базовых приёма могут быть использованы в разных комбинациях, получая в итоге разный эффект. А вообще набор основных комбо в итоге превращается в набор рефлексов.
Вот чисто для примера w — это перемещение через слово, окончание iw обычно означает «слово», и d — удаление, v — визуальный режим (выделение), c — удаление и переход в режим ввода, далее фантазируем (на самом деле регулярно используемые комбо, которые под коркой отбиваются на автомате):
diw — удалить слово
ciw — заменить слово, что-нибудь набрав
viw — выделить слово
p/P — вставка из буфера обмена перед/после, таким образом viwp — заменить слово тем, что в буфере.
Окончание i+кавычка или скобка — обычно означает всё, что внутри кавычек/скобок, таким образом не уходя от выше-приведённых примеров:
di' — удалить всё что между одинарных скобор
ci} — заменить всё, что внутри фигурных скобор, что-нибудь набрав
vi) — выделить всё, что в пределах круглых скобок
Также взять числовой префикс повторений, Y — скопировали строку, и 10p продублировали её 10 раз.
Как видите, сказать о кол-ве «хоткеев» довольно сложно, у вас есть небольшой набор базовых рефлексов, которые могут свободно комбинироваться между собой.
По первым двум пунктам речь идёт о статическом анализе кода. Вообще это сильно зависит от языка, с которым вы работаете, и где-то такой анализ просто мешает и раздражает, плохо применим. Вот например у некоторых коллег по работе — WebStorm, от чего-то они его так любят, но он ужасен, его встроенный линтер JavaScript/TypeScript, который, как я понимаю, пытается анализировать код, делает это отвратительно, постоянно сыпя ошибками там, где их в действительности нет, не говоря уже о том, что то и дело врубается форматтер, из-за которого нарушаются стайл-гайды и пулл-реквесты отправляются на доработку (но это уже другая история про хвалёные IDE). CtrlSF же находит вхождения и выводит их в один буфер, который ведёт себя как и любой другой vim-буффер, и всё что ты знаешь о редактировании в vim, — применимо, ты просто рассматриваешь чанки, делаешь в них изменения и затем коммитишь (просто как обычно для vim сохраняешь буффер), можно просто сделать автозамену с подтверждениями по вхождению (что обычно и происходит в моём случае, лично мне этого хватало пока с лихвой). Нужно иметь в виду что я описал только узкий пример возможностей, можно открывать отдельные файлы из буфера вхождений и работать с ними более детально например.
А вот вопрос третьего пункта я вообще не понял, к чему он? Возможно я уже дал на него ответ выше, описав механизм работы, и результат будет зависеть от того, в каком режиме вы находитесь, в каком месте буфера с вхождениями, и вообще от вашего vim-конфига, вы в конце-концов можете забиндить эти клавиши на что угодно.
Не могу не согласиться, скорость печати — дело третье, это помогает разве что в чатиках каких-нибудь изьясняться, чтобы текст поспевал за мыслью. А вот рефлексы каких-нибудь комплексных команд в редакторе — полезный навык, и вим предоставляет кучу возможностей для этого. Многих отталкивают всякие 5-и ступенчатые комбо, но когда они словно сами отбиваются в burst mode, — давление рутины ощущается меньше.
Имеется в виду, что не используется правый большой палец? Я вот иногда использую, хоть и очень редко, несмотря на то что пытался вытренировать рефлекс перекрёстного нажатия, когда перед этим символ был на другую руку, в итоге счёл непрактичным затраты на это дело. Мой метод печати в таком случае наверное можно назвать 9,5-пальцевым, вот это каламбур!
Для комфортной работы с кодом необходимо установить несколько плагинов. Мне хватило 33.
У автора хорошо с чувством юмора. У себя насчитал около 50-и, ну это с учётом разностороннего набора ЯП. Для старта можно и в 10 спокойно уложиться, и постепенно наращивать, по мере ощущения что вот такой-то фичи не достаёт.
Но главное, что меня заинтриговало, — это:
слепой 9-ти пальцевый метод печати.
Что это за метод такой? У автора не достаёт пальца? Очередная шутка? Или действительно есть какой-то такой способ?
А почему тогда сразу одна «душа» на «мозг-компьютер»? Может у нас нет никакого своего «оператора за клавиатурой», а мы просто компьютеры в каком-нибудь компьютерном клубе, и нами пользуется то один, то другой «оператор»? Мы же можем впадать в разные эмоциональные состояния например, может это результат влияния разных «операторов»? Меня всегда удивляют высказывания аля: «давайте не будем этого отрицать, мы ведь наверняка не знаем», — но при этом предлагается не отрицать какую-то устоявшуюся локальную парадигму, которая обычно радужная и красивая в лучших традициях коммерциализованного нью-эйдж, так давайте не будем отрицать любые немыслимые варианты, которые возможно чрезвычайно ужасны и отнюдь не привлекательны, может мы просто игровой отходняк, общественные затасканые компьютеры, и нет у нас никакой своей души, а нами пользуются как марионетками?
Та, которая одобряет и восхваляет имперские амбиции этой страны конечно же. Каждая статья должна начинаться и заканчиваться словами: «слава Ким Чен^W^W сами знаете кому».
Вы выдумали какие-то свои аргументы, основываясь на выдуманных обстоятельствах, но тем не менее оправдывать ограниченность своей IDE плохим стайл-гайдом, потому что IDE не может под него подстроиться, — я не уверен, что это сколько-нибудь положительный или хотя бы оправдывающий пункт для обсуждаемой IDE.
Это не требование, по стайл-гайду мы оставляем табы на пустых строках (например для того, чтобы при подсвеченых символах таба визуально видеть цельный не раздробленный блок), а в комментариях я их не вырезаю именно чтобы потом снова их не добавлять, в случае если код будет раскомментирован. То-есть опять же вы всё поняли неправильно.
Вот чисто для примера w — это перемещение через слово, окончание iw обычно означает «слово», и d — удаление, v — визуальный режим (выделение), c — удаление и переход в режим ввода, далее фантазируем (на самом деле регулярно используемые комбо, которые под коркой отбиваются на автомате):
p/P — вставка из буфера обмена перед/после, таким образом viwp — заменить слово тем, что в буфере.
Окончание i+кавычка или скобка — обычно означает всё, что внутри кавычек/скобок, таким образом не уходя от выше-приведённых примеров:
Также взять числовой префикс повторений, Y — скопировали строку, и 10p продублировали её 10 раз.
Как видите, сказать о кол-ве «хоткеев» довольно сложно, у вас есть небольшой набор базовых рефлексов, которые могут свободно комбинироваться между собой.
По первым двум пунктам речь идёт о статическом анализе кода. Вообще это сильно зависит от языка, с которым вы работаете, и где-то такой анализ просто мешает и раздражает, плохо применим. Вот например у некоторых коллег по работе — WebStorm, от чего-то они его так любят, но он ужасен, его встроенный линтер JavaScript/TypeScript, который, как я понимаю, пытается анализировать код, делает это отвратительно, постоянно сыпя ошибками там, где их в действительности нет, не говоря уже о том, что то и дело врубается форматтер, из-за которого нарушаются стайл-гайды и пулл-реквесты отправляются на доработку (но это уже другая история про хвалёные IDE). CtrlSF же находит вхождения и выводит их в один буфер, который ведёт себя как и любой другой vim-буффер, и всё что ты знаешь о редактировании в vim, — применимо, ты просто рассматриваешь чанки, делаешь в них изменения и затем коммитишь (просто как обычно для vim сохраняешь буффер), можно просто сделать автозамену с подтверждениями по вхождению (что обычно и происходит в моём случае, лично мне этого хватало пока с лихвой). Нужно иметь в виду что я описал только узкий пример возможностей, можно открывать отдельные файлы из буфера вхождений и работать с ними более детально например.
А вот вопрос третьего пункта я вообще не понял, к чему он? Возможно я уже дал на него ответ выше, описав механизм работы, и результат будет зависеть от того, в каком режиме вы находитесь, в каком месте буфера с вхождениями, и вообще от вашего vim-конфига, вы в конце-концов можете забиндить эти клавиши на что угодно.
CtrlSF Правда?
У автора хорошо с чувством юмора. У себя насчитал около 50-и, ну это с учётом разностороннего набора ЯП. Для старта можно и в 10 спокойно уложиться, и постепенно наращивать, по мере ощущения что вот такой-то фичи не достаёт.
Но главное, что меня заинтриговало, — это:
Что это за метод такой? У автора не достаёт пальца? Очередная шутка? Или действительно есть какой-то такой способ?