В предыдущем посте про горячие клавиши был сделан вывод о том, что лучше не трогать родные горячие клавиши и сочетания с модификатором CTRL и освоить их как есть, а все пользовательские команды и управление плагинами оставить на сочетания с клавишей лидером. Их туда можно напихать можно сколько угодно. Мнемонически это выгодно тем, что базовые сочетания будут работать везде и вы знаете, что сочетания с лидером могу работать каждый раз немного по-разному, особенно если вы активно используете конфигурации под определенные типы файлов (:filetype on). В каком-то случае LSP (Language Server Protocol) нужен, в каком-то нет, где-то DAP (Debug Adapter Protocol) работает, где-то в нем нет смысла, для большинства типов файлов омни автодополнение включено, для SQL скриптов лучше вызывать его вручную и так далее.

Однако всё это хозяйство работает пока не включен режим вставки. В режиме вставки остается очень ограниченный перечень плюшек, работающих с нажатым CTRL. Большинство пользователей при этом дружно сходятся во мнении, что в данном случае нужно беспрекословно следовать той самой философии "модального" режима, а именно: режим вставки - только для вставки. То есть встали на нужное место, нажали один из вариантов входа в режим вставки, кстати их там вагон и маленькая тележка, набрали нужный кусочек текста, и тут же вернулись в нормальный режим. "Нормальный" он именно поэтому - другие режимы считаются "ненормальными". Так вот, к этой философии привыкнуть после пары десятков лет с WYSWIG с разбегу, прямо скажем, сложновато.

Ну, во-первых, нужно именно сломать в голове парадигму, что режим вставки это то в каком состоянии должен быть редактор большую часть времени. Особенно сложно с этим свыкнуться при наборе вот такого текста из головы, когда вы работаете не какими-то дискретными отрезками, как, например, при рефакторинге программ, а довольно длинными сессиями, когда нужно изложить цельную мысль, не теряя её посередине.

Должны ли быть здесь паузы после каждого предложения или абзаца?

Надо ли выходить в нормальный режим, когда мысль закончена?

Когда считать мысль законченной? Словом, не так тут всё просто. Надо ли при этом выходить в нормальный режим, когда тут же замечаешь опечатку, пропущенную запятую, неправильный регистр? Всё-таки кажется логичнее тут же на месте вернуться на пару слов назад, исправить, и продолжить редактирование без переключения в голове способа передвижения. Может это сложно только в начале, и я просто сам еще не привык это делать на уровне условного рефлекса, но что-то мне подсказывает, что средний человек, всё-таки сталкивается с похожей проблемой. Конечно, если согласиться с тем, что я сам некий средний товарищ. Сколько длится этот переходный период? Месяц? Год? До тех пор пока человек не плюнет на всё это?

Поэтому и еще по паре причин ниже, предлагаю остановиться, опять же, на некоем промежуточном варианте, тем более, что Vim такую возможность из коробки, как оказывается, предоставляет.

Motions

Мне почему-то не сразу попало в поле зрения сочетание <C-o>, которое как-раз реализует эту промежуточную парадигму, когда режим вставки более "нормален", чем нормальный режим. Сочетание в режиме вставки позволяет кастануть ровно одно заклинание из нормального режима и продолжить. Например, вы забыли запятую три слова назад: что бы вернуться и вставить запятую каноничным способом вам надо выйти из режима вставки, вернуться на три слова назад "нормальным" способом, войти в режим вставки в конец строки - <Esc>3bhi,<Esc><A> (или, скажем, \'3F<Space>i,\'A, как бы сделал я). Либо, считая режим вставки "приоритетным" в данный момент, можно поступить более интуитивно: <C-o>3F<Space>,<C-o>$. На первый взгляд, движений потребовалось почти одинаковое количество, однако, мне по крайней мере, кажется, что последний способ чуть более быстрый, при этом чуть менее мысленно сложный - вы в каждый момент времени всё-таки в одном режиме работы. Либо же, для такого случая, я все-же пока чаще пользуюсь стрелками.

Вот честно не знаю насколько использование стрелок в режиме редактирования православно с точки зрения замысла Vim. Вроде как исконно Vim задумывался именно для клавиатур без стрелок передвижения курсора. Есть масса высказываний на тему, что для начинающего пользователя вообще лучше выключить стрелки (да и прочие кнопки справа от Enter) на уровне системы. Так сказать, что бы максимально погрузиться в новую (старую) философию. Но, лично мне, вся эта история с ноутбучными и минималистскими клавиатурами не очень близка. (Далека скорее. Может когда-нибудь...). И раз эти кнопки есть, то я не вижу разумных причин ими не пользоваться.

В режиме вставки прекрасно со своей функцией справляются сочетания CTRL со стрелками, да и просто сами стрелки. Тем более что я часто не попадаю по количеству слов в заданный пробел, а еще чаще нужно остановиться по-середине слова что бы исправить опечатку, причем последнего слова. Куда же тут без стрелок? Выходить в нормальны режим делать hhhhh, cl... <Esc>A довольно утомительно, не считаете? Отпишитесь пожалуйста если знаете способ лучше, действительно очень интересно. То же самое можно сказать про HOME, END. Надо понимать, что речь тут именно про редактирование обыкновенных текстов: статеек, документации, может быть даже длинных запросов и блоков кода, которые можно записать разом. Разумеется, когда при написании программ нужно активно лазить не столько по строке сколько вверх-вниз по коду, то тут удобнее выходить в нормальный режим. И то, знаете, не всегда.

Пример классический: надо что-то вертикальное (список полей) расположить в строку, или наоборот сперва разложить список на строки, и, не знаю, добавить по запятой спереди или сзади. И важно, что элементов в списке не двадцать девять, а, скажем, три. Не прибегать же каждый раз к регуляркам или к макросам? Есть еще, конечно, блочный режим (<C-v>...I...), о котором мне сразу напомнят более продвинутые товарищи, но, я к нему никак пока не могу привыкнуть, потому что, наверное, нужен он не так часто. Но вот с точки зрения, опять же, того что бы не терять мысль во время набора кода, не отвлекаясь на дополнительные сущности, мне иногда проще вот так быстренько пробежаться курсором и вставить эти злосчастные запятые. Если я вижу, что на такой топорный способ уйдет значительно больше времени, чем сказать себе: "подождите, тут же можно применить макрос" или "все строки повторяются с одного и того же символа", или "все числа выровнены в один вертикальный блок", то да, можно даже слазить в интернет, и посмотреть как же там было делать инкремент.

Тем более, что стрелки работают так как надо без каких бы то ни было предварительных ласк. Кроме случаев, когда они конфликтуют с эмулятором терминала или системы. Например, с tmux пришлось немного повозиться: дать ему в .tmux.conf

set-window-option -g xterm-keys on

А так же добавить немного черной магии в .vimrc:

" tmux compatibility
if !has('gui_running') && &term =~ '^\%(screen\|tmux\)'
	let &t_8f = "\<Esc>[38;2;%lu;%lu;%lum"
	let &t_8b = "\<Esc>[48;2;%lu;%lu;%lum"
endif

if &term =~ '^screen'
    " tmux will send xterm-style keys when its xterm-keys option is on
    execute "set <xUp>=\e[1;*A"
    execute "set <xDown>=\e[1;*B"
    execute "set <xRight>=\e[1;*C"
    execute "set <xLeft>=\e[1;*D"
endif

Что конкретно это означает, к сожалению, я вам сказать не могу, но это работает.

В общем, тут я готов принять критику, что это не очень каноничный подход, и посыпать голову пеплом, но вот в ситуации, когда использование стрелок не вызывает у вас аллергический приступ, то и не надо искать сложных путей и как будто бы всё хорошо. Однако, есть ситуация из которой хорошего выхода нет совсем. Или я его еще не нашел. (А может и не надо его искать?)

Soft wrap

Короче, это случай с вводом строк длиннее чем количество символов по горизонтали. Опять же, этот случай имеет свою определенную нишу, а именно, набор текста на естественном языке, как, например, этот. По умолчанию, как-будто, считается, что Vim не совсем предназначен для такого сценария использования. Да, есть у нас в распоряжении :set wrap linebreak, но он работает в режиме вставки, мягко сказать, не совсем так как от него ожидаешь. То есть длинная строка это всё-таки всё еще одна длинная строка, но просто отображается как несколько. И это как-будто бы даже логично, но, увы, перемещение по такой строке вызывает другие логические вопросы. Хочется всё-же вверх вниз двигаться по ней так, как она состояла бы из нескольких отдельных строк.

Есть радикальное решение. Использовать жесткие переносы: :set texwidth=80. Однако, понятно, что с этим появляются другие проблемы. Такой текст нельзя скопировать уже в какой-то другой редактор без переводов строки. Не понятно при этом 80 ли? Может где-то этого мало, может наоборот. Что вы будете делать, когда окну в данный момент доступно меньше столбцов? Если наоборот вам почти всегда доступно 120 и более? Если вы не пишите ничего кроме коротеньких программ на условном питоне, то в принципе это может быть решением. Почти во всех других случаях, когда ваш язык программирования более многословен, когда это SQL запросы, когда нужна развернутая документация, то такой выход скорее полумера.

Допускаю, что можно сделать так, что при выделении или копировании или по какому-то специальному сигналу, типа gq, можно как-то повлиять на ситуацию, но выглядит это, как по мне, так скорее как костыль. Так что мой выбор - перенос мягкий.

С мягким переносом обозначенные проблемы исчезают, но появляются свои. Параграф естественного текста это фактически одна строка. А параграфы бывают длинные (теоретически бесконечные). Перемещаться по нему вверх вниз в режиме вставки у меня не получается никак. Уж сколько я искал, всё сводится к одному: выйти в нормальный режим, а там уже вариантов множество. Один из них - сделать парочку переназначений.

" move between soft wrapped lines
nnoremap <expr> j v:count ? 'j' : 'gj'
nnoremap <expr> k v:count ? 'k' : 'gk'
nnoremap <expr> <Down> v:count ? 'j' : 'gj'
nnoremap <expr> <Up> v:count ? 'k' : 'gk'

Выглядит хитрее стандартного назначения, но тут на самом деле использованы лямбды. В данном случае <expr> делает доступной в правой части выражения переменную v, к которой можно применить методы, и, как здесь, обычный тернарный оператор. В Lua такое заклинание выглядит чуть более понятно:

-- soft wrap remap
local expr_opts = { noremap = true, expr = true, silent = true }
vim.keymap.set({ "n", "v" }, "j", "v:count == 0 ? 'gj' : 'j'", expr_opts)
vim.keymap.set({ "n", "v" }, "k", "v:count == 0 ? 'gk' : 'k'", expr_opts)
vim.keymap.set({ "n", "v" }, "<Down>", "v:count == 0 ? 'gj' : 'j'", expr_opts)
vim.keymap.set({ "n", "v" }, "<Up>", "v:count == 0 ? 'gk' : 'k'", expr_opts)

Где за передачу параметра отвечает expr=true. И, да, я наверное, в следующий раз объясню зачем мне делать конфигурацию одновременно на Vim и NeoVim. И файлы выложить тогда же - в этот раз опять не получается собраться.

Это я отвлекся. Так вот этого, к сожалению, не достаточно. Потому что оно, как и было обозначено ранее, не работает в режиме вставки. То есть либо надо всё-время переключаться, либо считать вбок слова или знаки, с чем лично у меня, есть проблемы. В пределах 5 слов, наверное, можно как-то быстро ориентироваться. В пределах параграфа в дюжину строчек, думаю, ни у какого нормального человека не хватит вычислительной мощности мозга что бы хотя бы примерно перескочить назад на несколько строчек.

Есть, говорят, плагины, которые, снова, частично, но хоть как-то облегчают жизнь. Например, как вот этот easymotion/vim-easymotion. Он у меня установлен, но, честно сказать, пока я им не пользуюсь совсем, хотя и чувствую - зря. Опять же, он работает в нормальном режиме, но используя тактику с тем же сочетанием <C-o> в режиме вставки, думаю можно добиться определенной степени ловкости, что бы не замечать боль связанную с невозможностью перемещения стрелками по перенесенному параграфу вверх вниз.

Registers

Примерно такую же функцию как <C-o> в режиме вставки выполняет <C-r> только с регистрами, позволяя буквально впечатывать текст из регистра (так мы теперь называем буфер обмена). Тут важно понимать, что это именно впечатывание, что чуть отличается от вставки. Потому что если в регистре содержатся управляющие последовательности, то они выполнятся так, как будто по вы вводите содержимое с клавиатуры. Что иногда мешает, а иногда наоборот приходится кстати. Именно поэтому в предыдущей статье было предложено поставить переключатель режима вставки.

nnoremap <F2> :set invpaste paste?<CR>
set pastetoggle=<F2>

Который временно переключает поведение вставки так как она работала бы в нормальном режиме. То есть, в большинстве случаев, особенно когда дело касается исходного кода программ, изобилующим разного рода символами и отступами, вам либо надо покинуть режим вставки, либо вот так переключить режим в дополнительный. (Который при этом за одно почему-то отключает <C-^>, который в свою очередь переключает раскладку. Поэтому включенным постоянно его держать не выйдет).

Еще один бонус использования регистров так как это задумано в Vim это то, что сочетание <C-r> работает и в других режимах кроме нормального - в командном, в терминальном. Нет сомнений и в том существует профит связанный с тем, что их, этих регистров, мало того что несколько встроенных, можно самостоятельно привязать их к буквам. Правда, я пока не достиг того уровня дзена, когда я помню что у меня лежит кроме как в системном (+) и в родном (") регистрах. Существуют способы и плагины сделать работу с регистрами более интуитивной и наглядной, но мне пока хватает стандартной :reg.

Кстати, может у вас есть способ наоборот использовать регистры Vim за его пределами? Сторонний софт, который бы давал возможность вставлять регистры во внешние программы?

Это, пожалуй, всё что я хотел сегодня сказать конкретно про режим вставки. Есть еще пару нюансов связанных с режимом вставки. В частности, работа с автодополнением (или как правильно по-русски это называется, подскажите) и с проверкой правописания, но этих моментов правильнее будет коснуться в связанных выпусках рубрики. А в следующий раз, я хочу продвинуться от эдакой предварительной подготовки почвы, сказать еще пару заключительных вещей на общие темы и перейти уже к какой-то программистской специфике и уже к более конкретным плагинам и ноу-хау.

ZZ

Комментарии (14)


  1. ku4in
    25.12.2022 13:19
    +1

    У меня функциональная клавиша клавиатуры + hjkl замаплены на стрелки. Сама функциональная клавиша - это левый контрол. А левый контрол перенесен на левый пробел (клавиатура сплит, поэтому два пробела). Поэтому удобно и в Vim в режиме вставки, когда надо на пару символов назад вернуться, и в других приложениях стрелками на hjkl можно пользоваться.


  1. ReadOnlySadUser
    25.12.2022 17:32
    +4

    Выходить в нормальны режим делать hhhhh, cl... <Esc>A довольно утомительно, не считаете? Отпишитесь пожалуйста если знаете способ лучше, действительно очень интересно

    Пускай заминусят, но я знаю офигенный способ решения чуть ли не 100% проблем с vim. Установите VSCode и не парьте мозг. Я много лет проработал с vim, даже научился-таки его варить нормально, но в итоге пришёл к выводу:

    раз эти GUI есть, то я не вижу разумных причин ими не пользоваться

    Я понимаю, что существует 10 тыщ плагинов, делающих из всего vim и все эти плагины, на мой взгляд, полная лажа) Я не нашел для ничего, чего не может VSCode или что в нём сделано хуже чем в vim.


    1. Rembo123 Автор
      25.12.2022 17:47
      +1

      Вы знаете, я больше скажу, vim получил новое дыхание как-раз благодаря VSCode и LSP сделанным под него. Другое дело, что вместе с этим меняется и общий архитектурный ландшафт разработки. Давайте я попробую чуть более аргументированно обосновать свой выбор. Важно - свой. То есть мне, с моей спецификой работы, когда надо иметь дело с разными средами, виртуальными машинами и с очень разными проектами одновременно, к сожалению ни VSCode, ни Fleet, ни тем более онлайновые среды просто не подошли. Уверен, вам для ваших задач достаточно иметь на рабочем месте единый хорошо настроенный VSCode или любой другой продукт, а вот некоторым, довольно многочисленным специалистам проще не привязываться к какой-то одной конфигурации и иметь возможность относительно безболезненно продолжать работать может быть не так эффективно, но в разных условиях. Пока я работал в одной узкой специализации постоянно, мне не нужны были вообще никакие универсальные инструменты.


      1. ReadOnlySadUser
        25.12.2022 18:51

        VSCode вполне себе портабельный и умеет в SSH. В 99% случаев, этого хватает для того, чтобы работать. При условии постоянной смены окружения, Vim просто ужасен, потому как без напильника и тонкой настройки - это удобный инструмент пару-тройку конфигов подправить, но не более.

        В принципе, я использую vim для правки мелких вещей каждый день и ничего плохого сказать про него не могу в этом плане. Однако как основной инструмент для работы он требует куда больше настройки и костылей, чем VSCode.

        Да, бывают совсем ограниченные среды, без доступа к внешнему интернету, через 5 проксей и RDP, но это прям очень специфические условия. Согласен, тут можно и поюзать vim.

        Просто я не понимаю, почему люди продолжают есть этот кактус добровольно) Когда выбор был между vim или тяжеловесной IDE, я могу понять почему выбор падал в сторону vim, но теперь есть промежуточные варианты в виде VSCode или того же Sublime Text. Они имеют портабельные версии, они относительно лёгкие (для современного железа), в них куча плагинов, которые не надо настраивать по 4 дня (как это бывает с vim). Зачем тогда продолжать им пользоваться как основным инструментом?)


        1. Angeld
          25.12.2022 20:50
          +1

          у VSCode нет нормального модального редактора, vim mode не в счет( в нем есть далеко не все)
          в плане настройки, всякие сборки типа
          https://astronvim.github.io/
          https://www.lunarvim.org/
          https://spacevim.org/
          не сложнее vscode, так же поставил и работает
          плагины которые сложно настраивать( это в основном поддержка языков и разные gui ) там уже встроены и настроены
          а с мелкими плагинами в vim проблем с настройкой не имеют, поставил и они работают
          привлекательность вим не в куче плагинов ( в этом плане разницы с другими инструментами нет), а в базовой функциональности, в удобстве модального редактирования( для тех кто выбрал вим это именно так)


        1. igorjan94
          26.12.2022 03:20
          +1

          Почему у всех vim ассоциируется исключительно с чёрно-зеленым чудовищем из которого нельзя выйти, с размером таба 8 и правкой конфигов?
          Vim это про редактирование кода как текста, неважно в каком редакторе/IDE — это может быть как и голый вим, так и любая IDE с эмуляцией vim: начиная со всех продуктов семейства Jetbrains до, простите, QtCreator'а (я понимаю, что поддержка в этих плагинах далеко не на высшем уровне, но, например, за последние лет 5 в той же IDEA изменилось с "да блин, это не так работает" каждый час на "что-то вроде не так оно должно себя вести, хотя может и норм" раз в месяц или даже реже)
          В таком случае вы получаете И мощь vim'а при редактировании кода как текста, И мощь IDE при редактировании кода. Об этом и пишется большинство статей (как я надеюсь, по крайней мере я так вижу...)


          Например, вы написали какой-то if с простым условием, оно разрослось до сложного со всякими скобками. Теперь вы хотите вынести выражение в скобках в константу.
          IDE: поставить каким-то образом курсор на открывающую скобку, мышкой или через стрелочки с зажатым шифтом выбрать всё с закрывающей скобкой, С-А-С, <имя переменной>
          VIM: поставить каким-то образом курсор внутри скобок, ca)<имя переменной><ESC>Oconst <имя переменной> = <ESC>p, удалить скобки
          IDE+VIM: поставить каким-то образом курсор внутри скобок, va)<C-A-C><имя переменной>


          Для меня очевидно, что комбинированный вариант самый удобный: я просто не представляю, как можно обходиться без vimовских motion-change/delete комбинаций (dap, di), c2w, v%, ...) не говоря уж о всемогущей точке, так и без обычных IDEшных фич. Даже сейчас, когда пишу этот коммент в браузере мне этого не хватает: всякие плагины типа vimium помогают, но это только для навигации, а не для написания какого-то текста, в такие моменты проще создать временный файл и редактировать его как раз голым вимом (да даже плагинов никаких не надо, разумеется), нежели чем страдать с обычным редактором


          Просто я не понимаю, почему люди продолжают есть этот кактус добровольно

          Кому-то может быть не нужны все возможности IDE. Я вот понаблюдал за собой, что я использую из всего WebStorm'а и понял, что это в большинстве своём автоимпорт, refactor->rename, refactor->extract и подобное, git view. Не так уж и много фич, которые при желании можно и в голом виме плагинами сделать, но смысл? А вот для спортивного программирования на с++ мне вообще ничего из IDE не нужно, поэтому смысл использовать IDE?


          которые не надо настраивать по 4 дня

          Мне даже интересно, что это за плагин. У меня более 20 плагинов (из которых обязательных — 0, а из желательных только автокомлит), но я не помню, чтобы установка занимала больше минуты, а настройка различалась по времени с чтением README устанавливаемого плагина
          Да в той же IDEA для того чтобы при желании пролистать все настройки уйдёт наверно 4 дня, но смысла в этом никакого нет — пользуешь по дефолту, понимаешь что что-то не нравится, идёшь в конфиг и чинишь. Но это я бы сказал это вообще про любой софт верно


          1. vtb_k
            26.12.2022 13:04

            Даже сейчас, когда пишу этот коммент в браузере мне этого не хватает: всякие плагины типа vimium помогают, но это только для навигации, а не для написания какого-то текста, в такие моменты проще создать временный файл и редактировать его как раз голым вимом (да даже плагинов никаких не надо, разумеется), нежели чем страдать с обычным редактором

            Прям сейчас пишу этот комментарий в Емаксе, используя tridactyl плагин для ФФ. Любые текстовые поля можно редактировать, используя системный редактор. Уже давно мышь не использую в браузере. Кстати, этот плагин никогда не будет работать на хромых браузерах.


    1. AAngstrom
      26.12.2022 02:17

      У нас, динозавров, трактористов и заслуженных работников виртуальных терминалов и консолей, есть одно простое правило -- если при работе с текстом в редакторе нужно прикасаться к мышке и, вообще, отрывать руки от клавиатуры, то редактор немедленно отправляется в /dev/null. В этом плане, единственный конкурент vim -- это emacs.

      У меня студент работает во всяких VSCode, PyCharm и прочих продуктах идеостроя. Когда он показывает результаты, тыкая мышкой во все эти табы с кучей свистоперделок, у меня начинает дёргаться глаз, потому что всё это чудовищно тормозит. Почти любое действие -- не менее полусекунды задержки, и это на супермощном ноутбуке с 6-ядерным процом. Это второй пункт, по которому vim обставляет все эти новомодные ГУИ.


      1. ReadOnlySadUser
        26.12.2022 02:28

        Я в VSCode мышкой если и пользуюсь, то ОЧЕНЬ иногда для каких-то жутко странных штук. С ходу могу вспомнить только один сценарий: мне нужно поставить несколько курсоров в случайных местах в тексте и что-то подредактировать такое странное (что, к слову, vim вообще не умеет, ибо multiline edit в vim реализован так плохо, что цензурных слов у меня нет для этого).

        У меня студент работает во всяких VSCode, PyCharm и прочих продуктах
        идеостроя. Когда он показывает результаты, тыкая мышкой во все эти табы с кучей свистоперделок

        Ну, а я когда смотрю, сколько лишних движений требует vim для тупейших действий, насколько это всё неудобно, насколько неинтерактивно, у меня слезы наворачиваются.

        Я сам вимовод со стажем, и когда я смотрю на своих коллег вимоводов (с ещё большим стажем) - мне больно смотреть. Они делают все ТАК ДОЛГО. Я оперирую горячими клавишами и GUI элементами примерно процентов на 30 быстрее.

        Но да, студентики у меня тоже очень ленивые, учить горячие клавиши не хотят и тоже всё тыкают мышкой. Они делают всё НЕВЕРОЯТНО ДОЛГО, иногда хочется им прописать курс vim-а только для того, чтобы появилась привычка делать всё через клавиатуру. Так что проблема не в VSCode. Проблема в студентах)


        1. AAngstrom
          26.12.2022 15:11

          Чисто любопытства ради: какие именно действия в VSCode выполняются быстрее, чем в vim? Не специфические языковые фичи -- всё-таки, vim является редактором текста, а не IDE, -- а действия, связанные с редактированием текста.

          И в обратную сторону. Сколько нажатий клавиш в VSCode потребуется, чтобы выполнить следующие действия?

          1. Проскакать вперёд/назад по, например, запятым (в общем случае, по любым символам).

          2. Отредактировать (удалить и начать набирать новый) текст в области между скобками, кавычками и т.п., когда курсор находится в произвольной позиции в этой области.

          3. Вставить столбец чисел в псевдотабличку (набор из выравненных столбцов, разделённых пробелами).

          4. Сделать следующее: имеется несколько строк с текстом, например, с объявлениями переменных, завершающиеся комментариями. Нужно перенести все комментарии в отдельную строку над соответствующим объявлением (опционально добавить пустых строк между каждым объявлением).


    1. vtb_k
      26.12.2022 02:40

      Пускай заминусят, но я знаю офигенный способ решения чуть ли не 100% проблем с vim.

      И это Емакс с evil-mode. Лучшее с двух миров. VSCode идет в топку. Он никогда не будет настолько же удобен, как настроенный под себя Вим или Емакс.


  1. ReadOnlySadUser
    26.12.2022 02:27

    del


  1. saboteur_kiev
    26.12.2022 02:40

    по поводу hjkl
    Нет никакой философии в плане "не пользоваться стрелочками".
    Просто в древние времена некоторые терминалы и протоколы не поддерживали передачу непечатаемых символов, отсюда и буквы. А когда появились стрелочки - добавились и стрелочки


    1. Angeld
      27.12.2022 21:21

      стрелочки добавились, но в модальном редакторе их использовать смысла нет, hjkl удобнее, тем кто переходит с обычных редакторов мешают только привычки. Новичку у которого их нет без разницы какие клавиши для перемещения использовать. Тем более, что не так часто требуется перемещатся по одному символу.
      Может модальный режим и появился из-за технических проблем передачи символов, но оказался так удобен, что его предпочитают, когда уже давно нет этих технических проблем.