Комментарии 51
Это очень индивидуально, также сильно зависит от предыдущего бэкграунда.
Для начала нужно освоить базу, пройти какой-нибудь vimtutor, пройти VIM Adventures. Начать работать в Vim сначала "по-тупому", но время от времени добавлять к своим навыкам что-то новое, можно найти какой-нибудь ресурс, который раз в день постит новый хоткей или описание фичи, и как этим пользоваться. Выписывать интересное на бумажку и стараться сразу начать употреблять.
Считаю также для эффективности крайне полезным сразу освоить слепую 10-и пальцевую печать, для этого полно онлайн-ресурсов. Vim как никакой другой редактор для этого очень приспособлен прямо "из коробки".
Смысл не в том чтобы сразу загрузить в себя большой массив знаний, навыков, умений. А в том, чтобы начать с чего-то, и постепенно улучшать этот навык, расширять понимание и кругозор в плане фич, возможностей, способов сделать что-то.
Вообще могу от себя дать хороший совет: наблюдать за тем, как ты работаешь в Vim, если ты чувствуешь что повторяешь что-то рутинно, шаблонно, по 10 раз одну последовательность действий, — значит самое время подумать или поискать в интернете или на форумах, как это можно автоматизировать или упростить.
Если владеете слепой печатью, то команды постепенно учатся. Опять же, никто не мешает вам использовать часть команд или сочетаний у вас в IDE. А выигрывать во времени я начал сразу — просто vim быстрее работает. С другой стороны я не использую всю мощь IDE. Мне для 80% задач хватает обычного редактора типа vim или VS Code.
По поводу "графичности", у Neovim есть различные GUI, например есть такой с поддержкой лигатур в шрифтах.
Есть и всякие экзотические проекты вроде onivim, которые сильно изменяют привычный облик vim, делая его более похожим на какой-нибудь sublime или atom, предоставляя различные не-текстовые элементы интерфейса.
Полный список доступных GUI для Neovim можно найти тут.
Сколько времени нужно, чтобы запомнить все комбинации серьезной ИДЕ, например, IntelliJIDEA?
Думаю, что сравнимо с vim'ом. Дело ведь в логике наименования и конструирования шоркатов.
Дело ведь в логике наименования и конструирования шоркатов.
И в виме это для почти всего — мнемоника, а в идее — случайный набор модификаторов и букв.
Ну, не случайный. Но логика явно была из серии — ctrl+c/x/z / shift+ins сделаем как в остальной системе, а остальное распихаем по ограниченному (!) набору шоркатов как сможем. В результате получается весьма странные комбинации из трёх одновременно нажимаемых клавиш.
vim'овские же комбинации больше похоже на макросы — максимальная расширяемость
слухи о том, что для эффективного использования вима надо выучить какие-то невероятные множества магических команд, сильно преувеличены. Ну да, их там много, но я не встречал еще ни одного вимера, который бы пользовался ими всеми. Все пользуются каким-то сильно ограниченным подмножеством, у каждого своим.
Да и если подумать, то ведь у обычных текстовых редакторов тоже есть много хоткеев для управления с клавиатуры. Даже прямо тут, в форме для добавления коммента. Очистить строку — Home,Shift+End,Del, назад — Ctrl+Z, и т.п. И ими тоже кто-то пользуется, а кто-то нет.
Нисколько. Как только начинаются реальные задачи, вроде отладки, рефакторинга классов, вычленения интерфейсов, генерации заглушек и т.д., все эти ваши vim, Atom, VSCode, Sublime, Notepad++ и иже с ними, тихонько уступают продуктам от JetBrains. Поэтому vim никогда не выиграет у нормальных IDE.
vim — это про шаблонное редактирование текста. Если код требует шаблонного редактирования, значит что-то с ним не так. В 99% это спагетти код или код с низким уровнем абстраций.
Ребята, не надо путать теплое с мягким. Полноценные IDE и vim даже с кучей плагинов всегда будут разными. В vim удобно редактировать данные и простой код вроде типичного HTML.
У IDE уже сейчас есть достаточно мощная система анализа кода на пример дубликации, спорных моментов, еще немного и IDE начнут подсказывать, какой дальше писать код и т.д. Т.е. пока они делают подсказки через простые штуки вроде геттеров/сеттеров/ и т.п., но развитие AI очень скоро начнет предсказывать вещи вроде простых условий.
// например
if (!value) return;
// или
fh, err := OpenFile(...)
if err != nil {
defer CloseFile(fh)
}Еще немного и такие стандартные куски начнут генерироваться автоматически с учетом контекста. Пока это реализовано в виде шаблонов, в стиле vim так сказать, однако время не будет стоять на месте.
Мой совет — не тратье время на изучение очередного текстового редактора, он уже есть внутри вашей IDE. Потратьте время на изучение горячих клавиш IDE, и да, вы все их можете сменить по своему усмотрению. Да и на изучение самой IDE, вы будете сильно удивлены, насколько продуктивнее вы сможете работать.
Как только начинаются реальные задачи, вроде отладки, рефакторинга классов, вычленения интерфейсов, генерации заглушек и т.д., все эти ваши vim, Atom, VSCode, Sublime, Notepad++ и иже с ними, тихонько уступают продуктам от JetBrains. Поэтому vim никогда не выиграет у нормальных IDE.
vim — это про шаблонное редактирование текста. Если код требует шаблонного редактирования, значит что-то с ним не так
То есть если в коде нет классов, интерфейсов и заглушек с ним что-то не так?
У IDE уже сейчас есть достаточно мощная система анализа кода на пример дубликации
Я б её вырубал. Вреда от нее больше чем пользы, а некоторые горе-девелоперы потом путают принцип DRY и дублирование кода.
Т.е. пока они делают подсказки через простые штуки вроде геттеров/сеттеров/ и т.п., но развитие AI очень скоро начнет предсказывать вещи вроде простых условий.
Если вы активно используете генерацию геттеров/сеттеров то что-то с вашим кодом не так -_- (геттеры/сеттеры не нужны).
Вы не подумайте, я исключительно за IDE, особенно в мейнстрим языках. Просто не ради этих фич, а ради продвинутого автодополнения, других инспекций, кастомных шаблонов, дебаггинга, удобной настройки всего этого и т.п.
Либо я плохо искал, либо здесь еще не упомянули — ко всем IDE от JetBrains есть отличное расширение IdeaVim, которое предлагается поставить прямо со стартовой страницы после установки IDE. Можно, так сказать, взять лучшее от двух миров.
К VS, VS Code и другим IDE/редакторам зачастую тоже есть аналогичные плагины.
Даже для браузеров есть vim-style плагины для более удобной клавиатурно-ориентированной навигации.
AI очень скоро начнет предсказывать вещи вроде простых условий.
TabNine это уже делает. Причём работает и в JetBrains и в популярных редакторах.
Нисколько он никогда не начнёт выигрывать в том смысле который вы(и куча людей включая меня в прошлом) рисуете у себя в голове :) Но сами по себе IDE — переоценены, это просто способ посадить не очень квалифицированные кадры выполнять типовые рутинные задачи максимально быстро(и посадить и выполнять).
Раньше я дивился с того, что очень технически крутые люди польюзуются для разработки каким нить notepad++ или vim без плагинов. Мне казалось, что я умнее и я им говорил что-то в духе — блин, ну тут даже интеграции с отладчиком нет, ты таааак долго делаешь эту хрень, смотри как у меня в <idename> всё круто. Они соглашались — круто, прикольно, так держать :) Но продолжали пилить код в текстовом редакторе, иногда даже без подсветки синтаксиса. И выполняли задачи, особенно сложные, в разы быстрее чем я…
На данный момент — поймал себя на том, что у меня уже пару месяцев как сломалось автодополнение, но меня это чет как то даже и не парит, вот думаю — может пора начать удалять плагины? Когда по большому счёту используешь только редактор, а те миллисекунды которые выскакивает комплит начинают тебя напрягать а и сбивать с мысли, а инфа в этом комплите выглядит как "да ладно, спасибо кэп", это видимо первые звоночки.
Я это к чему? Когда знаешь чего написать и как отладить — ты просто это записываешь и всё, с тем же усилием, как и документацию, просто на другом я зыке. Потом берёшь и отлаживаешь. А свистелки помогают пока не очень точно уверен, как ты собираешься сделать то, что собрался делать.
Чем хорош конкретно vim? Тем что с ним просто работать на удалённой машине, и он позволяет достаточно просто(так что можно хоть под каждый ишью писать скриптец) и вешать их на горячие клавиши или просто держать близко в истории. Ну и руки с хоумроу можно не убирать практически никогда (не для всех это плюс, помахать мышкой — тоже своя развлекуха имеется). Ну, ещё конфиг сравнительно просто утаскивается и размножается.
те миллисекунды которые выскакивает комплит начинают тебя напрягать а и сбивать с мысли
Абсолютно. +100500.
Чем хорош конкретно vim? Тем что с ним просто работать на удалённой машине, и он позволяет достаточно просто(так что можно хоть под каждый ишью писать скриптец) и вешать их на горячие клавиши или просто держать близко в истории. Ну и руки с хоумроу можно не убирать практически никогда (не для всех это плюс, помахать мышкой — тоже своя развлекуха имеется).
Польза IDE переоценена, а польза работы на удаленной машине нет?
А остальное реализуемо в IDE.
Работа на удалённой машине так же реализуема в некоторых IDE. Польза от работы на удалённой машине в том, что вы можете трудиться с лёгкого и сравнительно дешёвого терминала, утилизируя мощное серверное железо, без шума пыли. Я вот например сильно не уверен, что вы прямо сейчас сходу сможете начать работать с кодовой базой chromium на своём текущем конфиге без его апргрейда по железу :)
а вот запросто, не понимаю с чего разработчикам вообще жаловаться или ущемшять себя в железе? ПК это то на чем я работаю и зарабатываю, почему бы не купить мощный удобный ноут за 200k? И ещё в вопросе vim vs ide я за ide особенно когда начинаю задвигать что он быстрее, у меня вопрос возникает, у вас железо в 2000х засатряло?
Какую задержку между событием и откликом на него вы считаете приемлемой?
Несмотря на ультрамощное железо некоторые современные приложения на electron или какая-нибудь IDE, могут легко дать задержку с полсекунды на всплывание какого-нибудь автокомплита! Это совершенно неприемлемо, не потому что полсекунды — это как полвечности, а потому что таких событий у опытного разработчика во время работы с кодом могут происходить десятки на полминуты. И если отклик на рядовое событие будет длиться полсекунды, или даже 300-400мс — это замедлит работу в несколько раз (компьютер не поспевает за ходом мысли/рефлексами пишущего код), не говоря уже об общей раздражительности от дискомфорта использования таких решений, когда начинаешь ощущать, что тебе нужно ждать.
Если у вас всё хорошо с 10 fingers typing, у вас развиты рефлексы работы в вашем окружении, то такие задержки сразу начинают ощущаться и доставлять дискомфорт, чем их меньше, тем лучше, желательно чтобы любой отклик на действие укладывался в 100мс.
Несмотря на ультрамощное железо некоторые современные приложения на electron или какая-нибудь IDE, могут легко дать задержку с полсекунды на всплывание какого-нибудь автокомплита!
А могут и не дать.
А может IDE работать быстро, а Vim с задержкой в пол секунды.
У меня вот опыт обратный вышему, давайте не генерализировать частные случаи.
Моя IDE от JetBrains без проблем настраивается в отличие от Vim, и работает без видимых задержек, я не вижу ни единой причины переходить на текстовый редактор который либо имеет нулевой функционал, либо лишь часть от того что умеет IDE, но не факт что меньше лагая при этом(с плагинами).
p.s. Про переоценку частных случаев больше даже относится к комментарию maydjin выше, исходя из комментария которого выходит что все кто не работает над кодовой базой сравнимой по объёмом с базой хромиума «не очень квалифицированные кадры».
У меня стоит пол сотни плагинов, Vim запускается почти мгновенно (пол сотни, которые расширяют функционал, более сотни, включая поддержку многих языков и форматов файлов и цветовые схемы).
Остальное я даже комментировать не буду, глупости одни.
p.s. Про переоценку частных случаев больше даже относится к комментарию maydjin выше, исходя из комментария которого выходит что все кто не работает над кодовой базой сравнимой по объёмом с базой хромиума «не очень квалифицированные кадры».
Во-первых никого не хотел задеть вышеуказанной фразой. И уж тем более не считаю, что разработка небольших и шустрых проектов требует меньше квалификации, чем разработка больших (в случае хромого, я бы даже сказал монструозных) кодовых баз.
Во-вторых — ничто не истина в последней инстанции, более того — органы у всех находятся в разном состоянии, я вот например много играл в очень динамичные игрушки с минимальным пингом 5ms и видимо это заставило меня уметь различать разницу между 5ms и 10ms rtt на глаз при наличии тактильного отклика, я считаю, что это скорее плохо чем хорошо для моего душевного состояния если честно. К примеру — иногда ловлю лаг своей bluetooth клавиатуры, когда она подключенна не по проводу(к слову, в 2.4Ггц решениях такого не замечал, точнее замечал только на мышках и только в играх).
В третьих — vim можно настроить до состояния "лагает", и даже не очень сложно. А можно и не настраивать. Вот с настройкой ide обычно выходит сложнее, есть вещи которые решили за вас и их объективно больше, и это приятно с одной стороны, люблю когда кто-то что-то делает вместо меня. Но при этом — нет свободы отключить или заменить что-то, а коробка может не радовать. Тот же CLion кажется тормозом даже после QtCreator, примерно таким же, как Eclipse на фоне всех их. Я потрудился в 5-7 ide, во многих по несколько лет, поэтому, хочется верить, что мои замечания могут быть хоть от части объективными. К слову — тот же QtCreator единственный не вызывал у меня отторжений по времени отклика, пока я не начал перезжать на удалённый конфиг. Разница в том, что qtc начинает выдавать видимые для меня фризы на пинге 40 до целевого хоста, а vte-based терминал + ssh + vim на 80(а это уже даже для lte много).
Мощный ноут абсолютно не противоречит тормозам IDE при попытке автокомплита или когда увешался 100500 плагинов
Т.е., согласен, что мощное железо — необходимое условие эффективной работы, тем более, когда это инструмент. Но, к сожалению, не достаточное.
Потому, что не изобрели ещё мощных ноутов которые держат батарейку хотя бы 8 часов и весят так, что бы не нужно было бы быть атлетом для их регулярного перемещения и комфортной работы. При этом получаемая производительность на выходе всё равно остаётся намного ниже. Это к вопросу о мобильности, нужна она не всем и не всегда. Но тем не менее, почему-то куча народу таскает с собой эти коробочки с микросхемами.
Второй момент сборный, это шум, пыль, занимаемое свободное место. Если вас шум вентилятора не отвлекает — окей. Я вот когда слышу этот чудный звук — ищу виновника и причиняю ему -9 и прочие радости доставляю. Можно взять рабочую станцию с водянкой например — это вполне себе вариант, но он ощутимо дороже, не мобильный и занимает непозволительно много свободного места, при условии, что этого можно было бы и избежать. Мы же не в 90ых живём в конце концов, я вот планирую в этом году переехать на разработку со своего телефона полностью, ноут большой и тяжёлый же.
Третий момент самый тонкий, спорный и низкоприоритетный — время отклика. Казалось бы сети должны его повысить, но, как показывает практика, многие GUI решения локально оказываются в этом плане тупее, чем терминал по ssh с пингом 60 например до свободного железа. Ноги у этого феномена растут понятно откуда — в условиях вытесняющей многозадачности, на клиентском терминале за ресурсы дерутся куда больше приложений и служб, чем на выделенном удалённом и когда в игру вступает такая сложная система как IDE — мы видим нестыковки в процессах планирования и артефакты борьбы за ресурсы. Когда я вижу фриз в каком нить VisualStudio PRO за многоденег, на свежей рабочей станции от какого нить HP тоже за многоденег, меня это расстраивает. Не сильно, но достаточно, что бы я написал об этом параграф приведённого размера. И достаточно, что бы моё душевное спокойствие вернулось в норму при открытии того же кода в другом решении.
Самая большая проблема это плагины уже для самого vim/neovim, при попытке полного перехода, мало того что они кривые и труднонастраиваемые, но зачастую возникает необходимость их самостоятельного дописывания и на полное удовлетворение своих потребностей могут уходить недели.
Это основное заблуждение тех кто трогает vim по минимуму :) Там только возможности редактирования представлены на эти 80-90% и то, обычно в лучшем случае. Т.е. ощущение "я это по-любому сделаю/прикручу" — пропадает, а те 10% в которые втыкаешься из нереализованных или плохореализованных фич слегка сбивают.
:'<,'>!sed 's/[, ] \([^, ]\)/\1/' | sort -f | sed -e '1s/\w/ &/' -e '2,$s/\w/, &/'
Готово! Писать второй раз её уже не нужно, просто набираем первые несколько символов...
У вас подобные "наборы символов" с первого раза правильно набираются, ничего не забывается, всё учитывается, всё сразу работает как ожидается? Потому как эксперименты с баш-однострочниками, которые будут портить вам текст, тоже будут попадать в историю команд и замусоривать её. Более того, когда вся история команд состоит из подобных заклинаний, то придется потом вспоминать, что каждая из них делает. А когда вы находитесь в контексте работы над задачей, переключение мозга на парсинг и составление этих команд и потом обратно потребует время и энергию, даже если вы до этого всю жизнь программировали на баше и знаете наизусть все маны по coreutils.
Иногда бывает и не с первого раза, особенно если задача условно новая, но с опытом приходит хорошее понимание того, что ты пишешь (ну или просто набирается достаточное количество рабочих паттернов) и получается с первого раза как надо.
Засорение истории для меня никогда не было такой проблемой, т.к. самая правильная команда — последняя и найдётся первой. Я же не ищу сразу по всей истории просто перебирая, я набираю пару первых символов, и это уже сильно сокращает выборку по поиску, и в подавляющем большинстве случаев по этим пару символам плюс стрелка вверх сразу даёт нужный вариант. А если прямо реально что-то нужно где-то отыскать, жмётся Ctrl+f и / и дальше дело за малым (в моём конфиге вообще есть хоткей <leader>; который открывает FZF по истории команд, что делает это непозволительно лёгким), но я пользуюсь им крайне редко, т.к. обычно способ описанный выше сразу приводит к желаемому результату.
А касательно переключения контекстов, то лично я не испытываю на этом какого-либо существенного ментального проседания. Наверное всё-таки тут опыт играет роль, и когда это делать легко, то ощутимого смещения внимания не происходит.
Проблем со вспоминанием того, что команды делают я тоже не помню чтобы испытывал. Я могу их прочитать и понять что они делают. Но вообще как правило по визуальному образу я вспоминаю сразу зачем эта команда писалась. В конце-концов для меня нет проблемы взять и написать заново, если я не могу отыскать в истории, я мой поинт также в том, что хорошо бы практиковаться время от времени, чтобы мочь в любой момент написать такой кусок заново на ходу и не дорожить историей команд как сокровищем.
Вообще-то нормальные IDE давно уже все программируются. Так что у вас тоже все ваше рабочее окружение в наличии, и вполне может использоваться. Поэтому такое сравнение просто некорректно. При этом все попытки реализовать для vim скажем нормальный автокомплит для более-менее нетривиального языка приводят к такой ерунде, что в сравнении с той же IDEA ей просто пользоваться невозможно.
Лёгкость использования какой-либо сторонней программы или баш скрипта, по отношению к куску кода в IDE ощутимо сложнее (я если честно не видел чего-то, кроме make-скриптов, что очень далеко от того, что можно делать в Vim), чем нажатие одной клавиши (!) в Vim, чтобы этим кто-то часто и по любому поводу стал пользоваться. Будет гораздо лучше если покажите пример как в какой-нибудь IDE можно выполнить вот этот скрипт по отношению к выделенным строкам в коде:
sed 's/[, ] \([^, ]\)/\1/' | sort -f | sed -e '1s/\w/ &/' -e '2,$s/\w/, &/'Расписав последовательность действий/нажатий клавиш, или, прости Дарвин, прицеливаний и кликов мышью.
В vim8 есть из коробки для gdb, разумеется в стилистике редактора.
Но отладчики тоже переоцененны на мой взгляд :) Хотя это наверное тема для отдельной дискуссии. В кратце моя точка зрения тут такая — простые вещи ловятся тестами, в худшем случае логами, при этом отладочная сессия не попадает в /dev/null, а остаётся в виде артефакта в кодовой базе. А для сложных вещей всё равно приходится открывать терминал этого самого отладчика, а то и скрипт писать, так какая разница делать это в IDE, или в другом терминале?
отладчики тоже переоцененны на мой взгляд
простые вещи ловятся тестами, в худшем случае логами
для сложных вещей всё равно приходится открывать терминал этого самого отладчика
Абсолютно согласен. Особенно учитывая, что мы живем в XXI веке, и ошибки обычно возникают в сложной конкурентной среде, где отладчик и так мало, чем поможет. Однопоточный код у меня лично получается писать правильно с первого раза.
Ну, скажем, писать игру в команде без отладчика довольно больно, когда у вас есть несколько сабкоманд, отвечающих за разный функционал — одна пишет гуи, другая геймплей механики, третья — кор функционал фреймворка. Пересечения неизбежны и логика чужих кусков не всегда ясна, а баги чинить надо.
Наверное, даже наверняка, вы правы. Я просто очень далек от игровой индустрии.
Могу перефразировать вас немного, тогда поинт выше возможно станет более понятным:
Довольно больно разрабатывать средний или крупный проект без разбиения на подпроекты и тестов интерфейсов этих подпроектов. Так же — в нём сложно искать ошибки реализаций без хорошей подсистемы логгирования и/или трассировки.
Когда требования выше соблюдаются — отладчиком приходится пользоваться крайне редко, и обычно это какой то изощрённый кейс (типа написать скрипт, который проанализирует в какой точке испортили память которая создавалась в другой точке, но ещё не удалялась в третьей, руками такие сессии могут занимать часы и требовать недюжей внимательности), эти варианты обычно либо не доступны через UI IDE, либо сводятся к обращению к командному интерфейсу отладчика, который и в терминале имеется. В основном как ни странно баги находятся даже не в разрабатываемых продуктах зачастую :)
По части интеграций, есть частные решения, не универсальные, для отдельных языков, есть разные реализации LSP (см. ALE, LanguageClient-neovim), в roadmap Neovim-а включена встроенная реализация LSP. Есть всякие GUI для Neovim, которые сразу поставляются с интеграцией под javascript, напр. veonim.
Эх, не хотят юниксоиды LSP поддерживать. А все потому, что придумал его MS. А ведь единственно верное решение, по сути, для сторонних текстовых редакторов.
Про LSP см. соседний комментарий.
Имхо слишком сложный способ решения задачи с сортировкой (если только целью не является впечатлить собеседника крутизной однострочника), оптимальный только по кол-ву нажатий. Я бы не стал делать такие длинные цепочки из пайпов. Одна неочевидная ошибка — и сиди дебажь цепочку команд.
Правильнее делать поэтапно, хотя это и требует больше действий:
vap (или чем вы там выделяете диапазоны) ---> копипаста в отдельное место --->встать на первую строчку с запятой ---> dw ---> долбим j.j.j.j.j.j.<…> ---> выделяем ---> !sort
Не масштабируемо, но требует сильно меньше ментальных усилий.
Для меня нет ничего сложного. И если достаточно практиковаться делать такие вещи, то это делается на легке, к тому же навык пригодится и за пределами Vim-а. Никакой крутизны (однострочник к тому же предельно простой, тот который на баше, тут и выделываться нечем), решение рутинных задач, автоматизированно, не полагаясь на собственную несовершенную внимательность.
vap (или чем вы там выделяете диапазоны) ---> копипаста в отдельное место --->встать на первую строчку с запятой ---> dw ---> долбим j.j.j.j.j.j.<…> ---> выделяем ---> !sort
"Копипаста в отдельное место"? "долбим j.j.j.j.j.j."? Да я себя макакой-резусом почувтсвую сразу, которую за виноград научили дёргать за рычаг. И вы предлагаете делать это каждый раз, как я добавлю новый пакет в список зависимостей? Я учился пользоваться Vim-ом не для того, чтоб как рядовой пользователь какой-нибудь IDE, монотонно клацать по стрелочкам и руками повторять одинаковые секвенсы N times in a row, или мышкой прицеливаться "стрелять" по кнопкам. Я хотел быть эффективным, а это входит в прямое противоречие с "долбим j.j.j.j.j.j." Это пример "как не надо пользоваться Vim-ом".
В конце-концов можно макрос записать и сделать N@x (где N кол-во строк se rnu в помощь). Можно нажать Ctrl-V+l для блочного выделения в 2 столбца с запятыми, потом Njx чтобы выделить все запятые и удалить их. Далее gv:sort! i<cr> и gvojI,. Как-то так. Но "долбим j.j.j.j.j.j." — это просто комично, простите. Да и вы в своём примере забыли запятые вернуть на место. Наверное должно выглядеть как i, <esc> и "долбим" hj.hj.hj.hj.hj.
Копипаста в отдельное место
Да. Копипаста в отдельное место. Одно неверное движение в вашем однострочнике или опечатка — и вы, матерясь, будете воспроизводить всю последовательность действий с начала, начиная с выделения (я в курсе про историю ex команд и ключ /c, это не сильно помогает).
В случае отдельного буфера и операций "по одному" (без пайпов) набор строк изолирован и не лезет в историю undo. Кроме того такой процесс легче контролировать, откатывать, править на ходу.
долбим j.j.j.j.j.j.
Для набора в десяток строк — да, именно так. Сравните это долбление со сложностью набора вашего /s/-выражения (как по количеству символов, так и по частоте покидания home row, а также по ментальному усилию). Плюс в моём способе будет визуальное подтверждение прогресса (ок, решается ключом /c в вашем способе).
делать N@x (где N кол-во строк se rnu в помощь).
И как же вы быстро узнаете N в середине файла с 3-4 значными номерами строк (как мы помним, вы против перебрасывания набора строк в отдельный буфер)?
Можно нажать Ctrl-V+l для блочного выделения в 2 столбца с запятыми
В идеальном мире, где запятые образуют ровный visual block
Да и вы в своём примере забыли запятые вернуть на место. Наверное должно выглядеть как i, <esc> и "долбим" hj.hj.hj.hj.hj.
Нет, я до такого идиотизма не дохожу, но и ваш способ не лучший (по соотношению сложность/стабильность). Я бы склеил все строки в одну через J (да, опять долбёжкой, мне нужно визуальное подтверждение и я не знаю численного префикса) и затем выполнил бы s/, /, \n/g.
И ещё дисклеймер: я весьма давно пользуюсь vim (в тч text objects, шеллом и прочим инструментарием из статьи) и никого не призываю двигаться по тексту одними jjjjj или ещё как. Но я против и другой крайности, когда в жертву уменьшению кол-ва нажатий клавиш приносится вообще всё, в частности простота процесса и устойчивость к ошибкам.
Да. Копипаста в отдельное место. Одно неверное движение в вашем однострочнике или опечатка — и вы, матерясь, будете воспроизводить всю последовательность действий с начала, начиная с выделения (я в курсе про историю ex команд и ключ /c, это не сильно помогает).
Я искренне округляю глаза, когда читаю это. Ну ладно, отвечу в виде шутки.
… и вы, матерясь, будете воспроизводить всю последовательность действий с начала, начиная с выделения...
Допустим опечатался я в однострочке, и о ужас, я вдыхаю полную грудь воздуха и нажимаю ugv, вернул всё как было и даже выделение вернул, ну всё, я весь взмок, суставы ломятся от перенапряжения, в глазах темнеет, пойду прилягу, и на всякий случай вызову доктора, а пока доктор мчит, смерю давление, материться и сил никаких не осталось, 3 кнопки нажать последовательно — это не какой-то там уголь из шахты тащить. Но вот я отлежался, силы вернулись ко мне, перетягиваю на себе пояс, чтобы вернуться к команде из истории, фух, жму ":↑", уже сползая со стола от изнеможения успеваю нажать Ctrl+f, всё; несите ручку и салфетку, пока не поздно написать завещание!
Для набора в десяток строк — да, именно так. Сравните это долбление со сложностью набора вашего /s/-выражения (как по количеству символов, так и по частоте покидания home row, а также по ментальному усилию). Плюс в моём способе будет визуальное подтверждение прогресса (ок, решается ключом /c в вашем способе).
Усилий едва ли больше, зато когда мне это понадобится во второй и третий раз, — мне не придётся весь этот монотонный нонсенс с рычагом и виноградом повторять снова и снова.
И я не понимаю какое-такое визуальное подтверждение будет в вашем способе, которого не будет в моём? Чем ваш !sort (хотя вы наверное имели в виду просто sort, или точнее sort i, т.к. нужна регистро-независимость, встроенный в Vim, иначе чем это вообще отличается от моего варианта в плане наглядности?) более наглядно, чем мой вариант с командой (вызов внешней команды не может не заменить выделение, как бы между-прочим)?
А про home row открою сокровенную тайну за семью печатями, Vim можно конфигурировать, вот пара строчек из моего конфига:
" moving between history in command mode
cno <C-p> <Up>
cno <C-n> <Down>Этого уже достаточно чтобы не покидать home row. Но у лично у меня ситуация ещё интереснее, т.к. я несколько лет уже использую собственную софтверную прослойку для клавиатуры, которая позволяет мне нажимать стрелки и всякого рода home/end/pgup/pgdown/delete/etc. не покидая home row.
Предлагаю ознакомиться с лэйаутом ниже:
Но даже более того, с некоторого времени я обзавёлся эргономичной клавиатурой, на которой кроме как home row ничего другого и нет (хотя ещё раньше я пользовался 60% клавиатурами, к которым это также применимо). Предлагаю также ознакомиться с кастомным лэйаутом на уровне прошивки клавиатуры. В общем поинт с покиданием home row тут по целому ряду причин — попадание мимо, стреляя из пушки в упор.
А ссылаюсь на "стрелку вверх" я исключительно для понятности остальным, как в стандартном конфиге, мой конфиг же, очень далёк от стандартного.
И как же вы быстро узнаете N в середине файла с 3-4 значными номерами строк (как мы помним, вы против перебрасывания набора строк в отдельный буфер)?
Я же даже подсказку в скобках оставил, которую вы же и процитировали! Включите se rnu и посмотрите на экран, или :h rnu наберите и почитайте про стандартную и древнюю как мир фичу Vim-а. На всякий случай отмечу, то N — это N раз, а не N номер строки.
В идеальном мире, где запятые образуют ровный visual block
Я привёл конкретный случайный пример из жизни, где это так, и мы обсуждаем проблему и её решение именно в этом контексте. Когда то, с чем нужно иметь дело, выглядит иначе — это уже другое решение (невероятно, но это потребует лишнего ментального усилия, и доблить j.j.j.j.j. уже не получится).
Нет, я до такого идиотизма не дохожу, но и ваш способ не лучший (по соотношению сложность/стабильность).
Со стабильностью как-раз всё отлично, автоматизированно, повторяемо, переиспользуемо, корректируемо, полагаемся на хладнокровный код, а не на human factor.
Я бы склеил все строки в одну через J (да, опять долбёжкой, мне нужно визуальное подтверждение и я не знаю численного префикса)
Численного префикса не знаете как раз потому, что не знаете об se rnu.
и затем выполнил бы s/, /, \n/g.
Вот! Наконец прозрение! Я сам хотел привести в пример автозамену, но что-то забыл. А теперь внимание! Вернёмся к тому "сложному и дремучему" что я понаписал, а написал я 2-3 таких реплейса (синтаксис sed идентичен по сути vim-у) + sort -f (он же sort i в VimL), при этом вот это всё доблить j.j.j.j.j. исчезает.
Но я против и другой крайности, когда в жертву уменьшению кол-ва нажатий клавиш приносится вообще всё, в частности простота процесса и устойчивость к ошибкам.
Про простоту процесса я уже говорил, это потом всё легко повторяется из истории, я один раз такое пишу, а потом из истории переиспользую десятки раз. Это как раз-таки и упрощает всё, а не наоборот.
А вот про устойчивость к ошибкам — это совершенно мимо, наоборот, это именно что и устойчиво к ошибкам, в первую очередь к ошибкам ЧФ.
P.S. Для пущего веселья, вот как выглядел оригинальный пример, который я укоротил и дополнил модулями с капсом в имени, чтобы нагляднее продемонстрировать регистро-независимость:
X11
, base
, containers
, data-default
, data-maybe-preserve
, dbus
, deepseq
, directory
, extra
, lens
, linux-evdev
, mtl
, process
, qm-interpolated-string
, safe
, stm
, template-haskell
, text
, time
, transformers
, type-operators
, unixМолю вас, запишите на камеру, как вы обдолбите этот список с помощью j., я буду показывать это в качестве эталонного образца "как не надо пользоваться Vim-ом".
P.P.S. У меня нет цели высмеять лично вас, обидеть кого-то, или что-то в этом духе, надеюсь вы тоже отнесётесь к этому с юмором.
[Удалено] пост не в ту ветку...
VIM — Это не только редактор, это интеграция со всем вашим рабочим окружением