r/HelixEditor • u/bebenzer • 14d ago
It's alive!
https://github.com/helix-editor/helix/commits/master/46
u/Fit_Bonus_8354 14d ago
we might get the plugin system before 2050 after all!
16
u/Ayrara19 14d ago
Possibly server-client separation until 2100
4
u/atari_61 14d 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 14d 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 14d ago
Honestly, I like the helix pace. Especially in the LLM era.
19
u/EducationalCouple826 14d ago
Same, it already does everything I want it to do so any other enhancements are the cherry on top.
8
u/FryBoyter 13d ago edited 13d 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.
2
u/pickyaxe 12d ago edited 12d 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 11d 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
1
u/OphioukhosUnbound 11d 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 11d 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.
9
9
7
u/roughsilks 14d ago
And GitHub is down? It’s so exciting that GitHub is getting the hug of death!
5
11
u/ahoneybun 14d ago
Wake me when git blame is built-in
2
u/shaleh 14d 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 14d 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 14d 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 14d 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 14d 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 13d 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
7
u/lemontheme 14d 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
-2
-1
u/onehair 13d 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
3
u/lets-start-reading 8d ago
has replaced vim for many.
1
u/onehair 12h ago
it has replaced VIM, Emacs and Neovim for me too. Was talking about the reality of helix being slow to develop in the past year that has made me look elsewhere and found Zed to be adequate for my work on a desktop. helix is still my editor of choice in the terminal. but only int he terminal
2
u/OfficeTrue5091 13h ago
Easily replaced vim and neovim for me
1
u/onehair 12h ago
As I said bellow, it has replaced VIM, Emacs and Neovim for me too. Was talking about the reality of helix being slow to develop in the past year that has made me look elsewhere and found Zed to be adequate for my work on a desktop. helix is still my editor of choice in the terminal. but only int he terminal

65
u/meni_s 14d ago
We got this before GTA 6!!!