Comments 46
У них есть божество Lua, которое многократно усиливает их магические способности.
Скорее все же Emacs Lisp :)
VSCode 1997
Это о чём вообще?
На самом деле, выглядит совсем неплохо. Я часто хейчу хабрастатьи по виму за то что авторы не понимают суть. А суть как раз в том что Helix пытается сделать - модальный лёгкий комбайн. Для себя пока не вижу причин перекатываться с Neovim - он живее всех живых, а helix пока ещё молодой и непонятно, что с плагинами.
Schema, конечно, хорошо, но Lua всё же лучше. Rust тоже немного напрягает, слишком токсичный. Конфиг всё же хотелось бы на настоящем программируемом языке, а не просто флажки в томле.
Ещё важный вопрос - как он живёт без графики? Можно запустить в tty или на сервере по ssh?
Я не пользуюсь, но говорят хорошо живет с ssh. В tty отлично запускается, и в этом плане он намного удобнее nvim, потому что по дефолту умеет многое, а на чистом виме без плагинов как инвалид себя чувствуешь. Во время установки новой системы я теперь в нем предпочтаю конфиги править.
В текстовом режиме все работает в терминале тоже (с юникодовыми шрифтами). У них на сайте, на главной странице, анимация из консольного режима есть. В принципе можно скачать AppImage и проверить на своем сервере.
Emacs требует одновременного нажатия нескольких клавиш. И пользует Emacs Lisp. Первое оказалось плохо как с точки зрения физиологии (причём я отдалённо вспоминаю что на старых клавиатурах, тех где функциональные клавиши располагались в две колонки слева, с этим было лучше) так и с точки зрения протоколов удалённого доступа. Второе разбивается о традиционую погибель размножения вариантов, учить язык специально для единственного применения - от этого Flutter худо, куда уж тут Emacs...
Neovim сильно страдает от обилия плохих учебных материалов. Стандарт - а вот мой (великолепный, волшебный, великий, всемогущий) конфиг, может с какими-то комментариями. Должно быть - чтобы Neovim делал это (и ничего больше!!!!!!!!, красноглазики) а) сделать выбор из и б) прописать в конфиг так ( с минимумом, который обысно ноль, зависимостей). И отдельно, без привязки к любой другой функциональности, как автоматизировать работу с конфигом. Плюс масса просто устаревшего. Понятно какие психологические причины нормально делать не дают.
Абзац выше написан для тех, кто решил посмотреть на Neovim. Они увидят океан грязи, пусть знают - это не Neovim, это суета вокруг.
Helix делает противоположный остальным выбор - работа из коробки вместо конфигурируемости. Это будущее всегда, не только в редакторах - конфигурируемость нужна чтобы выяснить что и как должно быть, после этого она отправляется на покой по любому, в худшем случае - вместе с конфигурируемым софтом. Популярность Helix доказывает - и Emscs и Neovim упустили момент прощаться с конфигурируемостью.
Рядом с конфигурируемостью стоит автоматизация, плагины всякие. И до этого Helix ещё не дорос, что нужно учитывать желающим перейти.
А так - Helix действительно работает из коробки, иногда с некоторыми мелкими погрешностями, типа сколько возможных продолжений после точки показывать. Узнать что делать чтобы заработал конретный язык - одной коммандой hx --health. Иногда, конечно, не работает - как он из коробки узнает, например, где находить хедеры в проекте на С?
Популярность Helix доказывает - и Emscs и Neovim упустили момент прощаться с конфигурируемостью.
Пока рано говорить - сколько их таких было за 33 года (или 48 если мерять от емакса)?
сколько их таких было за 33 года
Популярных модальных текстовых редакторов кроме vim/neovim? Да ни одного. Тот же Kakoune на Helix может и повлиял, но популярным я его не помню.
Делали варианты vim, ни один не взлетел - значит vim всё делал правильно. Тот же Kakoune совершенно прав - глаголу лучше быть последним. И никого это не вдохновило куда-то переходить. А Helix с его работой из коробки - начинает вдохновлять.
Популярных модальных текстовых редакторов кроме vim/neovim?
А я ведь цитировал другой тезис) Я про работу из коробки - программистам важнее гибкость чем удобство. Потому что языки и технологии развиваются быстрее чем редакторы, поэтому догонять можно только усилиями всего сообщества. Если Helix не сделает плагины, его будет ждать та же участь.
Мне кажется, что программисту, и вообще любому пользователю чего угодно, по началу действительно важнее гибкость, а потом становится понятно как одним или двумя способами её использовать и важнее становится удобство, которое включает в себя правильно сконфигурированную гибкость. Поэтому я на предыдущие вбросы удобства и не подумал - рано ещё, чего ждать...
Однозначно взлетевшее - VS Code, и это при его прожорливости. Сначала было море конфигурируемости, а свелось всё к LSP, tree sitter, плюс мелочёвка. И главное - можно свои плагины писать. Путь тот же, что у Neovim -> Helix.
Если Helix не сделает плагины, то это будет модальность против плагинов. Это как минимум место под солнцем, иначе при наличии Neovim никакой популярности Helix не было бы.. А если сделает Helix плагины, то выяснится, что большинство их не пишет, место под солнцем станет больше без радикальных последствий.
Интереснее что будет если neovim станет сам обнаруживать сервера из коробки - nvim --health. Или helix сделает протокол для написания плагинов работающих в другом процессе и написанных на чём угодно, аналогия с LSP.
Сначала было море конфигурируемости, а свелось всё к LSP, tree sitter
Когда в VSCode начали tree-sitter использовать?
Какая разница если функциональность та же? Почему та же? Да потому, что стало понятно какой она должне быть.
Я как раз и (безуспешно) пытаюсь объяснить - всякая конфигурируемость есть всего лишь средство установить какой должна быть правильная конфигурация.
Интересная позиция. Не думал под таким углом. Действительно широкая конфигурируемость может помочь привести к хорошей дефолтной конфигурации. Это новая для меня идея.
Но я думаю конфигурируемость все таки нужна. Она нужна не всем, не всегда, не во всем... Но у людей разные потребности и хотелки. И одно приложение может удовлетворить большее количество людей если будет возможность настроить его под себя. Речь ведь не идет о полном исключении опций, настроек, расширений?
Всё-так, не совсем корректное сравнение IDE и текстовых процессоров!
Да, модальный текстовый редактор - это своя особая философия - но это именно философия просто текстового процессинга с небольшой приправой альтернативного управления командами редактора, вместо горячих клавиш.
IDE - это куда большее приложение - в котором текстовый процессинг лишь одна из составляющих IDE - тесно интегрируется с API ключевых приложений, которые и обеспечивают взаимодействие текста и выходной продукции - условно бинарный результирующий поток; IDE всецело управляет этим не только формированием этого потока, но и его дальнейшим использованием (условно я про отладку и профилирование, но не только про это).
Но да - для современных IDE текстовый процессинг это очень важная составляющая (но не более 20%), и в дополнении к ней активно растут пять сопутствующих составляющих:
Глубокий, в т.ч. машинный, анализ кода
копилотинг- умная runtime-автоподстановка, рефакторинг и преобразование шаблонного кода к контекстно зависимый; умный поиск готовых решений и их адаптация по контест
Глубокий тестинг - на неявные ошибки и просто выполнение тестов прямо в rutime design в IDE
Препроцессинг и макропроцессинг - выполнение кода в design, в т.ч. в runtime прямо в IDE видеть предполагаемый результат
Автогенерацая дополнительных форм по написанным текстам - от банальной кодогенерации до автодокументирования и генерации автотестов
Которые расширяют текстовый процессинг в IDE уже до 60% всех его ключевых составляющих!
Ну и, само собой, средства отладки, профилирования и реверсинженирования (рефлексия в код) тоже сейчас активно развиваются - и дадут ещё 20-25% ключевого функционала IDE.
Что там ещё останется.... версионирование и некоторые мелочёвки (как подключение к СУБД, спец. редакторы ресурсов), если ничего важного не забыл!
Ах... да.... конечно же - визуальный редактор и предпросмотр как выходных форм, так и прочих схем - это всё тоже прерогатива IDE! Это ещё 5-10% её функционала!
И где-то пара процентов - интеграция с внешними платформами - например с игровой Unity!
Безусловно - многое из названного можно и в текстовых процессорах а-ля VIM, Sublime или VS Code, плагинами реализовать - но это само по себе будет большое искусство и труд, и как такие монстры (которые собраны из кучи заплаток) будут вместе работать - никто не предскажет - в отличие от целостных IDE - где всё это сразу разрабатывается и тестируется как единое целое!
А запустил современную продвинутую IDE - и.... тебе тут же копилотинг код начал дополнять (не надо только это превращать к холивор - кому-то нравится, кому-то нет - это просто пример, да и явно эта тема будет в ближайшие десятилетия/столетия активно развиваться и совершенствоваться; уже очень интересно что нового будет тут в следующей Visual studio - уверен на AI помощника и лингво-генеративное программирование будут делать ключевую ставку в новой IDE)!
Но... IDE ведь тоже расширяемы... так почему бы не расширять их текстовый процессинг - внедряя модельное управление внутрь IDE! Вроде как IDEA отчасти это умеет, но поправьте меня если я не прав - не спец по IDEA, не адепт модальной философии
А что до модального подхода... это было интересно на рубеже XX/XXI веков!*
А на рубеже XXI/XXII рулить будет уже как минимум голосовое управление - и, как вариант, особый матерный сленговый язык - когда программист будет параллельно с относительно классическим текстовым набором кратко общаться с умным AI помощником, который будет его понимать с полуслова, а адаптируясь к его модели общения!
Да что там конец века - уже в середине XXI века AI помошник станет ключевым инструментом в кодинге, рефакторинге, кодогенерации, отладке, тестировании и профилировании!
* но - возможно я ошибаюсь, этот сленговый подход как раз и приведёт к тому, что большинство программистов перейдёт именно к модальному походу - и буду управлять процессами IDE через нечленораздельные короткие фразы. А интеллектуальные помощники и продвинутые IDE будут помогать легко осваивать такой подход - поэтапно к нему подготавливая программистов - через освоение промежуточных инструментариев и адаптации к сленговым командам управления!
Сравнение IDE и текстовых редакторов, конечно, совсем не корректное. Но так уж повелось, везде в интернетах именно в таком контексте их и сравнивают - а можно ли допилить редактор _____ до полноценной IDE? И никто не задается вопросом а можно ли книги писать в Emacs? А можно ли курсовую работу в Vim оформить? Всех интересует сравнение именно с IDE.
В IDE были вялые попытки интеграции... Даже не интеграции, а vim-mode. Вообще этот принцип и эти базовые хоткеи вима так много кому полюбились, что vim-mode можно встретить и за пределами кодинга. В obsidian например есть. Но vim-mode реализует только самый базовый функционал yy dd hjkl... Чуть что посложнее или русская расладка - все, конец эмуляции, давай дальше мышкой.
Я слышал к Qt Creator есть что-то более серьезное, плагин или что-то там. Позволяет прямо полноценный редактор Vim запускается внутри Qt Creator, и пользовательский конфиг вима работает в этом всем. Но у меня не завелся с первого раза, больше не пробовал.
Хорошо было бы иметь возможность к любой IDE прикрутить любимый текстовый редактор, кому Emacs, кому Vim, кому еще что. Не знаю почему эволюция инструментов разработки не пошла таким путем, может время еще не пришло, и однажды увидим MS Visual Studio [Vim]. А может оно никому не надо. Я думаю что второе.
И никто не задается вопросом а можно ли книги писать в Emacs? А можно ли курсовую работу в Vim оформить?
А Вы уверены что не задаются?
Например в этих редакторах вполне себе и профессионально можно писать и книги и курсовые в скриптовых типогравских языках (язык компьютерной вёрстки). Я тут не спец и очень давно этого дела касался - но VIM как и Emacs или VS Code (с плагином) точно поддерживает хотя бы LaTeX.
Но в чём была подколка - я не понял - это всё текстовый процессинг. Как и тои же MS Word.
Я слышал к Qt Creator есть что-то более серьезное, плагин или что-то там. Позволяет прямо полноценный редактор Vim запускается внутри Qt Creator, и пользовательский конфиг вима работает в этом всем
Мне кажется, это вполне интересный подход. В бОльшей системе Нужно расширять/заменять какую-то её отдельную составляющую!
Не знаю почему эволюция инструментов разработки не пошла таким путем, может время еще не пришло, и однажды увидим MS Visual Studio [Vim]. А может оно никому не надо. Я думаю что второе.
Не падайте духом! IDE сейчас активно развиваются - так что у них всё впереди! Прочитай-те лучше ещё раз вторую часть моего предыдущего комментария - там полно прямых намёков! Просто развитие оно многогранно - и то, что есть сейчас в VIM - тоже будет развиваться дальше - и lfkmit гибридизировать с IDE
И уверен - к середине и к концу века "мы увидим" ещё много интересны и новаторских подходов к кодированию - которых вообще нет сейчас!
Например - как я уже выше намекнул: очень назрела идея параллельного потока команд при программировании! Сейчас их два: клавиатуру и, условно, мышь - но руки только две - и параллельно оба потока не получается эффективно использовать! Отсюда и родилась концепция "vi".
Но если развитие технологий в ближайшие десятилетия - таки даст возможность эффективно вести ввод команд в несколько параллельных потоков - это будет прорыв. Один из вариантов я озвучил - это голосовой ввод!
Или ещё пробовали ногами!
Другой вариант - это управление взглядом!
Далее - силой мысли!
А развитие автокодинга, AI-ассистентов вместе с инструментарием IDE - который будет адаптироваться к новым возможностям ввода и рефакторинга - будут формировать новые стратегии по вводу программного кода - да и вообще любому вводу и дизайну данных и графических (или ещё каких, например звуковых) представлений!
Да и сам кодинг (или ввод любого текста и не текста) существенно изменится (далее для простоты буду про программирование говорить) - появится новые ЯП, адаптированные под AI ассиситирование и кодогенерацию. Не нужны будут изощрённые средства текстового рефакторинга* - кодирование будет более компактным - декларативным - а AI-ассистент будет выполнять всю черновую работу - а программист далее будет только его направлять и просить переделать с учётом новых замечаний! Изредка только детально вмешиваясь в сам процесс кодинга!
* Важное замечание - я говорю о потери интереса именно к прямому текстовому рефакторингу - в отличии от того, что лексический контекстный интеллектуальный рефакторинг будет наоборот, набирать обороты!
А Вы уверены что не задаются?
Например в этих редакторах вполне себе и профессионально можно писать и книги и курсовые в скриптовых типогравских языках (язык компьютерной вёрстки). Я тут не спец и очень давно этого дела касался - но VIM как и Emacs или VS Code (с плагином) точно поддерживает хотя бы LaTeX.
Но в чём была подколка - я не понял - это всё текстовый процессинг. Как и тои же MS Word.
Не задаются. Просто пишут и все). Я имею ввиду что, те кто уже начали пользоваться "продвинутыми" редакторами неизбежно приходят к тому, что набирать текст как прежде уже не хочется. В итоге в этот редактор стекает все: емэйлы, мессенджеры, написание блога/книги, формул LaTeX. С этим вопросов уже не возникает. Ну у меня не возникло, и других вроде тоже. Не видел громких постов в духе "NeoVim vs Scrivener" или "Emacs better then TeXmaker". Все холивары и муки выбора только вокруг сравнения IDE и этих редакторов. Я в статье постарался юмористично обойти этот вопрос, не начинать их сравнивать. Очевидно, что лучшего тут нет, и каждый "мир" имеет право на жизнь.
Говорят Илон Маск уже замутил чип в мозг который позволяет "силой мысли" вводить текст в смартфон. Или что то очень близкое к этому уже. Так что ноги наверное останутся без дела)
Давненько смотрел на helix, но:
Кодовая база хеликса хотя и кажется маленькой, на самом деле имеет много скрытой внутренней сложности. Заводил багу на то что вертикальные отсечки рисуются не у всех тем и хотел было пофиксить. Оказалось, что по какой-то причине файлов стилей есть несколько в разных местах. Сопутствующий код размазан по нескольким местам и имеет кучку скрытых штук, на которые необходимо делать поправку. Доков по теме нема.
Первый пункт тянет за собой второй пункт - фиксы влияваются крайне неспешно. Например, PR фикс цвета для всяких косых-кривых отсечек статусной строки до сих пор не слили.
Проблемы c LSP для С/С++ ровно те же что и у neovim, а точнее у clangd - если проект не собирается на текущей платформе или проект собирается особенным способом - получите обрубок. А т.к. плагинов нет, то и расширения для TreeSitter тоже не прикрутить.
Конфигурация редактора довольно странная. И если вам случилось сломать кофигурацию невалидным toml, то конфигурация сваливается в дефолт. Сомнительное поведение, но иную обработку конфигов пока не завезли, также как и их отладку перед применением.
Общее впечатление - глав ментейнер зашивается и не успевает/не планирует обрабатывать тот поток issue и PR, которые добавляет сообщество. Поэтому сомневаюсь, что helix когда-нибудь сможет догнать neovim.
Ну наверное он не будет идеальным. Не могу оценить качество кода столь крупных проектов. Но теоретически я уверен что перестать тащить за собой 48 летнее наследие и VimScript - это хорошая идея.
3 - ну надо дождаться системы плагинов. Понятно что без нее не взлетит.
4 - а как иначе? Я правда не встречался с другим подходом... Если не валидный конфиг то подгружается дефолтный. Это уже хорошо. У некоторых просто падает и не заводится. А в NeoVim lua перестает работать, так что все держут один редактор открытым, запущенным на старом конфиге, потом пробуют запускать измененный, а то можно остаться с редактором инвалидом против испорченного конфига.
Я как то не подчеркнул в статье, я не админ. Но вот именно для админов этот редактор уже превзошел vi vim neovim. Он быстрее. Он работает из коробки. И умеет чрезвычайно дофига из коробки.
Через 5-10 лет увидим какое место займет Helix и где будет NeoVim. Я беру колу и попкорн, остаюсь на Neovim, иду болеть за Helix.
а как иначе? Я правда не встречался с другим подходом.
в моём neovim если я вставил ошибку луа где-то посреди конфига, то оно до какой-то степени продолжает работать, по крайней мере тема не дефолтится к исходной потому что луа исключение кинуло. То есть порядок шагов должен быть несколько иной - прочитать конфиг, завалидировать, ресетнуть установленные настройки, накатить прочитанные. Helix начинает этот пайплайн с ресета. Решений тоже несколько и самый простой - хранить бэкап последней сохраненной валидной конфигурации.
Но вот именно для админов
Пока он определённо не дотягивает до vi/nano/ee тем что а) его нет в дефолтных поставках дистров и б) бинарь весит слишком много. На моей машине после cargo install оно показывает ажно 31 метр без учёта lsp/dap/грамматик, против 10 у nvim и 1.6 метра у vi, 287 кило nano или 96 кило у ee . Админам такое не очень нравится - правки скриптов и конфигов на разных удалённых машинах такого врядли стоят. Плюс я сомневаюсь, что helix умеет в туннелирование, как это работает в neovim через --remote или nvim scp://user@myserver[:port]//path/to/file.txt.
Через 5-10 лет
Остаётся надеяться, что автор будет жив и проект ускорит разработку. Для добавления в дистры наверняка многие захотят порезать жирок и сделать воспроизводимые билды, до тех пор какого-то особенного будущего кроме нишевого сегмента энтузиастов пока не предвидится.
emacs и vi/vim пережили многие десятилетия и сотни разных киллеров старины по множеству разных причин. LSP подарил им очередную молодость.
Я процентов 60-70 дня провожу в ОС emacs в vim-режиме и мне чертовски удобно. Более того, когда мне нужна IDE я просто переключаюсь в VS Code со включенным vim-плагином и донастроенными под мои привычки хоткеи. А когда я попадаю на удалённые linux, то я не теряя никаких кардинальных вещей правлю нужное мне в vim/vi.
Для меня ключевая фишка vim/emacs+vim mode это эргономика рук "home row" и дополняющие её механизмы контекстных leader-сочетаний, не требующих "распальцовок". Например "spc f" это перейти в диалог открытия файлов с магическими ускорителями, "spc j" это переход в файловый менеджер в каталог текущего файла, "spc m k" это создать новую быструю заметку-задачу и положить её в inbox моего задачника, и т.д. и т.п. 100500 удобств пользователя текстовых OS.
А очередной универсальный ответ на все ранние стандарты это хорошо, это замечательно. Периодически они приносят нам вещи вроде LSP и treesitter, за что им большое спасибо.
Да, home row. Мне кажется половина споров про Vim/другой кончились бы, если в начале задать вопрос - а ты в слепую печатаешь? Нормально в слепую, то есть полностью и десятью пальцами? Тогда можно посмотреть на Вим. Если нет - в нем нет практически никаких плюсов, они на 10 делятся если на клавиатуру смотреть. И лучше работать в любой IDE. Гораздо лучше.
Весь кайф и скорость от вима получаешь как раз при слепом наборе. И это такой кайф, что потом ради него готов заморочиться с докручиванием вима до приемлемой среды разработки. А если пойти еще на шаг дальше, в lua/vimscript то уже никакая IDE не нужна. Не то чтобы лучше хуже... просто 90% нужного прикручиваешь, и наслаждаешься hjkl yy dd p o O 0 ^ $... а surround, а макросы... да чтоб после этого вернуться на стрелочки с Ctrl+C / Ctrl+V... да только в страшном сне.
А потом и в браузере и в оконном менеджере / композиторе те же горячие клавиши. И двигать руку на мышку становится совсем грустно.
я бы не был столь категоричен как истинный ситх из Звёздных Войн по поводу "или только полностью слепой 10 пальцевый метод или никакого vim". Я, со своими 30 годами в ИТ так и не научился за ненадобностью в полный слепой набор, что никак не мешает мне быстро набирать тексты и пользоваться всеми достоинствами vim/emacs, делая основные операции вслепую. С ним наверняка лучше, но и так потрясающе хорошо.
Ок. Категоричность=False. Буду знать что и так бывает.
В какой то момент читая споры вокруг Вима, я подумал, что большая их часть вызвана отсутствием слепого набора у одного из спорящих. Я про себя точно знаю, дай мне вим до слепой печати - не понял бы фишку. А с десятипальцевым - любовь с первого клика по hjkl.
Лично для меня VIM, эти когда надо по-быстрому что-то отредактировать, конфиги, какие-то разрозненеые исходники, etc.
Я не представляю, что на нём или на чём-то другом можно было бы реализовать весь функционал IDE. Ещё не стоит забывать, что в них есть редакторы GUI.
Так что, сравнение не корректно.
vim также очень удобен, если надо очень быстро обработать гигабайтный файл да с полуавтоматическим режимом с макросами. Макросы это прямо базовая опция для меня: я ими пользуюсь не задумываясь и в других редакторах практически сразу обнаруживаю их отсутствие.
а касательно механизмов IDE, то по сути language servers уже реализованные под vs code принесли почти все ide-функции во все редакторы, которые умеют в LSP. Отладку тоже через коммунальный DAP завозят. IDE просто это всё сами интегрируют, а в редакторах требуются телодвижения, но с каждым годом всё меньше
Весь как правило и не реализовывают. Никто ведь не использует ВЕСЬ функционал IDE. Но по отдельности практически любую штуку можно прикрутить. Каждый докручивает на столько на сколько ему надо. Некоторые вещи легко и быстро прикручиваются. Некоторые костылями. С чем то придется смириться. В IDE тоже приходится смиряться. А в чем то можно получить 200% профита от кастомизации.
Я думаю здесь подходит такая метафора к миру авто: IDE это массовый рынок автобилей. Emacs и Vim это гаражный тюнинг, это то, что в серийке никогда никто не сделают. Слишком специфично. Но те кто возятся в гараже со своими машинами делая их архе-проходимыми, или архе-саунд сустем, или че там еще кому надо... Они как сидели в своем гараже так и будут. Их никогда не удовлетворит готовое, они хотят по своему и по другому.
При этом хорошие водители и профессиональные водители бывают и там и там. И хорошие люди бывают и там и там.
Редактор гуи если он есть как утилита, в случае Qt, тоже можно прикрутить, скрипт написать который этот файл будет обрабатывать. Кого то такое прикручивание устраивает. Я день пострадал, а потом оказалось создавать Gui прямо в коде нифига не сложно, а через несколько месяцев даже быстрее стало получаться чем мышкой.
Сравнение не корректно. Но десятки тысяч людей пишут код в Emacs/Vim и не используют IDE вовсе, или используют как второстепенный вспомогательный инструмент. И да, таких меньше.
Можно конфиг hyprland с скриншотов? Выглядит похоже поэтому предположил что оно и есть.
Врят ли будут пересаживаться с Neovim на Helix. Многие долго настраивали его под себя и сделали его идеальным(опять же под себя), а тут что-то новое, при чем не на lua.
А в 2015г все сразу побежали на NeoVim?
Зачем-то начали переписывать все плагины, которые вроде работали на VimScript и работали...
Естественно будет очень большой этап сопротивления, в NeoVim массовый переход не в первые два года начался.
30.000 на гитхабе, это очень много, серьезная заявка на победу. Поживем увидим.
А я сделал в конфиге NeoVim маппинги как в Helix и кайф
Surround
Похож на nvim-surround плюс автозакрытие скобок.
Надеюсь, что автозакрытие настраивается отдельно. Сколько встречал автозакрытий в разных редакторах, они больше бесили, когда автоматом ставили скобки(а так же другие "скобки" типа кавычек) куда не требуется.
В Helix сначала выделяем, затем выбираем действие
Насколько я понял, это делает невозможным указание количества повторений. Скажем, не так уж редко я удаляю(точнее, заменяю) часть слова до второй точки или какое-то подобное действие. В Vim потом я это комплексное действие, включая и удаление старого текста и добавление нового вместо старого, могу повторить в другом место просто нажав ".". В Helix выходит, что мне первое действие надо будет это сделать за два приёма, а повторить это уже получится никак. Можно, конечно, поспорить и сказать, вот тут-то мультикурсор самое то, но по мне мультикурсор значительно менее удобен в этом случае. Второй минус такого подхода для меня(хотя это крайний случай): если терминал тормозит, то иногда проще выполнить команду типа "10j", чтобы сдвинуть курсор несколько ниже, чем пытаться попасть в нужную строчку двигая клавишами курсора.
Вопрос: а как у Helix в целом с повторением прошлой выполненной команды? У тех же Vim/Neovim есть замечательный плагин vim-repeat, который улучшает возможности встроенного повторителя ".".
Edit: ещё подумалось, что для описанного мной выше повтора замены до второй точки можно ещё попробовать поиск/замена с регулярками. (Кстати, а в Helix есть превью текста,чтобы видеть какам будет текст после наджатия на Enter и выполнения набранной команды? В NeoVim это очень удобная фича, особо если в регулярке не уверен :) ) Но, опять, писать регулярку ради замены текста в нескольких строках как-то тоже кажется перебором.
Повторение команд через точку есть. Отличается ли его поведнние от вимовского не вникал. Про скобки тоже не знаю, мне нравится автозакрытие. Порторение через цифры тоже есть.
Редактирования более сложные чем то, что можно повторить через . я делаю записью макроса. И плюс биндинг на вызов этого макроса. Ну например я испольхую букву m для временных макросов. Плюс чтобы упростть вызов макроса с вместо @m , сделан бипд Alt+m. Макросы в helix уже есть.
Я не прошел весь тутор, Но то что прошел показывает - helix может все что может вим в редактировании, иногда это делается точь в точь как в вим, иногда несколько другим способом. И есть новые фичи, или скорее встроенные по умолчанию, а в вим доступные через плагины.
Это уже детали, их долго можно обсуждать, проще установить и попробовать тутор. Сразу будет понятно, стоит ли ждать и наблюдать за проектом, или закрыть/удалить/забыть, и открыть снова вим..
Редактор кода Helix — лучше чем NeoVim?