Release size is ridiculous, and they refuse to do anything about it
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.
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)
$ du -hs /opt/homebrew/Cellar/helix/
139M /opt/homebrew/Cellar/helix/
> 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.
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.
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.
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)