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
(edited for grammar)
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.
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.
1. While Helix dev is on the slow side, I think what you’re describing as specific to Helix is in fact the typical case in open source
2. In this case the author did a bunch of work up front and the maintainers said no almost immediately after the PR was posted
I agree they could be faster to say no, but I think part of it is that the maintainers would have to agree themselves and as far as I know they are not getting together to come to consensus about random Helix PRs every day.
Not all open-source projects want contributors, many are open-source for different reasons.
Is switching to Helix worth it? Can I get more-or-less equivalent functionality with Helix?
If you are interested in making a move to a terminal editor I would instead look to neovim until helix matures a bit more
* 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.
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.
For something like an editor, where whole features can be turned off by default, there's quite a bit of leeway to add bloat and get newcomers to buy in, without actually making the product worse.
For a programming language, a feature in the language has to be used by everyone. So the leadership has to say no a lot to keep the language high quality, and that makes it hard to get newcomers to buy in.
Unfortunately you can't have it both ways without paying people to maintain the project. Elm was good because the leadership said no...often. It's dead because the leadership said no so often that no one wanted to help maintain it. No one is going to waste their free time working on a project that won't accept their ideas, nor should they.
A language like Go doesn't have this trade off. If the Go leadership rejects a google employee's proposed language change, the employee still has to do maintenance chores as directed to keep their job.
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
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.
They decided on an obscure Lisp flavor as the language (instead of WASM), so I don't hold my breath for a powerful plugin system, more like slightly more convenient configuration language.
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
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.
Change them to be the same! It's indeed a waste to have a difference for such fundamental keybinds
Same with Helix - there is a vim layout out there, no need to use a different set (unless, of course, you can use something better, but then you should also use it in vim)
linsomniac•14h ago
hit8run•14h ago
you can do "! git status" etc
There is some other integration for git like SPACE + g to see file changes for example
abuani•14h ago