State of my Helix PRs

[nik-rev]

Hello everyone! It's been a while. I am giving a little update on the state of my open Helix PRs. A little background:

For the past year, I have really gotten into Rust - it is basically my first programming language, and the reason why I learned it was because I love open source software and wanted to contribute - but an outstanding majority of software that I use is written in Rust - and it seems to be the bright future.

So, I decided to learn Rust by actively contributing to an open source project. I looked at which projects I use that would be the most fun to get started with, and picked Helix because:

• I wanted to understand how a tool I use every day works under the hood
• I wanted new features but there's no plugin system, so might as well maintain my own fork with custom features instead
• An editor felt like the simplest complex project to get started with. If I want to learn how a command like ":open" works, I just grep for "open" in the codebase and read. If I want to add a new command. I just write a new, self-contained function.

I started with the Rust book and after 3 days did my first Helix PR. It was great. I continued sending PRs for a while. I had TONS of free time due to being 18 and recently finishing my A Levels. I didn't mind some of those PRs being closed, because I used it as a learning opportunity - if it's merged, great! If not, I don't mind.

This lasted for many months. I had weeks where I'd just spend 6-8hours a day learning Rust with Helix, making PRs.

After a while, I had dozens of open PRs. With 300+ PRs, and mostly 1 hero maintainer merging & reviewing them - I realized my PRs will sit there for a while. But people already used them. People used my PRs in their custom forks. So for a while I kept my PRs up to date.

Keeping them up to date requires checking every week or so for merge conflicts. Most of the time this is easy, but sometimes they take 1-2 hours to fix. With 30+ open PRs, this adds up.

Around this point, I stopped using Helix. I met some Zed developers at an event in London and got inspired to try their editor. It was great, so I've been using Zed for half a year now.

I don't use Helix anymore, but I was still interested in having my PRs be merged because they are useful to people and people really use them. So I continued to maintain them for a while, despite not even using Helix anymore.

After a few months, I noticed there's 400+ PRs so it's unlikely my PRs will be merged anytime soon. And by this point, I didn't have the same amounts of time to contribute as before. When I do have time to contribute to open source, I spent it on projects that I actively use. For example: my Rust crates, Rust compiler, darling (rust library for proc macros)

All to say, as much as I would like to continue maintaining my PRs - I keep finding myself using the free time I have on projects that I actively use

So, I will be closing all of my helix PRs except 1. And the one that will stay open is the one I will drive to completion. The Git Blame PR. This not only was the most exciting PR to implement, but I actively believe in the Gitoxide project and I am very impressed by its author Sebastian Thiel, and see this PR as an indirect contribution to that project, so I am very motivated by that idea to drive this effort forward. There are a lot of interesting details in the implementation of that PR, maybe I will write about it some day.

For all of my closed PRs, anyone interested in driving them forward is free to re-open them!

P.S. @mattwparas is an absolute legend, and I am very impressed by his dedication and work on Steel and the plugin system PR.

[TornaxO7]

Really sad to see you go... but I understand your reasoning here.
I also stopped contributing due to the lack of activity.

Details

I also stopped contributing due to the lack of activity.

I want to clarify that I do not want to bash the maintainers here.
Without them, helix wouldn't be like this today which is still my favorite- and main-editor!

Wish you all the the best and happy rusting!

[lens0021]

I'm not a contributor here, but I was touched that you took the time to write about why you're leaving. Most people, myself included, just disappear without a word. Thank you!

[rockboynton]

@nik-rev Wow, thanks for detailing your experience in the write up! I still use a ton of your work, including patchy to have several of your PRs in my own fork!

I'm curious with your switch to Zed, are you able to still get all the functionality Helix provides, including the keybinds and modes?

[TeriyakiBomb]

Zed has a WIP helix mode

[nik-rev]

I'm curious with your switch to Zed, are you able to still get all the functionality Helix provides, including the keybinds and modes?

Great question!

Short answer: Mostly. Many of Zed's missing features were added in the last half a year I've been using it for, that my list of Things I Want decreased by a factor of 3 since I first tried it out

Long answer

Zed does have a Helix mode, but it's still very far from complete - so I am using Vim motions in Zed.

Editing

Helix's editing model is definitely more intuitive and easier to learn, but the selection->action model is not the reason I used Helix for over a year.

Helix's primary appeal for me is out of the box configuration, and its multi-cursor implementation. The ability to select a region of code, create a bunch of cursors in it, and repeat the same action for each cursor can accomplish mind-blowing things.

Zed has commands for these capabilities, so despite moving to Vim keybindings I still use a lot of the Helix-specific ones that operate on selections.

• Actions like mi(d in Helix take 5 keystrokes, in Vim it's di( - 4 keystrokes. 25% less.
  If I make a mistake I can undo it. If I want the equivalent of Helix's ability to see what the d will do, I can use vi(d which is also 5 keystrokes, but I have the choice.

• Due to the selection->action nature, the . key is unavailable in Helix. So you can't repeat the last action, as it's unclear what should happen - you don't have a selection. I use this feature all the time.

• Most powerful Helix commands like alt-s are available in Zed as well, and I have them bound. That means I essentially get the power of 2 editing systems at once. Helix's multi-cursors and Vim's faster editing

• Vim motions are available everywhere, and I've always had them turned on. In my browser, on remote servers, in my shell. It was common for me to mess up keybindings due to always context-switching between the 2 editing models

Pros

• Integrated terminal: Opening files in the terminal will open them as a buffer in the editor, instead of creating a new editor instance. Huge, because I get to use all the commands I'm familiar with for navigating in the terminal. For example, I have this alias in my configs:

  alias rg = ^rg --hyperlink-format="zed://file{path}:{line}:{column}"
  

  When searching anything with ripgrep, all links in the terminal are clickable and can be opened as a new buffer in the existing editor instance:

  memory❯ rg let
  src/main.rs
  9:    let ui = AppWindow::new()?;
  12:        let ui_handle = ui.as_weak();
  14:            let ui = ui_handle.unwrap();
  
  Cargo.lock
  1378:name = "filetime"
  4305: "filetime",
  

• Developers: Zed is maintained by dozens of full-time employees, it is by the same people who created Tree sitter, some of their developers also work on rust-analyzer. There are weekly releases, and each release has changes that are impactful to me. Like the recently added sticky scroll. And the soon-to-be-added semantic highlighting

  It was really nice to actually talk to some of Zed's developers in-person

• Security: Check out a repository, and contents of the .helix folder will be read and allow arbitrary code execution (for example, someone might configure a malicious language server that starts when you open *.ts files, and sends contents of these files to a remote server). Zed has trusted workspaces.

• Multi-buffers: I can't emphasize enough how important this feature is. It is the killer feature of Zed. It lets you place a bunch of buffers into a single "multi-buffer" and then edit all of those buffers without leaving the multi-buffer. This comes in very handy when doing workspace refactors. If I remove a field, I can open all 40 errors in a single buffer, edit them all with multi-cursor/regex and be done - instead of having to go to each individual file

• Project-wide search/replace. Helix is fantastic at replacing text in a single buffer. But it's very common to want to do this replacing across the workspace.

• Git integration: Despite being a heavy user of the git CLI, I still prefer UIs for staging and manipulating hunks. Zed has a commit log, blame, and explorer for all Git changes in the repository. When you push a branch, you are offered to "Open a PR" directly in the editor.

• Better intellisense. If I have a line like this, with cursor at |:

  ui.on_req|({

  And I have the "on_request_increase_value" suggestion - what will happen is different depending on the editor.

  Helix:

  ui.on_reqon_request_increase_value({

  This inserts the entire string as-is, which means I have to go back and delete the invalid portion "on_req" at the start.

  Zed:

  ui.on_request_increase_value|({

  Zed's implementation instead smartly replaces the 5 letters that I would have otherwise delete in Helix.

• Auto-complete in config files. This is incredible, I can hover over any of my config fields, and it will auto-complete all available commands for me.

• Community and 3rd-party support: Tools that have an "Editor setup" or "Editor integration" section seems to contain a section about Zed more often than a section about Helix.

Cons

• Loss of control. For example, one of the options that I'd really like to have is the ability to remove the title bar. Zed received a PR to add this feature, but it was rejected because it didn't align with the Zed team's vision

• Telemetry is opt-out

• Worse syntax highlighting: I believe that Helix currently has the best tree-sitter syntax highlighting out of all editors. For the past 6 months, the majority of merged PRs to helix seem to be improvements to these queries

  It's unfortunate that all of this has to essentially be rewritten for Zed, I think there should be a central repository of queries that all editors can benefit from. A PR to a repository like that will improve syntax highlighting for both Zed and Helix.

  This is likely temporary. I imagine 1-2 years down the line Zed will catch up with Helix in terms of syntax highlighting - and likely overtake it. Especially considered semantic highlighting. Helix's syntax highlighting queries are maintained in-tree while Zed's are available as plugins, so individuals who develop language extensions have more control over the queries

• File explorer: I'm used to the File Explorer that Helix has (space+e) which shows the current file, files in the same directory as this one. Zed has a traditional file tree, which requires some time getting used to

• Jump list: Zed's jump list is different to Helix's, to the point where I sometimes lose track of where I was. I can't quite describe how it is different, but jumps in Helix that would be registered aren't in Zed

• JSONC is used for configuration, instead of TOML

• Performance: I've never had performance issues with Helix, but it's not uncommon for zed to noticeably slow down, lag, or freeze when a lot of cursors are involved - for example, pasting the same text in 100 different locations

• I like that Helix always shows your primary cursor in the viewport. In Zed, your cursor can be out of the viewport, which can be disorienting

• No gw (goto word), but that seems to be coming at some point, as it's one of the issues with the most amount of likes in the repo

[rockboynton]

You are an absolute legend thank you. I am so comfortable with Helix at this point but I will have to check out Zed at some point, probably when they add gw which I use religiously

[luccahuguet]

there is a PR for gw, but im not sure when it will merge: zed-industries/zed#43733

[yerlaser]

The only solution I see to prevent this from happening to other contributors is to create a helix-unstable project within helix-editor organization where with laxed rules many experimental feature MRs could be merged.
Really sorry to see Helix die a slow death :(

[Rudxain]

That reminds me of Git's seen&next branches

[jerabaul29]

So sorry to see you leave @nik-rev , thank you so much for your PRs - enjoying several of them. Hope you get back to helix some day! :)

[taylorplewe]

I made use of many of your PRs and they were awesome. Until I too switched to Zed, which has a very competent Helix mode! Thanks for all the work on Helix man!! 🙏

[iamvoidcoder]

This is all just so so sad 😞 Not a contributor nor a user here but damn. I admire the hundreds of devs spending tons of personal time doing their best to contribute. In vain... Just look at those hundreds of PRs with virtually zero chance of ever being merged in. And all the constant rebasing.

I do understand Helix is the hallmark of "opinionated" software. And I do understand maintainers not wanting to merge PRs. Whether because these don't align with their view, because they don't want to end up maintaining someone else's code, simply don't have any spare time to review PRs and merge them in or all of the above together.

But damn it is just so painful to watch. The attitude is just something. Often borderline rude. Not sure whats on their minds but it feels a bit like: Well, we are coding this primarily for ourselves. Don't care about features we don't use ourselves. Therefore live with it or fo. Or: helix was envisioned as a minimalist editor (a mini IDE???), therefore it can't have more features (even if turned off by default). Or: helix is supposed to run out of the box with minimal or zero config, therefore we will hardcode things and not let them be configured. Or: wait until plugins will be implemented, topic closed. Or also: we will ask the community's opinion and will do the opposite. Don't think I've seen any other foss project a bit like that tbh. At this rate this could have been a private closed source project with binary releases or just a paid app.

Now don't get me wrong. The editor is great and I admire the helix devs work. They sunk enormous amount of personal unpaid time into it. I don't use it myself yet because of lack of some basic features (even something as basic as marks). Not that I somehow feel entitled to be given all the features I need, far from it. And I'd gladly pay for the editor if it offered slightly more to make it bit more useable. But I keep bouncing back for years just to check what is going on. And it always strikes me how different the air in the helix repo is...

Reading Nik's post made me truly a sad panda 🐼. Surely the maintainers could have at least done as little as put a big red warning on the front page with something like:

BEWARE! PRs OTHER THAN COLOR THEMES AND LSP NOT GOING TO BE ACCEPTED. DON'T WASTE YOUR OWN AND THE MAINTAINER'S TIME. WAIT FOR THE PLUGINS (AND HOPE THEY WILL NOT BE TOO LIMITING IN WHAT THEY WILL BE ALLOWED TO DO). PEACE.

[luccahuguet]

Thanks a lot Nik, for all the work and PRs. the whole thing saddens me a bit.

zed's helix mode is reaally good, guys!

I've create this discussion and have been observing it up close: zed-industries/zed#33580

and also using zed sometimes too

Using Zed with proper helix-mode has humbled me, and made me want more from yazelix and from helix...

we, the helix users, could really use a plugin system right now