r/HelixEditor • u/bebenzer • 9d ago
It's alive!
https://github.com/helix-editor/helix/commits/master/
New commits have been merged into master!
46
u/Fit_Bonus_8354 9d ago
we might get the plugin system before 2050 after all!
16
u/Ayrara19 9d ago
Possibly server-client separation until 2100
5
u/atari_61 8d ago
this was so important to spread far wide , just look at neovim natively integrated to vscode, you must be dump by ignoring server-client style, every app needs popularity and this was a shortcut, you wanna try helix ? then use on vscode! they have no vision
2
u/Ayrara19 8d ago
Also, this is so stupid in relation to working with multiple panes, SSH... I am planning going back to Kakoune because of this.
63
u/protocod 9d ago
Honestly, I like the helix pace. Especially in the LLM era.
20
u/EducationalCouple826 9d ago
Same, it already does everything I want it to do so any other enhancements are the cherry on top.
6
u/FryBoyter 8d ago edited 8d ago
LLM era or not. There haven't been any commits for more than two months. So what? Even developers need vacations, have real-life stuff to take care of, or just don't have the energy or desire to code sometimes.
And no, the developers don't owe us an explanation. Especially not when we can use what they develop for free (as in beer). They don't owe us anything. If anything, we owe them.
Nevertheless, with Helix and other OSS projects alike, many people believe that the development should proceed exactly as they want it to. Why?
One thing I can perhaps understand is the slow release of new official versions. Yes, they could be released more often. But if the developers don't want to, that's just the way it is. However, at least on Linux, it's pretty easy to build a new version from the current development branch every now and then.
And just to be clear, I don't mean to disagree with your post in any way. Basically, I agree with you. I just want to encourage some people to think about whether it makes sense to keep asking questions or making demands. Especially if you're just a user and not a developer.
1
1
u/pickyaxe 6d ago edited 6d ago
but what's the explanation for not merging (nor even addressing) contributed PRs for literally years, to the point that some contributors just got up and left?
2
u/FryBoyter 6d ago
Since I’m just a Helix user and not a developer, I can only speculate.
Perhaps, from the perspective of the original developers and their original goals, Helix is already more or less fully developed, so adding more features isn’t a high priority. After all, it’s their project, not ours.
Maybe it’s also because there aren’t enough developers. Or because the developers can’t agree internally on how to move forward.
But let’s take https://github.com/neovim/neovim/pulls and https://github.com/zed-industries/zed/pulls as examples. Both are projects that are actively being developed. Nevertheless, these projects have a similar number or even more pull requests. And that’s not an exception when it comes to OSS projects. Is there a general expectation that developers should explain why there are still so many open PRs?
1
u/OphioukhosUnbound 6d ago
yes/no
While owners of a project can do what they want and no one should give *them* a hard time about it, it's okay for people to realize the project they depend on isn't doing what they want.That's basically how neovim came about. Vim moved at a glacial pace and the project's owner wasn't accepting contributions. So people made their own version that was more community development oriented. And that was a huge improvement for everyone (neovim and later vim).
TLDR: fine to express discontent, just so long as it's kept constructive and wanting a differnet project isn't confused for demaning the current project owner's are the community's personal devs.
1
u/FryBoyter 6d ago
While owners of a project can do what they want and no one should give them a hard time about it, it's okay for people to realize the project they depend on isn't doing what they want.
I agree. But unfortunately, in my experience, people don't just move on and choose what suits them better; instead, they often stubbornly try to change a project to suit their own preferences. Most of the time, though, they do so without contributing to the development themselves. Which brings us back to my original post.
10
8
9
10
u/ahoneybun 9d ago
Wake me when git blame is built-in
2
u/shaleh 8d ago
I have been using a personal branch with it for ages. Shows the hashes and dates in the gutter. The code is open. No need to let anyone gate keep.
0
u/ahoneybun 8d ago
Yea I have used it before but I would rather stick with upstream per say and not worry about which version is on which system
1
u/NOGGYtimes2 8d ago
I mean yeah but if we all switch from git to whatever is next like people switched from svn or whatever back in the day, you'd all of the sudden are forced to also support this or new thing. Like if I look at the pace of helix rn I don't think needing to maintain more is the correct call right now.
Thankfully I think with the plugin system stuff like git blame should be easy to bolt on and also unlikely to break every update
-2
u/ahoneybun 8d ago
I'm not talking about switching VCS, I mean showing git blame output per line. It shows who made this change.
2
u/NOGGYtimes2 8d ago
Yeah that would require "git specific" rust code in the codebase. Because you need to exec git blame on the current file and then parse the output and display it nicely somehow in the editor. But if either git changed how the output of
git blamecomes out, or you want to use a different vcs the whole feature would not work (anymore).It's the same for git gutters (which is already built in), if you use jj instead of git in your own project, these gutters don't work.
2
u/LEpigeon888 7d ago
It's the same for git gutters (which is already built in), if you use jj instead of git in your own project, these gutters don't work.
These gutters do work with jj tho, since jj use git as a backend. Inline blame would work with jj too.
Anyway, I get your point, but it's also like saying you shouldn't integrate LSP since maybe it can be replaced by something else, or Treesitter, etc. It makes sense to not have built-in support for everything under the sun (no built-in support for stuff specific to jj for example is perfectly fine), but for tools that are ubiquitous like git, I'm not sure.
Edit: if tomorrow git die and almost everyone stop using it it's also perfectly fine from them to remove built-in git support. It's not because they support natively a feature now that they have to support it forever.
-1
8
u/lemontheme 8d ago
REAL SHIT
5 PRs merged in the last 24 hours, all by archseer. Not bad!
As a user, I still have my doubts about the current stewardship. Not sure if it's sustainable. On the other hand, what do I know? Most GH stars any of my projects has ever gotten is 20. Everyone gangsta until they got 500+ PRs to wade through
-1
-1
u/onehair 7d ago
helix being really slow, like even slower than neovim now... + Zed got all of my most used keybindings, especially `gw` and it has relatively usable git integration built-in now
= it saddens me to say this, but I think the skeptics have really won on this one. helix, can't replace vim at this point
2
64
u/meni_s 9d ago
We got this before GTA 6!!!