Hacker News Reader

Comment by jdeaton | Hacker News Reader

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

View on HN

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.

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.

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

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".

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.

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.

Reply on news.ycombinator.com