Откиньтесь на спинку кресла, пододвиньте монитор поудобнее, сейчас будет краткий магически метафоризированный рассказ о редакторах кода. А потом, о новом явлении, или даже тектоническом сдвиге, в этом древнем мире. О редакторе Helix, глазами старого Vim-овода.
Существует три мира
1. Мир IDE
Они всевластны. Их прародитель Turbo Pascal 1983. Ныне его можно встретить в музеях и на скриншотах. Хотя может быть еще есть люди, которые владеют древним знанием DOS и могут его запустить.
В мире IDE много сект, которые отличаются друг от друга обрядами, однако между собой, в целом, живут мирно. Microsoft Visual Studio 1997, VSCode 2015, IntelliJ IDEA 2001, QtCreator 2009 и многие другие.
Здесь живут маги творящие заклинания из:
ctrl+[a, z, x, c, v, b, f, h]
ctrl/shift+"чето_там"
и еще они владеют мышкой
Они уверены, что их заклинания самые сильные. Что самые крутые маги принадлежат школе IDE, что все масштабные проекты созданы IDE магией. А их заклинания по рефакторингу вообще не имеют аналогов. Остальное - это недоделанные блокноты, экзотика, а использующие их гики ковыряют только свои маленькие проекты.
2. Мир Emacs
Я мало знаю об этом мире. Это древние маги. Впервые они появились в мире в 1976 г, это 48 лет назад. Их верховный мастер сам Ричард Столлман! В том, что сейчас называют GNU/Linux, первые 3 буквы это его рук дело.
Здесь владеют могущественными заклинаниями из:
Ctrl+Shift+Meta+[все_буквы_цифры_символы]
У них есть божество Lisp, которое многократно усиливает их магические способности. Однако, доступ к этому божеству есть не у всех. Необходимо обучение и посвящения от старых мастеров.
Говорят у них даже есть своя операционная система, в которой они делают все, но для конспирации ее называют так же как редактор - Emacs.
3. Мир vi-Vim-NeoVim
Об этих магах стали говорить после 1991 г, когда пророк Брам Моленар явил миру учение Vim. Но адепты этой школы знают, что на самом деле, все началось задолго до пришествия Брама. В 1976 г будда Билл Джой достиг просветления при редактировании кода и сказал - это "vi". Таким образом это тоже древнейшие маги.
Здесь владеют могущественными заклинаниями из:
[Все_Буквы_Цифры_Символы_ПричемРегистроЗависимые], которые имеют разные эффекты в зависимости от руны 'n' 'i' 'v'. Есть и другие, продвинутые, менее известные руны, например 'с' 't', говорят их аж 14. Но их никто не знает. И вообще даже самый крутой Neo маг знает и владеет не более чем 5% учения, настолько уж оно обширно.
У них есть божество Vimscript, которое многократно усиливает их магические способности. А теперь, с приходом эпохи NeoVim они так же получили доступ к божеству Lua.
Тот кто попал к ним, обычно не может выйти.
Эти три мира непримиримы, каждый из них за десятилетия доказал право на место под солнцем, и в целом во вселенной редакторов кода поддерживался баланс. Но вот, в третьем мире "vi-Vim-NeoVim" началось что-то нетипичное:
If Neovim is the modern Vim, then Helix is post-modern.
За бугром уже вовсю крутятся обзорные ролики показывающие первые заклинания, доступные без посвящения. Старейшины собираются на githube и записывают учение. А вокруг обсуждают вопрос: "Helix Text Editor: Better than Neovim?".
На территории рунета пока тихо, один ролик на ютюбе, да пара упоминаний мельком на хабре. Попробую свои силы в первой статье для многочисленного, сильного и уважаемого клана "Хабр", надеюсь меня возьмут в их ряды.
Чем Helix отличается от Vim?
Цитата с официального сайта:
Начав с нуля, мы смогли извлечь уроки из нашего опыта работы с Vim и внести некоторые кардинальные изменения. Результатом является гораздо меньшая кодовая база и современный набор значений по умолчанию. Легче начать работу, если вы никогда раньше не использовали модальный редактор, и надо будет гораздо меньше возиться с файлами конфигурации.
А еще он многое взял от Kakoune, про который тут речь не пойдет, но можно посмотреть здесь.
Helix написан на Rust, без Electron, без VimScript, без JavaScript. Работает ощутимо быстрее чем Vim, но сравнение некорректно, Vim у меня плагинами обвешан, и их гораздо больше чем в базе у Helix.
Да, Helix приходит не голым чистым листом, предназначенным для дальнейшей доработки напильником. Он уже заряжен и готов к работе. Лица ортодоксов кастомизации сейчас должны выражать глубокое разочарование. Я тоже, услышав это не воодушевился, а напрягся. Но посмотрите на этот список! Что тут лишнее, если это редактор для кода?
Color scheme
Из коробки доступны все темы для NeoVim с первой страницы по популярности. Пишем ":theme " и щелкаем "tab" в поисках того, что глаз радует, или вводим первые буквы своей любимой темы. Не надо ничего качать, не надо ничего в конфиг писать. Просто. Удобно. Такой же функционал предоставляет, например, NvChad сборка для Vima.
Multiple Cursor
Это вообще за гранью добра и зла. Жмем "Shift-с" и появляется второй курсор, еще раз "Shift-с" и еще один. Хоть 100500 курсоров делай, жми "," чтобы вернуться к одному курсору. В начале курсоры располагаются друг под другом, и позволяют делать примерно тоже что можно делать в NeoVim в блочном выделение "Ctrl-v". И ещеO намного больше, это все-таки отдельные курсоры, а не блок выделения. В паре предложений не описать то, что они позволяют делать. Просто посмотрите туториал, он как в Vim сделан ":tutor". Наверное не все так удивляются как я, позже выяснилось что для Vim есть плагин реализующий подобную функцию.
Fuzzy find
Как telescope для Vim, только работает по ощущениям быстрее.
Tree-sitter
Создает устойчивые к ошибкам и надежные синтаксические деревья, что обеспечивает лучшую подсветку синтаксиса, расчет отступов и навигацию по коду.
LSP
Когда начинал писать конфиг для NeoVim вообще не знал, что такое Language Server Protocol, примеры из интернета не работали, мне понадобилось несколько дней, чтобы заставить nvim-cmp работать.
К Helix все прикручивается само, нужно набрать в терминале "~helix --health", чтобы увидеть список доступных LSP, DAP, Formatter, Highlight, Textobject, Indent. Затем установить нужный пакет, например в Arch Linux для С/C++ выполнить "~yay -S clangd", или "~yay -S pylsp" для Python. Вуаля, автодополнение работает. И аргументы функции при вводе подсвечиваются, и документация подтягивается.
Surround
Похож на nvim-surround плюс автозакрытие скобок.
Интеграция с git
Измененные/удаленные/добавленные строки подсвечиваются по-умолчанию. Может еще что-нибудь, не знаю.
Я из тех, которые несколько месяцев причесывали и дополняли свой конфиг Vim-a. Это было интересное время, полезный опыт. Получился отличный, удобный для моих задач инструмент, гибкий, мощный, быстрый, легкий. Работать с которым в кайф.
Во второй половине работы над конфигом, когда основное уже настроил и было все почти идеально, читая очередную статью про NeoVim я видел, что темы пересекаются, грубо, на 50-80%. Одни и те же плагины, одни и те же рецепты.
То есть уже сформировался лучший user experience, и большинство решает одинаковые задачи одним способом. Helix собрал лучший опыт и сделал его по-умолчанию. Это просто экономит время.
Но есть и другие, более существенные отличия.
Editing model "selection -> action"
В Vim мы сначала выбираем действие, затем область его применения:
"di(" - удалить все что в скобках. В Helix сначала выделяем, затем выбираем действие: "mi(d" - match inside ( delete. На мой взгляд эта модель более интуитивна и естественна. Комфортнее видеть что изменяешь, до того как изменяешь. После Vim это, конечно, раздражает, а не радует, но это только дело привычки, нескольких дней или недель использования. Обе модели в принципе жизнеспособны, и существуют давно. В конце концов на практике это приводит лишь к тому что вместо "dw", вы будете нажимать "wd"
Simple config - toml
После Vim никакой конфиг нам не страшен. Но некоторые конфиги приятно удивляют своей простотой и понятностью. А тут еще и краткостью. Думаю рабочий конфиг Helix-a будет где-то в 10-50 раз меньше вашего конфига в Vim. И было очень приятно увидеть простые команды ":config-open", "config-reload".
Пример конфига:
theme = "kanagawa"
[editor]
line-number = "relative"
color-modes = true
[editor.cursor-shape]
insert = "bar"
normal = "block"
select = "underline"
[editor.statusline]
mode.normal = "NORMAL"
mode.insert = "INSERT"
mode.select = "SELECT"Всплывающие окна справки по хоткеям
В составных командах, типа "gg", после нажатия первой клавиши появляется окно с хоткеями. Тут много общего с Vim, по ощущениям где то на 70%. А изменения на мой взгляд в лучшую сторону. В Vim было "d" и "x" которые делают примерно одно и тоже. В Helix есть только "d". Он более ортогонален. Эти всплывающие окна наверняка можно отключить, не копал еще, в начале они помогают.
А что с плагинами?
А их пока нет. Но точно будут. Возможно на языке Scheme. В сообществе идет активное обсуждение.
Пара слов для эмигрантов из мира Vim
Готовьтесь, будет боль, больше всего бомбить будет когда "х" выделяет строку, а не удаляет то что выделено, или символ под курсором. А так же dd и yy сработают только на символ под курсором... Но это все мелочи.
Философия и пророчества
Некоторые могут морщить нос, мол это не Unix-way, одна программа должна решать одну задачу, комбайны и коробки это не труЪ.
На мой взгляд тут есть одно принципиальное отличие. Когда делали IDE и другие масштабные коробочные продукты (типа Photoshop, Autocad), люди думали над тем, что нужно пользователю в работе, как ему это лучше делать, и реализовывали это. Решения были и удачные, и не очень. Потом шло время, нужны были новые функции, нужно было поддерживать обратную совместимость, так комбайны становились все тяжелее. Они с одной стороны становились лучше, умели больше, а с другой стороны накапливали плохое наследие.
С Helix-ом кое-что по другому. Сначала был минималистичный, но гибкий редактор Vim. Который с годами делали еще и еще более гибким. А сообщество написало триллион плагинов, начиная от навигации по файлам заканчивая "завариванием_кофе" и "подачей_тапочек_к_кровати". Эти плагины прошли естественный отбор. И только теперь, когда мы уже знаем, что нужно всем нам, пишущим код в модальном редакторе, и как это лучше всего сделать, вот теперь это интегрировали. А еще многое было пересмотрено в Kakoune, теперь Helix пытается собрать лучшее из обоих. И у него получается. Посмотрите вот это обсуждение хоткеев.
Метафорически это не строительство комбайна. Это как раз похоже на то как работает эволюция. Сначала появляются отдельные формы, они тестируются, выживают лучшие, потом они интегрируются в более крупные системы. И так многократно.
Вот так вот за раз сесть и сходу написать проект человека со всеми его глазами, ушами, нервной системой, органами, колониями "пищеварительных" бактерий в кишечнике и с гораздо более низкоуровневыми подсистемами, - видимо даже архитектору этого мира было сложно. И он писал этот проект частями, проводя время от времени рефакторинг, и отбрасывая целые модули (типа динозавров).
При таком подходе сквозь годы можно выделить удачные решения, а плохое наследие само уходит на дно забытых репозитариев. То есть улучшения улучшаются, а плохое отмирает никому не мешая, благодаря тому, что это все отдельные кусочки, а не изначально целостная система.
Похоже что "никогда такого не было, и вот опять" пришли перемены.
system V -> systemd
xorg -> wayland
neovim -> helix
Хоть это и совершенно не равнозначные аналогии между длинным, горячим и зеленым, я вижу в этих переменах один и тот же принцип - интеграция проверенных элементов. И создание нового проекта с нуля опираясь на уроки и опыт работы с предшественником.
Конец мира NeoVim определенно не близок. Но Helix весьма вероятная замена. Жаль только название не PostNeoVim / pnvim. И он никак не может именовать себя чистокровным потомком древних магов vi.
Немного цифр
Количество звезд на гитхабе:
Vim - 35k
NeoVim - 79k
Helix - 30k
Количество строк кода:
Vim - 1.8m
NeoVim - 1.5m
Helix - 0.5m
Post scriptum
Я не перешел на Helix, но думаю, что перейду. Проекту еще только 2 года. В нем еще не хватает некоторых необходимых мне функций. Нет фолдинга. Нет древовидного обзора файлов проекта (в моих dev проектах можно без него обойтись, а в работе с блогом где гораздо больше файлов и разных форматов, и много одинаковых имен, но лежащих в разных папках, тут fzf не удобен).
И если с навигацией еще можно решить вопрос костылями, хаками и отдельным TUI файловыми менеджерами. То с фолдингом вроде пока никак нельзя. Ну и поддержки работы с русской раскладкой в normal-mode тоже, конечно, нет.
Я с интересом буду наблюдать за развитием проекта. Время от времени пробую набирать в нем несложные тексты, жду систему плагинов. Что-то мне в нем нравится, в самой его сути, философии. Helix обычно очаровывает пользователей Vim, а не разочаровывает. И по моему будущее за ним. А некоторые уже работают над своими проектами в Helix.
А вы что думаете? Уже пробовали?
Ссылки:
- Сайт проекта
- Github
- Документация по хоткеям
- Обсуждение хоткеев
- Обсуждение системы плагинов
- Миграция с Vim
- Hack с файловым менеджером yazi
- Про упомянутый редактор Kakoune
Комментарии (38)
CrazyOpossum
20.06.2024 06:38На самом деле, выглядит совсем неплохо. Я часто хейчу хабрастатьи по виму за то что авторы не понимают суть. А суть как раз в том что Helix пытается сделать - модальный лёгкий комбайн. Для себя пока не вижу причин перекатываться с Neovim - он живее всех живых, а helix пока ещё молодой и непонятно, что с плагинами.
Schema, конечно, хорошо, но Lua всё же лучше. Rust тоже немного напрягает, слишком токсичный. Конфиг всё же хотелось бы на настоящем программируемом языке, а не просто флажки в томле.
Ещё важный вопрос - как он живёт без графики? Можно запустить в tty или на сервере по ssh?
arsvincere Автор
20.06.2024 06:38Я не пользуюсь, но говорят хорошо живет с ssh. В tty отлично запускается, и в этом плане он намного удобнее nvim, потому что по дефолту умеет многое, а на чистом виме без плагинов как инвалид себя чувствуешь. Во время установки новой системы я теперь в нем предпочтаю конфиги править.
SnakeSolid
20.06.2024 06:38В текстовом режиме все работает в терминале тоже (с юникодовыми шрифтами). У них на сайте, на главной странице, анимация из консольного режима есть. В принципе можно скачать AppImage и проверить на своем сервере.
Octabun
20.06.2024 06:38Emacs требует одновременного нажатия нескольких клавиш. И пользует Emacs Lisp. Первое оказалось плохо как с точки зрения физиологии (причём я отдалённо вспоминаю что на старых клавиатурах, тех где функциональные клавиши располагались в две колонки слева, с этим было лучше) так и с точки зрения протоколов удалённого доступа. Второе разбивается о традиционую погибель размножения вариантов, учить язык специально для единственного применения - от этого Flutter худо, куда уж тут Emacs...
Neovim сильно страдает от обилия плохих учебных материалов. Стандарт - а вот мой (великолепный, волшебный, великий, всемогущий) конфиг, может с какими-то комментариями. Должно быть - чтобы Neovim делал это (и ничего больше!!!!!!!!, красноглазики) а) сделать выбор из и б) прописать в конфиг так ( с минимумом, который обысно ноль, зависимостей). И отдельно, без привязки к любой другой функциональности, как автоматизировать работу с конфигом. Плюс масса просто устаревшего. Понятно какие психологические причины нормально делать не дают.
Абзац выше написан для тех, кто решил посмотреть на Neovim. Они увидят океан грязи, пусть знают - это не Neovim, это суета вокруг.
Helix делает противоположный остальным выбор - работа из коробки вместо конфигурируемости. Это будущее всегда, не только в редакторах - конфигурируемость нужна чтобы выяснить что и как должно быть, после этого она отправляется на покой по любому, в худшем случае - вместе с конфигурируемым софтом. Популярность Helix доказывает - и Emscs и Neovim упустили момент прощаться с конфигурируемостью.
Рядом с конфигурируемостью стоит автоматизация, плагины всякие. И до этого Helix ещё не дорос, что нужно учитывать желающим перейти.
А так - Helix действительно работает из коробки, иногда с некоторыми мелкими погрешностями, типа сколько возможных продолжений после точки показывать. Узнать что делать чтобы заработал конретный язык - одной коммандой hx --health. Иногда, конечно, не работает - как он из коробки узнает, например, где находить хедеры в проекте на С?
CrazyOpossum
20.06.2024 06:38+1Популярность Helix доказывает - и Emscs и Neovim упустили момент прощаться с конфигурируемостью.
Пока рано говорить - сколько их таких было за 33 года (или 48 если мерять от емакса)?Octabun
20.06.2024 06:38сколько их таких было за 33 года
Популярных модальных текстовых редакторов кроме vim/neovim? Да ни одного. Тот же Kakoune на Helix может и повлиял, но популярным я его не помню.
Делали варианты vim, ни один не взлетел - значит vim всё делал правильно. Тот же Kakoune совершенно прав - глаголу лучше быть последним. И никого это не вдохновило куда-то переходить. А Helix с его работой из коробки - начинает вдохновлять.
CrazyOpossum
20.06.2024 06:38Популярных модальных текстовых редакторов кроме vim/neovim?
А я ведь цитировал другой тезис) Я про работу из коробки - программистам важнее гибкость чем удобство. Потому что языки и технологии развиваются быстрее чем редакторы, поэтому догонять можно только усилиями всего сообщества. Если Helix не сделает плагины, его будет ждать та же участь.
Octabun
20.06.2024 06:38Мне кажется, что программисту, и вообще любому пользователю чего угодно, по началу действительно важнее гибкость, а потом становится понятно как одним или двумя способами её использовать и важнее становится удобство, которое включает в себя правильно сконфигурированную гибкость. Поэтому я на предыдущие вбросы удобства и не подумал - рано ещё, чего ждать...
Однозначно взлетевшее - VS Code, и это при его прожорливости. Сначала было море конфигурируемости, а свелось всё к LSP, tree sitter, плюс мелочёвка. И главное - можно свои плагины писать. Путь тот же, что у Neovim -> Helix.
Если Helix не сделает плагины, то это будет модальность против плагинов. Это как минимум место под солнцем, иначе при наличии Neovim никакой популярности Helix не было бы.. А если сделает Helix плагины, то выяснится, что большинство их не пишет, место под солнцем станет больше без радикальных последствий.
Интереснее что будет если neovim станет сам обнаруживать сервера из коробки - nvim --health. Или helix сделает протокол для написания плагинов работающих в другом процессе и написанных на чём угодно, аналогия с LSP.
ris58h
20.06.2024 06:38Сначала было море конфигурируемости, а свелось всё к LSP, tree sitter
Когда в VSCode начали tree-sitter использовать?
Octabun
20.06.2024 06:38+1Какая разница если функциональность та же? Почему та же? Да потому, что стало понятно какой она должне быть.
Я как раз и (безуспешно) пытаюсь объяснить - всякая конфигурируемость есть всего лишь средство установить какой должна быть правильная конфигурация.
arsvincere Автор
20.06.2024 06:38Интересная позиция. Не думал под таким углом. Действительно широкая конфигурируемость может помочь привести к хорошей дефолтной конфигурации. Это новая для меня идея.
Но я думаю конфигурируемость все таки нужна. Она нужна не всем, не всегда, не во всем... Но у людей разные потребности и хотелки. И одно приложение может удовлетворить большее количество людей если будет возможность настроить его под себя. Речь ведь не идет о полном исключении опций, настроек, расширений?
LordDarklight
20.06.2024 06:38+2Всё-так, не совсем корректное сравнение 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 будут помогать легко осваивать такой подход - поэтапно к нему подготавливая программистов - через освоение промежуточных инструментариев и адаптации к сленговым командам управления!
arsvincere Автор
20.06.2024 06:38Сравнение 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]. А может оно никому не надо. Я думаю что второе.
LordDarklight
20.06.2024 06:38И никто не задается вопросом а можно ли книги писать в 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-ассистент будет выполнять всю черновую работу - а программист далее будет только его направлять и просить переделать с учётом новых замечаний! Изредка только детально вмешиваясь в сам процесс кодинга!
* Важное замечание - я говорю о потери интереса именно к прямому текстовому рефакторингу - в отличии от того, что лексический контекстный интеллектуальный рефакторинг будет наоборот, набирать обороты!
arsvincere Автор
20.06.2024 06:38А Вы уверены что не задаются?
Например в этих редакторах вполне себе и профессионально можно писать и книги и курсовые в скриптовых типогравских языках (язык компьютерной вёрстки). Я тут не спец и очень давно этого дела касался - но VIM как и Emacs или VS Code (с плагином) точно поддерживает хотя бы LaTeX.
Но в чём была подколка - я не понял - это всё текстовый процессинг. Как и тои же MS Word.
Не задаются. Просто пишут и все). Я имею ввиду что, те кто уже начали пользоваться "продвинутыми" редакторами неизбежно приходят к тому, что набирать текст как прежде уже не хочется. В итоге в этот редактор стекает все: емэйлы, мессенджеры, написание блога/книги, формул LaTeX. С этим вопросов уже не возникает. Ну у меня не возникло, и других вроде тоже. Не видел громких постов в духе "NeoVim vs Scrivener" или "Emacs better then TeXmaker". Все холивары и муки выбора только вокруг сравнения IDE и этих редакторов. Я в статье постарался юмористично обойти этот вопрос, не начинать их сравнивать. Очевидно, что лучшего тут нет, и каждый "мир" имеет право на жизнь.
arsvincere Автор
20.06.2024 06:38Говорят Илон Маск уже замутил чип в мозг который позволяет "силой мысли" вводить текст в смартфон. Или что то очень близкое к этому уже. Так что ноги наверное останутся без дела)
domix32
20.06.2024 06:38Давненько смотрел на helix, но:
Кодовая база хеликса хотя и кажется маленькой, на самом деле имеет много скрытой внутренней сложности. Заводил багу на то что вертикальные отсечки рисуются не у всех тем и хотел было пофиксить. Оказалось, что по какой-то причине файлов стилей есть несколько в разных местах. Сопутствующий код размазан по нескольким местам и имеет кучку скрытых штук, на которые необходимо делать поправку. Доков по теме нема.
Первый пункт тянет за собой второй пункт - фиксы влияваются крайне неспешно. Например, PR фикс цвета для всяких косых-кривых отсечек статусной строки до сих пор не слили.
сверху neovim, снизу helix Проблемы c LSP для С/С++ ровно те же что и у neovim, а точнее у clangd - если проект не собирается на текущей платформе или проект собирается особенным способом - получите обрубок. А т.к. плагинов нет, то и расширения для TreeSitter тоже не прикрутить.
Конфигурация редактора довольно странная. И если вам случилось сломать кофигурацию невалидным toml, то конфигурация сваливается в дефолт. Сомнительное поведение, но иную обработку конфигов пока не завезли, также как и их отладку перед применением.
Общее впечатление - глав ментейнер зашивается и не успевает/не планирует обрабатывать тот поток issue и PR, которые добавляет сообщество. Поэтому сомневаюсь, что helix когда-нибудь сможет догнать neovim.
arsvincere Автор
20.06.2024 06:38Ну наверное он не будет идеальным. Не могу оценить качество кода столь крупных проектов. Но теоретически я уверен что перестать тащить за собой 48 летнее наследие и VimScript - это хорошая идея.
3 - ну надо дождаться системы плагинов. Понятно что без нее не взлетит.
4 - а как иначе? Я правда не встречался с другим подходом... Если не валидный конфиг то подгружается дефолтный. Это уже хорошо. У некоторых просто падает и не заводится. А в NeoVim lua перестает работать, так что все держут один редактор открытым, запущенным на старом конфиге, потом пробуют запускать измененный, а то можно остаться с редактором инвалидом против испорченного конфига.
Я как то не подчеркнул в статье, я не админ. Но вот именно для админов этот редактор уже превзошел vi vim neovim. Он быстрее. Он работает из коробки. И умеет чрезвычайно дофига из коробки.Через 5-10 лет увидим какое место займет Helix и где будет NeoVim. Я беру колу и попкорн, остаюсь на Neovim, иду болеть за Helix.
domix32
20.06.2024 06:38+1а как иначе? Я правда не встречался с другим подходом.
в моём 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 лет
Остаётся надеяться, что автор будет жив и проект ускорит разработку. Для добавления в дистры наверняка многие захотят порезать жирок и сделать воспроизводимые билды, до тех пор какого-то особенного будущего кроме нишевого сегмента энтузиастов пока не предвидится.
arsvincere Автор
20.06.2024 06:38Хм, хранить бэкап последней валидной конфигурации. Просто и гениально. Записал, запомнил, нада делать так. Плюсанул бы комент, да плюсики кончились. Завтра.
budnikovsergey
20.06.2024 06:38+1
helix - вот единый стандарт для всего! 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, за что им большое спасибо.
arsvincere Автор
20.06.2024 06:38+1Да, home row. Мне кажется половина споров про Vim/другой кончились бы, если в начале задать вопрос - а ты в слепую печатаешь? Нормально в слепую, то есть полностью и десятью пальцами? Тогда можно посмотреть на Вим. Если нет - в нем нет практически никаких плюсов, они на 10 делятся если на клавиатуру смотреть. И лучше работать в любой IDE. Гораздо лучше.
Весь кайф и скорость от вима получаешь как раз при слепом наборе. И это такой кайф, что потом ради него готов заморочиться с докручиванием вима до приемлемой среды разработки. А если пойти еще на шаг дальше, в lua/vimscript то уже никакая IDE не нужна. Не то чтобы лучше хуже... просто 90% нужного прикручиваешь, и наслаждаешься hjkl yy dd p o O 0 ^ $... а surround, а макросы... да чтоб после этого вернуться на стрелочки с Ctrl+C / Ctrl+V... да только в страшном сне.
Dooez
20.06.2024 06:38+1А потом и в браузере и в оконном менеджере / композиторе те же горячие клавиши. И двигать руку на мышку становится совсем грустно.
arsvincere Автор
20.06.2024 06:38+1А потом сплит клавиатура с QMK и мышка начитает покрываться пылью.
budnikovsergey
20.06.2024 06:38+1я бы не был столь категоричен как истинный ситх из Звёздных Войн по поводу "или только полностью слепой 10 пальцевый метод или никакого vim". Я, со своими 30 годами в ИТ так и не научился за ненадобностью в полный слепой набор, что никак не мешает мне быстро набирать тексты и пользоваться всеми достоинствами vim/emacs, делая основные операции вслепую. С ним наверняка лучше, но и так потрясающе хорошо.
arsvincere Автор
20.06.2024 06:38+1Ок. Категоричность=False. Буду знать что и так бывает.
В какой то момент читая споры вокруг Вима, я подумал, что большая их часть вызвана отсутствием слепого набора у одного из спорящих. Я про себя точно знаю, дай мне вим до слепой печати - не понял бы фишку. А с десятипальцевым - любовь с первого клика по hjkl.
DieSlogan
20.06.2024 06:38Лично для меня VIM, эти когда надо по-быстрому что-то отредактировать, конфиги, какие-то разрозненеые исходники, etc.
Я не представляю, что на нём или на чём-то другом можно было бы реализовать весь функционал IDE. Ещё не стоит забывать, что в них есть редакторы GUI.
Так что, сравнение не корректно.
budnikovsergey
20.06.2024 06:38+1vim также очень удобен, если надо очень быстро обработать гигабайтный файл да с полуавтоматическим режимом с макросами. Макросы это прямо базовая опция для меня: я ими пользуюсь не задумываясь и в других редакторах практически сразу обнаруживаю их отсутствие.
а касательно механизмов IDE, то по сути language servers уже реализованные под vs code принесли почти все ide-функции во все редакторы, которые умеют в LSP. Отладку тоже через коммунальный DAP завозят. IDE просто это всё сами интегрируют, а в редакторах требуются телодвижения, но с каждым годом всё меньше
arsvincere Автор
20.06.2024 06:38Весь как правило и не реализовывают. Никто ведь не использует ВЕСЬ функционал IDE. Но по отдельности практически любую штуку можно прикрутить. Каждый докручивает на столько на сколько ему надо. Некоторые вещи легко и быстро прикручиваются. Некоторые костылями. С чем то придется смириться. В IDE тоже приходится смиряться. А в чем то можно получить 200% профита от кастомизации.
Я думаю здесь подходит такая метафора к миру авто: IDE это массовый рынок автобилей. Emacs и Vim это гаражный тюнинг, это то, что в серийке никогда никто не сделают. Слишком специфично. Но те кто возятся в гараже со своими машинами делая их архе-проходимыми, или архе-саунд сустем, или че там еще кому надо... Они как сидели в своем гараже так и будут. Их никогда не удовлетворит готовое, они хотят по своему и по другому.При этом хорошие водители и профессиональные водители бывают и там и там. И хорошие люди бывают и там и там.
Редактор гуи если он есть как утилита, в случае Qt, тоже можно прикрутить, скрипт написать который этот файл будет обрабатывать. Кого то такое прикручивание устраивает. Я день пострадал, а потом оказалось создавать Gui прямо в коде нифига не сложно, а через несколько месяцев даже быстрее стало получаться чем мышкой.
Сравнение не корректно. Но десятки тысяч людей пишут код в Emacs/Vim и не используют IDE вовсе, или используют как второстепенный вспомогательный инструмент. И да, таких меньше.
ay0ks
20.06.2024 06:38Можно конфиг hyprland с скриншотов? Выглядит похоже поэтому предположил что оно и есть.
arsvincere Автор
20.06.2024 06:38Да это hyprland. Конфиг не идеальный и не конца причесанный, в работе, и кейбиндинги там сумасшедшие - у меня сплит кастомный и там это легко нажимается. Ну если чем то поможет - все конфиги здесь https://github.com/arsvincere/dotfiles, будут вопросы пиши.
MagnumMalum
Скорее все же Emacs Lisp :)
arsvincere Автор
А, точняк, поправлю
Octabun
А Lua - приписать к Neovim не забыть.
arsvincere Автор
Так там же написано
Octabun
Уже да!