Well, thanks for your article!
There is also now a file explorer under <space>+e (little e for starting at workspace root, capital E for starting in the buffer’s directory).
I should definitely use the buffer picker more, at the moment I use the gn/gb commands and it mostly works, but then I suddenly end up with too many open buffers and it's hard to figure out where I need to go again.
There's a file explorer now!
Just tried it now, it's not quite a file tree but it's almost as good.
I have been checking in with helix every 6 months to see if the plugin system was finalised so I could use a real file picker and actually navigate through and explore the files in my project.
That one thing has held me back from using helix. I'll probably give it another go for tiny projects where I don't need any plugins (e.g. in-line error annotations through LSPs, indent rainbow, in-editor color pickers, line sorters, etc...).
OTOH one could build distrib similar to spacemacs/lazyvim, then you could just start with that, and once you find one particular plugin annoying or lacking, you could swap it for something else, at least theoretically (I've never used those personally, so I don't know how hard it is in practive). Not so much with all the eclipses and jetbranses of the world.
I of course quickly just googled it myself and found the page, and so afterward I went to the source of the blog post and searched for the URL to confirm that it wasn't actually linked to anywhere. Turns out that about three quarters of the way down, in the "Key Bindings" section, there is a link to the Helix keymappings documentation page, which appears to be the closest thing to a direct homepage link.
Anyways, no nefarious intent being implied of course, I just found it sort of interesting. I am pretty certain it just got accidentally left out, or maybe the project didn't have a homepage back in December of 2024 when this was originally written? Although the github page isn't directly linked either (only one specific issue in the github tracker).
Oh, and here's a link to their page: https://helix-editor.com/
And github page: https://github.com/helix-editor/
Maybe in certain anti-intellectual crowds. But not here.
Reddit behavior shouldn't restrict you elsewhere.
It felt too inflexible (not just from lack of plugins), and there were numerous annoyances like save always changing file ownership to the current user, the buffer not reloading when a file is changed externally, no way to highlight (only) trailing spaces, dot repeat doesn’t always work (because the motion/selection comes first) etc.
But mostly I much prefer the way Vim does selection and motions and actions etc.
I also don’t like bulk search and replace in helix as it’s based on selection and replace.
Other than that, I find it easier to stick to helix than to vim!
I don't chase shiny new tools nor do I aspire to replace my toolchain with things just because they're built in Rust. I've used vim/neovim ~15 years. I don't use many TUIs (I actually can't think of any others besides my editor), but my development workflow is entirely terminal-based. I use native splits/tabs in my terminal emulator instead of screen/tmux/zellij. I spent years balancing having a minimal vim configuration that included plugins (but not compiled ones so that it was portable) but didn't include hundreds or thousands of lines in my vimrc. I'm excited to see how neovim is making progress with native LSP, but for years getting it working meant continuously tweaking vimscript/lua code or adopting a massive plugin written in TypeScript.
When I first tried Helix, LSP just worked; it read what was on the $PATH and used it. That's perfect because it solves for another source of annoyance: having different versions of tools for different projects. As the author notes, there are some LSP features that don't work with Helix, but whenever I dig into the issues, I almost always come to the conclusion that the issue lies in LSP being a VSCode monoculture rather than a deficiency in Helix itself. However, using the right version of a tool for a specific project and not spending any time configuring LSP servers were the top problems plaguing my usage of neovim.
If you're a vim user and you're concerned about muscle memory, by the first week I was proficient and by two weeks, Helix was the default in my brain.
I was a huge supporter of neovim -- I actually was submitting patches to the vim mailing list to fix vim on a beta version of macOS at the time taruda posted his original async patches that kicked everything off. If you had asked me the day before I tried Helix that you could reimplement a vim-like codebase from scratch well enough to abandon the original vim code, I would've agreed with you.
Lua and native LSP supports were introduced at the same time. Not getting how you would tweak Lua code to get LSPs to work before Neovim had native support.
> LSP just worked; it read what was on the $PATH and used it.
This is how Neovim loads LSPs as well. You don't need a plugin to download and manage LSPs. You can just install them externally yourself.
> not spending any time configuring LSP servers were the top problems plaguing my usage of neovim.
It's been years since it's just a few lines to enable LSPs with the config shipped in nvim-lspconfig if you don't want to override any server-specific settings. And even then its still pretty easy.
I will give you that Neovim should ship with nvim-lspconfig and just load a compatible LS if its already in the PATH. Enabling each server one wants to use is annoying. But again, it's just a few lines (and I'm pretty sure a lot of people wage war if they did either of those things because "bloat").
I'd explicitly configure which servers were triggered which filetypes (aka autocmd and when I first started doing this, the binding for autocmd didn't even exist in lua yet) and have to bind lsp functions to keybindings across languages. FWIW, I have no idea what I would've done in vimscript, lua is a godsend with tables, loops, and lambdas. At this point in time, I was an early adopter neovim's built-in LSP and everyone else was recommending coc.nvim.
But the juxtaposition at the time was that Helix ships `languages.toml` that includes all of this already out of the box. You can override it, if you want, but actually all I wanted was cohesive keybindings for basic LSP functions.
What's the state of the world for neovim today?
Hi, just browsing. Where are you usually having issues with LSP these days? Is it a vim issue specifically, or related to your setup?
I believe LSP works across a multitude of editors by now.
I build HEAD from source using brew, so I'm not actually sure if the directory explorer is in a stable release.
I really recommend it if you find Vim motions unintuitive and want some of the basic features of IDEs like VSCode.
My biggest gripes: - No plugin system (yet). - Configuration documentation is not the best. - Hasn't reached enough popularity to where other apps have "Helix mode" like how a bunch of apps have "vim mode". I find myself wanting to do Helix motions in other apps.
That said, I'm convinced people praising Helix because they "don't have to install 60 plugins" or "constantly keep tweaking their config" will just start blaming Helix when it gets plugin support and if it gets a dynamic configuration language.
You don't have to install 60 plugins (I have 6) and you don't have to keep tweaking your config (I haven't touched core parts of my config in years, just like to play around with logic sometimes). It's not a feature to not support these things just because you lack the self control to stop playing with your editor and focus on your work.
For example C is not change line as expected but multi line edit mode (something not very useful with vim keybind) ...
But even with these quirks it's close enough to be usable and enjoy all the goodies of helix.
> Scheme/Lisp should not be forced onto the user. It's error-prone and harder to read by humans, compared to Rust/TOML/Lua/...
I get the argument of preferring TOML over a Turing-complete language for configuration, but to claim that Rust is easier to read than Scheme, or that Lua is less error-prone, is... interesting, to say the least.
I saw similar comments in the linked issue that tracks the proposal. I think people object more to functional programming and S-expressions than to Scheme itself, which is a shame. There's a lot to be gained and learned from Lisps once you get over that initial reaction.
Which text editor is unresponsive because of heavy rendering?? And that's the only potential benefit the author has identified
In Neovim at least one reason for why it might be slow is that the particular treesitter implementation for the syntax you're using isn't very optimized?
But it depends a lot on what kind of type you're pasting exactly and your setup.
It would be benefit a lot from some funding, but it's hard to find funding for a TUI editor.
It insane how fast Zed is moving in terms of development, on the other hand, I'm still waiting for some features in helix for more than 2 years. Helix devs have their own vision and reject a lot of attempts/PRs to make it better.
Regarding slow development, I saw a thread on reddit today https://old.reddit.com/r/HelixEditor/s/zn0xiSs9pp
While I’m looking forward to the plugin system for a few nice to have tweaks, and amrunning the dev branch alongside the main build to check it out, there’s nothing really essential missing to me.
I appreciate that the maintainers aren’t trying to compete with vim or emacs for features or be all things to all people, aren’t that they don’t prioritise growing the number of users over keeping true to their vision for the editor.
Helix is all the better for its slow, considered development as far as I’m concerned.
- global replace
- multiline search in files
- small terminal with toggle (for quick commands)
- Recent LSP protocol features that would allow using inline copilot suggestions
- better file manager where I can create, remove, rename files
- an ability to bind x and xx (double) keypress at the same time
- git blame
- a better ability to run programs on top of helix (lazygit, for example, the same way people use it in neovim without closing it)
The original link only works for logged in reddit users
I feel your pain, but i support their focus here. Not only does it help prevent feature soup but at the end of the day they're the ones that have to support all these things.
As always, anyone is free to fork it. That sounds short but imo true nonetheless. Especially if the feature is small enough that the fork is just maintaining a patch on the head.
Regardless, plugins are being worked on so in time hopefully it's less of an issue.
> It insane how fast Zed is moving in terms of development,
I imagine funding and bodies helps a lot on this front.
It would be cool if it got more token-based movement/selection/replacement features, since it already has good tree-sitter integration.
I'm finding that spacemacs seems a bit easier to use, striking a nice balance between vim style editing and emacs style everything else, making it easy to slowly build up memory instead of overwhelming me with keybinds and configuration details.
If that's been added I'd take another look.
has worked well for me, even if the reflow behaviour itself is sometimes frustrating
