Helix has been trying to implement a plugins system for like 2 years that should tell you everything you need to know about its future prospects

A plugin system is much less of an issue when Helix has built-in functionality for most of what comes as plugins in Vim. That said integration with git or with code assistants/chat is something that is probably better done via plugins hence it is still on the roadmap.

But in my experience of ~10 months of Helix vs +20 years of Vim, the former is a much more pleasant and hassle-free experience, mostly because of it offering autocompletion, matching, fuzzy file picker, multiple cursors, LSP and go to definition, and other features with no or minimal configuration and the guarantee of stability and support (something that can not always be said when picking among the competing Vim plugins for same)

I tried to use it for multicursor editing which I tried to enable in Vim via plugins and it sucked, but being a console editor didn't help much. So I'm still using vi/vim for console editing because it's installed everywhere.

My first multicursor experience is with Helix (it goes to show what it means to have it built in instead of trying to find plugins for it) so it may be unsatisfactory for people who have used similar functionality in other editors. I use it in a very basic way - like change similar things on related lines - but it is a nice enough feature for me to mention it as part of the batteries included Helix experience. My main issue now that I am using Helix locally is that its keybindings are not well supported in other places I occasionally work (VSCode, Google Colab) and I keep having to mentally switch between vi/hx bindings. Not a hindrance enough to go back to vim though.

You may want to check helix.vim. it's a vim script that emulates helix

In fairness Helix provides a lot of functionality out of the box and features are gradually being added all the time. The lack of plugin system is not a problem for many people, and I’d rather they take their time and get it right. I certainly don’t think it’s the case that they’re “trying” and failing to implement plugins - it’s clearly going to happen when the time is right.

Big fan of helix and am in this camp. Used to have a bunch of plugins for neovim, but in Helix, honestly just haven't felt the need for anything besides what it comes with. It's a great editor.

I think you only miss (or at least I noticed this happened to me) a plugin system when you've engaged with the programmable side of your editor and then have to use one that isn't. I dont use/try to stay away from using (neo)vim plugins but I do like to pull out repetitive things into little snippets. I have things to manage my clipboard, pull up manpages in another editor tab when I put my cursor over a command and press a key in terminal mode, and a scattering of other quick useful tools. A lot of it's not reasonable to upstream, so it's a bit frustrating to me personally to use stuff that isn't programmable.

I've also toyed with emacs in the past and think I could like it for this reason, but ironically most other programming editors don't seem to be committed to the user's abilities as a programmer. I don't think it's nearly as easy/accessible/encouraged to program vscode, for instance. Self-documenting programmable programs like vim and emacs are so magical--- I hope they never go out of fashion.

Many helix users have their own fork to scratch that itch. I do too, and it's nice, but of course a little more maintenance than a set of scripts

I think a big missing piece with writing what you want in Rust and recompiling the editor to activate your changes is that you're not able to work with it _live_. That is, I can use the vim (or nvim or emacs) GUI/text processing/IO/etc facilities interactively as I'm writing my snippets to see if everything works the way I expected. I can send lines/expressions to the lua/elisp compiler running in the editor that I'm _currently using to write the program_ to change how it works, _on the fly_. It's an integrated programming experience in a way that very few things are--- it's not just about programmability, but this circular thing that goes on with editors that really fully commit to it.

And, oddly, they chose to do their own Scheme implementation for it. Not that I'm against Scheme in particular, but a lot of other people justifiably seem to be. It doesn't have the speed or learn-it-in-10-minutes of Lua (nvim) or the historical excuse of Elisp/Vimscript (emacs/vim) or the ecosystem of Typescript (vscode). Strange choice.

They already have Scheme based config files and I'd say it is simpler that Lua.

What are you talking about? It uses TOML for config files and some S-expressions for queries, which is actually a consequence of using tree sitter.

https://docs.helix-editor.com/configuration.html

I should have specified internal config files for the runtime queries that you mention. Those are .scm files.

I wouldn't really count that as editor config. Every editor with treesitter support will have configs for treesitter, for instance: https://github.com/nvim-treesitter/nvim-treesitter/blob/mast...

My comment is in the context of 'their own Scheme implementation'. Since they already handle some .scm files internally it's not that wild to pick Scheme over other languages as the base for plugins. It's a power user editor, Scheme should not scare them.

It can't really be simpler than Lua, come'on. Maybe if you already know Lisp, but for people who know C-like languages (Java, Javascript, C++) Lua should be much more "obvious".

scheme is a group of languages, it doesn’t have its speed. some implementations are very quick. and quick-to-learn, too.

helix looks like a passion project, so i thoroughly understand their wish to tend towards what they enjoy doing.

I mentioned speed because they're writing their own instead of using Chez or Gambit or something (which have taken a while to get into 'performant' territory). Writing and maintaining a fast(!) Scheme is hard. Having spent time with r5/r6/r7rs (many variants for the latter) and their quirks I'd honestly say Lua is simpler by a wide margin, but some of this is down to preference. The Lua execution model, if nothing else, is a lot easier to understand than call/cc for instance. And the language does force you to write things functionally, practically speaking. I'm also not a huge fan of syntactic macros. Also things like dynamic binding which, in fairness, are just SRFIs but end up being implemented by most Schemes. I do respect their willingness to do what's fun for them, though :) that's what it's all about.

Scheme makes sense to me (better semantics than Lua), but I'm surprised that they didn't choose an established and fast implementation like Guile.

Yeah, that was mostly my thinking. I like lisp!

I use Helix and don’t miss plugins.

If you're happy with Helix, do nothing, it you find yourself missing features, try this: https://lazyvim-ambitious-devs.phillips.codes/

I love Helix and used it a bit, but the lack of plugins (and thereby features) made me switch.

I also heard about Helix and have been curious about it, for the same reason. If I’m going to learn Vim keybindings, it’s because I want to move fast. Tweaking configuration files for an evening is the exact opposite of moving fast.

The idea that you constantly need to tweak your config files in vim/neovim is a bizarre myth that seems to have sprung up because vim is so flexible that some people love messing about with config. You can just copy something like vim-sensible to give sensible defaults and get going - you absolutely don't have to do a bunch of tinkering. I have used vim and then neovim for 24 years now and most of my config customization I did more than 15 years ago when I decided to add a bunch of extra keybindings.

I very occasionally will add a plugin or tweak something (eg if I want a new snippet or something) but it's really not necessary to have a big complex config and I would say I spend well under 5 minutes per year on config.

I really wanted to like helix but there are a few really fundamental things that are really crucial to most of my workflows that were just missing (eg reflow text) when I tried it.

Agreed. I've been using (n)vim for roughly 8 years now and only touch my config to put in bits of Lua I've hacked together to make my life slightly easier (~10 minutes every few months? I just do it as-needed). I use 5-6 plugins total. I think the most vocal users are probably responsible for the impression of constant churn, because they've got fancy tricked out configs loaded with alpha-quality plugins and probably do need to constantly update it. Nothing against doing that, but it need not be that way!

Yeah, there definitely seems to be quite a bit of churn for people who adopt the newest plugins, and I think that can lead to the impression that Vim and Neovim require constant configuration maintenance. I don’t think the churn is necessarily bad for people interested in spending a lot of time on their configuration because it means there’s a lot of experimentation, which eventually makes its way to the whole community.

Just use https://astronvim.com/. I haven't touched my config for more than a month. With astronvim community, other people do the hard work.

I also tried the "pure" config from scratch way but its just way too much work to maintain, esp if you want all the goodies. Also, not an expert in Lua so my config sucked. Simply better to use an existing, well-maintained neovim distro. I tried all of them and liked astronvim the best.

Give Helix a try. If you happen not to depend intensely on a few big IDE features it's missing, it's wonderful.