“Daemon”, for a process that is detached from your terminal

That's factually incorrect. Daemons are often spawned from "early" processes whose ancestors are not TTYs.

It's slightly more nuanced than that, but you've got the basic idea.

Do you expect it to be as ubiquitous as Vi(m) has become?

I honestly believe that Helix will eclipse NeoVim because it's designed better, the source code is more maintainable, and the philosophy is a bit more balanced and welcoming to users that care more about productivity than customizability. Refactoring Vim's spaghetti C code is a massive task, and C as a language drags it down. Where the NeoVim ecosystem is currently fractured among many Lua "distributions," Helix just builds on itself in one source tree. I think starting with a solid core before supporting plugins will be good for the future of Helix.

do you expect Helix to improve its Vim implementation

I'm not sure what you mean. The Helix key combos are similar but not the same as Vim, they are closer to Kakoune. Once Helix has plugins, it might be possible to get something closer to true Vim emulation.

rival Vi(m) in being ‘ever-present’

Yea I think Helix is here to stay, and it will continue stealing market share from other terminal editors. It probably won't convert anyone that's already invested years in learning and configuring (Neo)Vim, but for newcomers looking for a powerful option with sane defaults, Helix is far easier to get started with.

Personally, I learned Vim at a workplace where most others used Vim. This was at a time when NeoVim was just gaining traction, so I wasn't familiar with it. Vanilla Vim didn't quite compete with VSCode for my workflows, so I worked with VSCode for a while before trying NeoVim. I found the NeoVim setup obtuse. Helix saved me all of that effort, and I was almost immediately productive.

"how to write sloppy rust code and squander most of the advantages of the language"

Only half serious. But I think really the only point that I agree with is taking the easy way out with the borrow checker. I mean, at least try to borrow when it's idiomatic, but if you get frustrated, clone (or move) instead.

Error handling when done well is not much harder than unwrapping everything, and you get many advantages. Learn to use thiserror for your library crates and anyhow for executables.

I also agree that you should avoid unsafe 99% of the time. If you think you need it, you probably don't.

Helix is great. And it's written in Rust so I feel pretty comfortable working in the codebase. The maintainers are friendly. I think it will eventually leave other modal terminal editors in the dust, considering rate of development.

It has shortcomings from being young, but they are rapidly disappearing. The philosophy of being mostly "batteries included" is so refreshing compared to the configuration hell of NeoVim.

Some of the solutions it claims to provide would be genuinely great. I can't tell if it delivers. It definitely looks pre-alpha stage. I really hope it's not locked-in to their cloud platform.

The cargo culting is always going to happen and turn into elitism. But it stems from real advantages of specific technologies, and sometimes you should actually consider that the tech you're using is irresponsible when better alternatives exist.

the Rust folks wouldn’t care about the in-memory representation as long as the compilation is on point.

Well I can't speak for everyone, but Rust is very intentional about supporting things like repr(C). At least some of us care a lot.

Nah these are the actual integer representations. Otherwise you would have Some(None) == Some(Some(None)) which is way too Javascripty for Rust folks.

OK but what is "Git Patch Stacks"? It seems like I'm missing something fundamental that was never actually explained in this post.

EDIT: Oh hey I found it after reading a different blog post on that site: https://github.com/uptech/git-ps-rs

The post is also super rambling in the middle section.

I have to assume that this is something similar to Mercurial's MQ plugin or Stacked Git (stgit), which allow you to manage revisions as a stack of diffs.

I personally enjoy using stgit, and it fits just fine into the world of feature branches and PRs.

This part scared me:

In a Stacked Branch workflow, you are creating branches for each of your atomic commits, and then you're defining the relationships between those branches so it can formally store a directed acyclic graph of those relationships.

Why do you want to make a separate branch for every commit? That sounds like a nightmare, and it's definitely not the intended workflow for git.

Do challenging projects. Read code from better engineers. Work with better engineers. Try new languages that actually solve technical problems instead of just having nice syntax. Contribute to open source projects that you use. Actually read the manuals that come with your tools. Notice when it's taking you a long time to do something and reflect on it to find a faster way. Constantly tweak your workflow to be more productive.

And the most important of all:

Get a split ergomech keyboard.

Seems like they could maintain non-canonical lookups by normalizing all crate names to use underscores.

That's so weird, I thought everyone had already heard about Helix. Why are people still using neovim?

Is it just a matter of proactive learning and I should know all of them in advance, as well as their uses?

Yes

Oh yea I want to try this out. Just wish it could work with other editors. Also Talon being closed source bothers me.

I have a few that I've started using this year.

• NixOs
• Helix
• Cloudflare Tunnel

Does it offer any advantages over sway? I don't find the 3d effects useful.

Helix. Instant startup. Minimal configuration required. Has all of the killer features I want from an IDE anyway.

EDIT: I assumed people would just research this anyway, but a more complete list of features I enjoy from Helix:

• very responsive
• modal editing
• declarative configuration file format (TOML, not Lua)
• language server protocol
• debug adapter protocol
• written in Rust so I am more likely to be able to submit a PR if I need to

Some cons (all known issues on github):

• no plugin API yet
• inline LSP diagnostics are overly intrusive and can overlap your code
• cold-starts the LSP when you start the editor, so you might need to wait for symbol queries in a large project

Not even "controlling the lifespan" but, "being whipped by your machine when you are not careful with the lifetimes."

The only thing a GUI text editor can be better at than a terminal editor is making it easier to use the mouse.