Helix 23.10 Highlights | Hacker News Reader

Helix 23.10 Highlights

helix-editor.com

158 pointstodsacerdoti66 comments

Smart tab is so… smart. I really admire how people keep coming up with creative features that immediately make sense and become table stakes right away. This applies to editors across the board. Couldn’t imagine living without command palette in VSCode, for example. Smart tab looks like something I’d be using constantly. Does anyone have experience switching from VSCode to Helix? I’m using a ton of different features of VSCode and for that reason keep thinking switching off it is hard. Debugging, keyboard shortcuts, command palette, multi cursor, all sorts of different languages, all sorts of different extensions (GitHub actions completions and checks, line wrapping that’s Markdown-aware, …), … it just does it all! The core downside is the reason I’m looking to switch: performance.

nowadays i generally point $editor and VS code at whatever i'm working on and hop between them when i feel like it

I don't have experience switching vscode to helix, but here are my 5ct regarding your concerns:

Debugging works for some languages, though it's not comparable to IDEs like vscode. It's also marked as experimental https://docs.helix-editor.com/keymap.html?highlight=Debug#sp...

Helix also has multi cursor, but probably not as intuitive when you are coming from vscode.

Helix supports many languages without configuration, except installing the language server.

GitHub actions completions should probably work through this json schema with a language server, at least I didn't configure anything and when I edit docker compose files, I have autocompletion and validation. https://github.com/SchemaStore/schemastore/blob/master/src/s...

Command palette - i don't know what you are using it for, but nearly every modal editor like (neo)vi(m) has a "command line" when pressing ':' where you can run helix commands https://docs.helix-editor.com/commands.html

With helix you can get most of the vscode features, except debugging, extensions and file management, though most of the extensions can be replaced with some other tools (depends heavily on what the extension does, can't be generalized). A plugin system is currently on the roadmap and is being worked on, but I don't think anyone could tell you when it's going to be ready.

There is a tasty looking proposal for a debugger overhaul https://github.com/helix-editor/helix/issues/5950.

`space-?` brings up the command palette in Helix.

> Command palette - i don't know what you are using it for

Discovery!

No doubt, command mode in vim et al. is probably the most powerful thing. However, as with anything shell, it all has to be laid out a priori.

Command palettes are fuzzy-finding, allowing reckless abandon for hacking into them. Single-letter commands have to be remembered, productivity suffers. Fuzzy is pretty much just as fast and grows with the user dynamically. I'll look into whether Helix has that.

Ah okay, then you want Space-? It fuzzy finds alle the available commands and shows you the keybindings next to it, so you can even search for keybindings.

> I really admire how people keep coming up with creative features that immediately make sense and become table stakes right away. (…) Couldn’t imagine living without command palette in VSCode, for example.

Command Palette isn’t a VSCode invention. Sublime Text already had it.

Related. Others?

Even more hindsight on Vim, Helix and Kakoune - https://news.ycombinator.com/item?id=36427267 - June 2023 (115 comments)

More hindsight on Vim, helix and kakoune - https://news.ycombinator.com/item?id=36066347 - May 2023 (1 comment)

Helix 23.03 - https://news.ycombinator.com/item?id=35384691 - March 2023 (93 comments)

Helix 22.12 - https://news.ycombinator.com/item?id=33890655 - Dec 2022 (40 comments)

Helix: Post-Modern Text Editor - https://news.ycombinator.com/item?id=33494840 - Nov 2022 (166 comments)

Helix: A Neovim inspired editor, written in Rust - https://news.ycombinator.com/item?id=33147270 - Oct 2022 (306 comments)

Helix: A post-modern text editor - https://news.ycombinator.com/item?id=33039390 - Sept 2022 (2 comments)

Helix, Terminal Modal Editor - https://news.ycombinator.com/item?id=30847041 - March 2022 (2 comments)

Helix 0.5 released (Kakoune like terminal text editor) - https://news.ycombinator.com/item?id=29043889 - Oct 2021 (2 comments)

Helix: a post-modern modal text editor - https://news.ycombinator.com/item?id=27358479 - June 2021 (365 comments)

I've been using Helix full time, professionally as a Rust/Golang engineer and it has been great. It took some getting used to not having a file explorer. But now I think I am better for it.

These looks to be fantastic updates, I especially dig the diagnostics (if that is part of the release as well).

what's your workflow like for situations where you need to poke around in an unfamiliar directory and open files in helix?

I mainly use ranger, or some conveniece scripts I've built around ripgrep, ripgrep replace and fd. When i find the file i want I either open it directly to do a small chance or use the fuzzy search in my long running session to open the file.

The only thing I haven't nailed yet is creating files in deeply nested directories.

In general most of the things I used in nvim have now moved back to the terminal which has its pros and cons.

you could try to use ranger or a similar terminal filemanager. it's basically like nvimtree or nerdtree

I use broot :)

There are a lot of nice tui s for this, but saidly helix does not support opening new files into an existing session :(

this is the big problem. I hope there's a fix for it someday.

Open the root in helix, use the fuzzy file finder (space-f) for looking up by name path, or global search (space-/) for finding by content.

I also use Helix full time, I really like it, especially the multi cursor features. I was a neovim user before, but I did not enjoy configuring my editor all the time. I like Helix config defaults, LSP works out of the box, the commands are a bit longer to type, but more logical. I cannot work without a file tree, I settled with the tree explorer fork[1] and I'm happy with it.

[1] https://github.com/helix-editor/helix/pull/5768

Yeah I've considered it. For now ranger in a pop up term works nice enough for me. Ranger is a bit slow so I should move to lf or some other alternative.

Check out joshuto - https://github.com/kamiyaa/joshuto

also written in Rust

so is yazi ;) https://github.com/sxyazi/yazi

How long did it take you to reverse your movement->action muscle memory?

I just started using a modal editor this summer. Started with vim, progressed to neovim and landed on helix. I love the batteries included features and minimal configuration. Using a scripting language (Lua) for configuration was bit too much overhead for me to get started with neovim. I felt immediately productive using helix. I also prefer the selection->action model as well as native multi-cursor support. I would definitely recommend it to anyone looking to start using a modal editor. Experienced vim users might find it irritating to adjust to helix. In my opinion, it has the best out-of-the-box experience of anything I have tried so far. Though I will admit that Intellij is paying the bills for now and I use helix for all my school work. I hope to get helix to be my daily driver eventually.

As an avid neovim user, I must say helix felt right at home. There are differences, but most of the basics are the same. I felt immediately productive. Great job. (Neo)vim compatibility, makes this much more approachable for those familiar with vim-style modal editing.

Very stable so far, been using these features since a while, as I always compiled the version from the master branch.

Never could stick to any modal editor like (neo)vi(m), but helix was so easy to get into, and you don't even need to configure anything.

My main editor and "IDE" since >1 year, can only recommend.

I like Helix, but I get annoyed by a really tiny thing. When you hold the left and right arrow keys, the cursor will go to the prev or next line once it reaches the beginning or end of the current one.

Which is completely fine behavior, to be clear. I just can’t deal with it. vim does not do this.

Which is 100% intended, as also in (neo)vim commands like f, t, etc only operate on the current line, while in helix they actually work and take you to that character, no matter if it’s in the same line or 400 lines later

The tabbing feature looks nice. AST-based code navigation has been a huge boon to productivity.

My hope is that Helix gets around making /**/-style block comments more ergonomic. It's one of the reasons I'm still using nvim for writing C.

Fantastic updates. The multiple LSP was the main missing feature but now this makes Helix ready for all use cases imo. It is super fast and performance unlike the disastrous performance of vs code.

I still miss a file explorer like telescope in the nvim world. I was a bit sad to hear that is now blocked by plugins being added: https://github.com/helix-editor/helix/pull/5768#issuecomment...

It's still planned. That particular implementation just wasn't desirable.

True, but still. Iterations of the PR have been ongoing for months. Hope it lands sooner than later

I wonder how their fuzzy finder fares against fzf-vim in the livegrep scenario

I used Helix for a while due to its support for LSP out-of-the-box, which my Vim config at the time couldn't live up to. I switched back to NeoVim after finding LunarVim[1] which had everything I was trying to get setup in my own config.

[1] https://www.lunarvim.org/

I’m a big fan of LunarVim, but handling large files out-of-the-box is not a great experience. Observed in both lvim, and neovim with my own config. I’ve found myself leaning on helix in those cases - quicker than screwing with either config, or running vim -u NONE.

LunarVim is my daily driver, but Helix is screaming fast compared to it in many cases.

Release size is ridiculous, and they refuse to do anything about it

https://github.com/helix-editor/helix/issues/6187

    $ du -hs /opt/homebrew/Cellar/helix/
    139M /opt/homebrew/Cellar/helix/

That doesn't seem unreasonable to me.

is helix built on electron?

From the homepage:

> Built in Rust, for the terminal

> No Electron. No VimScript. No JavaScript. Use it over ssh, tmux, or a plain terminal. Your laptop battery life will thank you.

oh at that binary size i kind of assumed it was

Helix the binary is around 24M on my system.

Helix uses tree-sitter for rich language support. Tree-sitter's grammars are binary dynamic libraries compiled from some source code. Depending on how they are written and how complex they are, they can be anywhere from few KB to many MB. There's like 150 of them ATM. It's not exactly Helix's fault that some are unreasonably large.

Tree-sitter is a large part of what makes Helix editing experience so good. Unlike regex-based parsing that (Neo)Vim uses (or at least it used to, last time I looked) which often break in weird ways and make the editor very sluggish sometimes.

Helix official releases ship with all the supported grammars pre-compiled to give a convenient fully-featured user experience. It's entirely possible to package Helix without grammars, then compile selected few and so on. Some distros and individual users do so. Grammars compiled by distros / package managers can be re-used between other programs using Tree-Sitter, so could be packages as additional (possibly optional) dependencies.

Honestly 140MB for such a good editor is totally fine with me, but people who can't live with it have plenty of routes to take, like improving Helix integration in their package manager of choice.

helix is the only editor that gets this right. shipping pre-compiled grammars should be the default for any editor leveraging tree-sitter, from a user experience perspective and for stability.

the fact that more popular editors expect you to check them out yourself and compile from master and then wire everything up yourself and "hopefully there's no incompatibility today!" is insane. we should really have higher standards than that.

More popular editors expect you to click a button when you open a file in a given language to install language support, nothing insane about that, easy and also no waste

for tree-sitter? what button do you press in neovim or emacs?

:TSInstall <language>

See https://github.com/helix-editor/helix/issues/1970 but yeah, other editors do the same thing as Helix here.

> It's not exactly Helix's fault that some are unreasonably large.

But it is Helix's fault for including them all even if 99% of the users will never use them (like the linked Verilog issue illustrates)

What do you expect for an editor that promises all batteries are included.

I'd expect it not to include dead batteries

Neovim... regex parsing... uh?

https://neovim.io/doc/user/treesitter.html

Wow! A hundred megabytes? That'll be a huge struggle for my 2002 Never Obsolete(TM) eMachines PC with 15GB hard drive.

Sounds like the very few people who are concerned about this can easily get a smaller install.

Genuine question: why does storage size on disk matter, especially when we're talking about ~100MB?

I can understand complaining about RAM usage because there is some performance impact there, but I have truly no clue why anyone cares about storage usage.

Other than the initial download time, I don't see how it would have any impact on the end-user.

Of course, it would be _nice_ to get that package size down if it's easy, but to me it seems unnecessary to prioritize.

Only case I could reasonably see an argument for is on low-end systems, but Helix isn't targeting that anyway.

Even for low-end system, 100MB isn't much.

For my Arch system I have a 60GB (BTRFS, compressed) root partition, and I install packages very liberally, I have KDE Plasma, KiCAD (with the 3D library), FreeCAD (though I don't use it) and quite a few other packages and haven't run out of space yet (currently I'm using 79GB uncompressed, 55GB on-disk)

I'm actually impressed at how nicely they answered the request by explaining why it's so large, pointing out a few workarounds, explaining why it's not currently a priority given their vision, and leaving the door open for potential future improvements. It would have been a lot simpler and less hassle to simply ignore it or close it with minimal discussion.

Well they gave reasons about it and a solution which is a link to a related documentation page, they handled it really well.

Reply on news.ycombinator.com