I keep meaning to get back into Helix, I'm super close to setting up an "vi=hx" alias. I had Claude make me a cheat sheet, but I haven't gone over it, here it is if it helps anyone: https://box.linsomniac.com/HelixCheatSheet.pdf
Worth mentioning that while this was very nice work by a Helix enthusiast, it was proposed as a replacement for the official docs and mostly rejected, and for good reasons IMO. An instructive discussion!
It's rarely a good idea to do a bunch of work on a big change to an open source project in a direction that has not been validated by the maintainers. Or at least, if you do, do it for your own education and don't have high expectations that it will be merged. The contributor in question had a very good attitude about it.
> - The homepage right now is extremely lightweight and uses next to no javascript. The new design just looks like the same generic Starlight template
I'm not sure we want to use a javascript framework. While it provides a lot of features, bitrot in the javascript ecosystem happens at a very fast pace (and pulls in thousands of dependencies). I have sites written both in gatsby and vuepress and between major version breaking changes and deprecations as frameworks cycle, it's a ton of work to keep up (e.g. vuepress -> vitepress/vuepress v2). Even mdbook upgrades have been a pain since we need to merge down theme updates. I'd prefer to see something simple, e.g. (https://docs.racket-lang.org/guide/). What do we do in five years when Starlight is deprecated by another framework, and Astro is several major releases ahead, with breaking changes?
This is a very valid point, and a mark of a mature developer who has been bitten by frontend churn, and wants something stable, simple, reliable, and predictable.
Currently, I'm using VS Code with Vim keybindings (through the Neovim plugin). My workflow (C/C++/Rust) involves multiple panes open, using the lldb debugger, goto/peek definitions, CMake integration w/ active target compilation on Ctrl+Shift+B, clang format on save, LLM-powered tab-autocomplete, and IntelliSense powered by `compile_commands.json`.
Is switching to Helix worth it? Can I get more-or-less equivalent functionality with Helix?
I really would love to move to helix but they can be… stubborn about what gets into the core. And if you start having to go to a plugin (which isn’t even possible last I looked) to get table stakes features in, it kind of defeats the purpose of a modern batteries included modal editor. But it’s still a cool thing I’m glad exists.
I'd prefer a more honest tutorial. Who is this editor for? and show the kinds of problems it was designed to solve, nobody makes generalist text editors anymore and nobody needs a generalist editor.
Like are you really trying to convince poets to use this? Of course not, this tutorial relies on some domain expert seeing it and mapping the functionality show in the examples to their problem.
Also the utility of these kinds of editors goes way down when you aren't doing many quick edits of arbitrary files ( which points to a larger workflow problem though perhaps unavoidable for some )
I guess Helix is made to have appeal for Vim users. At the same time, times change and usually people expect less step learning curve (including myself!).
I would really appreciate visible-by-default hints, alike in Linear.app. Then, learning shortcuts becomes organic, rather one need to keep tutorial open, or have a cheatsheet of some sorts.
Many complain here about the helix maintainers pace and PR rejection rate. I embrace it. It’s opinionated software developed in the open and you can fork any time.
I prefer this model of strict high quality governance and a “no” as default to keep their vision clear.
Can someone explain to me the concept being Helix? I never got it.
From a casual reading, it looks like vim with no text objects and no support for ed commands so basically vim stripped of two of the main things that makes it good.
I understand it wants to be a more rational successor but while I got how sam tried to achieve that by breaking the limit on line editing, making clever use of mouse selections and switching ed for a new non line limited syntax (how I wish ssam had replaced sed), I don’t get the Helix value proposition.
I used vim for about twenty years, and I'm mostly happy having moved from neovim to helix.
The main thing I miss in helix is solid debugging support and slime style repl support - but I never had that working in vim.
The other thing I'm missing in ruby is "go-to definition" automatically working with dependencies, allowing to go to the source code by "opening" gems - tpope has/had some amazing stuff for ruby development with vim.
That said - I like how helix is more discoverable (pop up context menu), has sane/great defaults and out of the box experience - and I like the select-apply or subject-verb and multi cursor workflow better than vim verb-subject flow.
I recommend trying to go through the tutorial and see if fits.
I'm hoping plugin support will open the door to some improved go-to-definiton support - I'd love to be able to go "up" to edit/view dependencies be that libc source code, java, rust crates etc.
Can any Helix users share how the muscle memory from vim is working out? I’d really like to give it a go but I’m worried I’ll pollute my memory of basic vim commands. I’m bad enough remembering cut/copy/paste keyboard shortcuts in different OS/applications.
Does Helix have no way to go back to the last editing position when re-opening a file? Similar to: '" in vim? That is going to be a deal-breaker for me. One reason I use vim over many other options is that I jump in and out of files a lot, having to find my last position in many cases is a chore.
18 comments
[ 3.3 ms ] story [ 41.4 ms ] threadhttps://github.com/helix-editor/helix/pull/12127#issuecommen...
It's rarely a good idea to do a bunch of work on a big change to an open source project in a direction that has not been validated by the maintainers. Or at least, if you do, do it for your own education and don't have high expectations that it will be merged. The contributor in question had a very good attitude about it.
This is a very valid point, and a mark of a mature developer who has been bitten by frontend churn, and wants something stable, simple, reliable, and predictable.
https://github.com/helix-editor/helix/issues/2059
Is switching to Helix worth it? Can I get more-or-less equivalent functionality with Helix?
Also the utility of these kinds of editors goes way down when you aren't doing many quick edits of arbitrary files ( which points to a larger workflow problem though perhaps unavoidable for some )
I would really appreciate visible-by-default hints, alike in Linear.app. Then, learning shortcuts becomes organic, rather one need to keep tutorial open, or have a cheatsheet of some sorts.
From a casual reading, it looks like vim with no text objects and no support for ed commands so basically vim stripped of two of the main things that makes it good.
I understand it wants to be a more rational successor but while I got how sam tried to achieve that by breaking the limit on line editing, making clever use of mouse selections and switching ed for a new non line limited syntax (how I wish ssam had replaced sed), I don’t get the Helix value proposition.
The main thing I miss in helix is solid debugging support and slime style repl support - but I never had that working in vim.
The other thing I'm missing in ruby is "go-to definition" automatically working with dependencies, allowing to go to the source code by "opening" gems - tpope has/had some amazing stuff for ruby development with vim.
That said - I like how helix is more discoverable (pop up context menu), has sane/great defaults and out of the box experience - and I like the select-apply or subject-verb and multi cursor workflow better than vim verb-subject flow.
I recommend trying to go through the tutorial and see if fits.
I'm hoping plugin support will open the door to some improved go-to-definiton support - I'd love to be able to go "up" to edit/view dependencies be that libc source code, java, rust crates etc.