5 ms·

Release size is ridiculous, and they refuse to do anything about it https://github.com/helix-editor/helix/issues/6187 https://github.com/helix-editor/helix/iss

by 38 3y ago

Release size is ridiculous, and they refuse to do anything about it https://github.com/helix-editor/helix/issues/6187 https://github.com/helix-editor/helix/issues/6187

kinghajj 3y ago
$ du -hs /opt/homebrew/Cellar/helix/ 139M /opt/homebrew/Cellar/helix/ That doesn't seem unreasonable to me.
- beanjuiceII 3y ago
  is helix built on electron?
  - cornstalks 3y ago
    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.
    - beanjuiceII 3y ago
      oh at that binary size i kind of assumed it was
- wholesomepotato 3y ago
  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.
  - BaculumMeumEst 3y ago
    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.
    - eviks 3y ago
      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
      - BaculumMeumEst 3y ago
        for tree-sitter? what button do you press in neovim or emacs?
        caerphoto 3y ago
        :TSInstall <language>
      - bobbyskelton41 3y ago
        See https://github.com/helix-editor/helix/issues/1970 https://github.com/helix-editor/helix/issues/1970 but yeah, other editors do the same thing as Helix here.
  - eviks 3y ago
    > 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)
    - fsociety 3y ago
James_K 3y ago
Wow! A hundred megabytes? That'll be a huge struggle for my 2002 Never Obsolete(TM) eMachines PC with 15GB hard drive.
deleted 3y ago
[deleted]
dcre 3y ago
Sounds like the very few people who are concerned about this can easily get a smaller install.
deleted 3y ago
[deleted]
shepherdjerred 3y ago
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.
- bobbyskelton41 3y ago
  Only case I could reasonably see an argument for is on low-end systems, but Helix isn't targeting that anyway.
  - yonatan8070 3y ago
    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)
asoneth 3y ago
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.
Quentincestino 3y ago
Well they gave reasons about it and a solution which is a link to a related documentation page, they handled it really well.

by 38 3y ago

Release size is ridiculous, and they refuse to do anything about it https://github.com/helix-editor/helix/issues/6187 https://github.com/helix-editor/helix/issues/6187

kinghajj 3y ago

$ du -hs /opt/homebrew/Cellar/helix/ 139M /opt/homebrew/Cellar/helix/ That doesn't seem unreasonable to me.

beanjuiceII 3y ago
is helix built on electron?
- cornstalks 3y ago
  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.
  - beanjuiceII 3y ago
    oh at that binary size i kind of assumed it was
wholesomepotato 3y ago
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.
- BaculumMeumEst 3y ago
  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.
  - eviks 3y ago
    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
    - BaculumMeumEst 3y ago
      for tree-sitter? what button do you press in neovim or emacs?
      - caerphoto 3y ago
        :TSInstall <language>
    - bobbyskelton41 3y ago
      See https://github.com/helix-editor/helix/issues/1970 https://github.com/helix-editor/helix/issues/1970 but yeah, other editors do the same thing as Helix here.
- eviks 3y ago
  > 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)
  - fsociety 3y ago

James_K 3y ago

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

deleted 3y ago

[deleted]

dcre 3y ago

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

deleted 3y ago

[deleted]

shepherdjerred 3y ago

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.

bobbyskelton41 3y ago
Only case I could reasonably see an argument for is on low-end systems, but Helix isn't targeting that anyway.
- yonatan8070 3y ago
  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)

asoneth 3y ago

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.

Quentincestino 3y ago

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