[HN Gopher] Beginner-friendly, unofficial documentation for Heli...
___________________________________________________________________
Beginner-friendly, unofficial documentation for Helix text editor
Author : Curiositry
Score : 64 points
Date : 2025-11-01 19:33 UTC (3 hours ago)
(HTM) web link (helix-editor.vercel.app)
(TXT) w3m dump (helix-editor.vercel.app)
| linsomniac wrote:
| 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
| hit8run wrote:
| Your cheatsheet has some hallucinations in there. For example
| there is no :git command
|
| you can do "! git status" etc
|
| There is some other integration for git like SPACE + g to see
| file changes for example
| abuani wrote:
| Heh, "vi=hx" was exactly how I forced myself to spend a week in
| helix. Just go for it
| cadamsdotcom wrote:
| Great to see so much Helix content on HN lately. Excited to give
| it a try!
| abuani wrote:
| It's the first editor since probably sublime text that I've
| genuinely enjoyed. Useful without any configuration, and very
| easy to get a productive environment.
|
| There's a few rough edges that I'm trying to work through. I've
| been able to solve my "open in X" like key bindings. But I have
| yet to get things like "run test for current method". That's
| probably the biggest pain point I've had so far
| shoy wrote:
| A while ago I made a dense cheat sheet for Helix. It's a touch
| out of date, but still possibly useful.
| https://github.com/stevenhoy/helix-cheat-sheet
| hit8run wrote:
| Hey nice to have you here. I found your cheatsheet and printed
| it out a while ago :D
| shoy wrote:
| I'm glad you liked it. I keep meaning to update it (work and
| life get in the way), if the demand is there.
|
| (edited for grammar)
| dcre wrote:
| 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!
|
| https://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.
| alphazard wrote:
| > 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.
|
| While this is good advice in general, it doesn't tell the whole
| story in the case of this specific project. The helix
| maintainers have a track record of giving very slow "no"s and
| wasting contributor time. They encourage contributors to fix
| various odds and ends, until the PR has been nit picked to
| death, and then finally the concept is rejected. Totally
| backwards, good project leadership would front-load the
| conceptual yay-or-nay before reviewing any actual code.
| lexoj wrote:
| I keep trying Helix but just got hit by wq freeze issue, opened
| since 2022, so I wonder sometimes if its ready.
|
| https://github.com/helix-editor/helix/issues/2059
| dlivingston wrote:
| 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?
| Crowberry wrote:
| The debugger in helix was extremely barebones last I tried, LLM
| integration can only be made available through custom language
| servers since they do not support plugins yet.
|
| If you are interested in making a move to a terminal editor I
| would instead look to neovim until helix matures a bit more
| suby wrote:
| I don't think Helix can currently match the C++ experience you
| get with VS Code.
|
| * Debugging is rough. There's experimental DAP support, but it
| isn't ready to be used. I was able to set breakpoints and step
| through the code, but the UI for exploring variables / state
| while paused felt missing or was unintuitive enough that I
| couldn't figure it out. I use CLion for debugging.
|
| * Goto definition works with clangd as long as your CMake setup
| outputs compile_commands.json, which you already do.
|
| * Renaming symbols (variables / functions) via clangd works
| fine.
|
| * Intellisense is decent, but I had to tweak clangd settings.
| By default, it would stop returning results after scanning a
| certain number of symbols, so some valid functions just didn't
| show up. I was using Helix for a few days before realizing this
| problem, it isn't obvious that you are getting an artificially
| constrained filtered view of your symbols via default clangd.
| Maybe this is a distro packaging issue though?
|
| * The order of intellisense completions is not great. CLion is
| smart about surfacing relevant suggestions first. In Helix +
| clangd, I often get obscure symbols that obviously have nothing
| to do with my project or context. It's not the worst thing, but
| it is mildly annoying and noticeable.
|
| * "go to error" doesn't surface errors in files that aren't
| open. In Helix, space D brings up workspace diagnostics, but it
| only shows errors for compilation units already open. This
| appears to be a clangd issue, as space D in other languages
| will show all project errors. CLion does not suffer from this
| problem.
|
| * I think you can get LLM suggestions via an LSP, but I've not
| tried personally. Assuming it's true that you can get LLM
| suggestions, it's not clear to me that you can run two LSP's on
| the same file, so it might be a choice between clangd and an
| LLM LSP? Not sure.
|
| * No integrated build support. You'll probably end up building
| from a terminal. I use Wezterm with a custom lua script that is
| invoked on a hotkey. I put a lot of thought into the build UX,
| and what I've done is both extremely hacky and still not good
| enough.
|
| Helix is not flexible, it's uncompromising. I like it, but I
| think it's hard to beat CLion or vscode for C++ development.
|
| I'd say right now, if you have a good setup already, stick with
| what you have.
| kemiller wrote:
| 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.
| alphazard wrote:
| > but they can be... stubborn about what gets into the core.
|
| Yes, as an onlooker who is similarly cautious about moving to
| helix, I consider this to be a major risk factor. I've watched
| the maintainers waste dozens of hours of contributors' time,
| and leave the project with no improvement afterwards. I would
| actively warn against anyone trying to contribute to the
| project. The maintainers simply don't know how to run an open
| source project, and it's unlikely you will be able to
| accomplish anything. It's fine for a project to not accept
| contributions, and if you don't have the skillset to leverage
| contributor labor, then it's better to be upfront about it.
|
| That being said, I hope they figure out the plugin system, or
| someone forks the project to add the missing table stakes
| features.
| no_wizard wrote:
| This is what killed all the momentum that Elm had at one
| point. While that's a language and not an entire editor, it
| does serve as an illustrative example of being far too strict
| about accepting changes to core.
| poncho_romero wrote:
| > The maintainers simply don't know how to run an open source
| project
|
| Can you explain why you feel this way? From an outsider's
| perspective, Helix seems like an impressive piece of software
| with a growing community. I don't see what the maintainers
| are doing so wrong
| alphazard wrote:
| Being able to build high quality software alone is a
| distinct skill from being able to make a group of engineers
| productive. Neither are soft skills, it comes down to how
| the software is architected and how well you can produce,
| understand, and communicate designs with the other
| collaborators.
|
| I _do_ consider helix to be an impressive piece of
| software, and I agree that the user base is growing, not
| necessarily the set of effective maintainers though. The
| maintainers don 't seem to have any aptitude for
| coordinating engineering effort. That would be fine, if
| they were honest and direct about it. SQLite is a project
| which does not accept contributions, I think helix should
| do the same.
|
| Put differently, I don't expect the large community to have
| a meaningfully positive effect on the quality of the
| software, because the maintainers have not demonstrated the
| competency to effectively utilize that labor. I expect
| helix to continue slowly improving at whatever rate the
| maintainers can make important changes themselves.
| Crowberry wrote:
| I actually moved from VS Code to helix and happily used it
| exclusively for about 4-5 months, at that point I had list list
| of things I really wanted in my editor. I took that list to
| neovim and haven't looked back!
|
| I really hope to be able to use helix again in the future
| though, there was a speed advantage in helix and less janky
| window management.
|
| But for me to do that they might have to allow full vim motions
| as well
| jgalt212 wrote:
| The latest neovim is a bear to install unless you have
| something newer than Ubuntu 22.
| zuhsetaqi wrote:
| Isn't the built in tutor build to interactively teach exactly
| what this site contains?
| casey2 wrote:
| 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
| )
___________________________________________________________________
(page generated 2025-11-01 23:00 UTC)