Meanwhile I'm checking Helix editor every 6 month to see if authors became any less hostile to the idea of thinking about considering of starting thinking about potentially adding copilot support.
Why should an open source editor support some single commercial product API in their core? Why copilot and not another product?
It's completely reasonable to me that this should be a third party plugin or that they should wait for some standard that supports many products.
As @adriangalilea recently aptly wrote in Helix's 2nd-longest discussion thread (#4037):
> For the nth time, it's about enabling inline suggestions and letting anything, either LSP or Extensions use it, then you don't have to guess what the coolest LLM is, you just have a generic useful interface for LLM's or anything else to use.
An argument I would agree with is that it's unreasonable to expect Helix's maintainers to volunteer their time toward building and maintaining functionality they don't personally care about.
It's not about it being locked to a commercial product — whatever they built would be provider-agnostic. My understanding is the decision is more about not wanting to build things into core that are evolving so quickly and not wanting to rely on experimental LSP features (though I think inline completions are becoming standard soon[1]). Zed itself is perfect evidence of that -- they built an AI integration and then basically had to throw it away and rebuild it because the consensus best practice design changed. The Helix maintainers don't have time for that kind of churn and aren't trying to keep up with the hype cycle. When the plugin system is ready people will be able to choose their preferred implementation, and maybe eventually some aspects of it will make it into core.
Interestingly enough, this is exactly why I've started using Zed – while simultaneously eagerly waiting for Helix PR #8675 (Steel plugin system) to get merged. It's not far off, but then again, many Helix PRs seem that way, only to stay in limbo for months if not years.
These last two months I've been trialing both Neovim and Zed alongside Helix. I know I should probably just use Neovim since, once set up properly, it can do anything and everything. But configuring it has brought little joy. And once set up to do the same as Helix out of the box, it's noticeably slower.
Zed is the first editor I've tried that actually feels as fast as Helix while also offering AI tooling. I like how integrated everything is. The inline assistant uses context from the chat assistant. Code blocks are easy to copy from the chat panel to a buffer. The changes made by the coding agent can be individually reviewed and accepted or rejected. It's a lot of small details done right that add up to a tool that I'm genuinely becoming confident about using.
Also, there's a Helix keymap, although it doesn't seem as complete as the Vim keymap, which is what I've been using.
Still, I hope there will come a time when Helix users can have more than just Helix + Aider, because I prefer my editor inside a terminal (Helix) rather than my terminal inside an editor (Zed).
The authors don’t seem hostile at all. They’re firmly against putting work into a feature they don’t care for but welcome pro-AI users to make it happen. For some reason the latter group hasn’t seemed to accomplish it.
Unless something's changed, every AI-backed language server I've tried in Helix suffers from the same limitation when it comes to completions: Suggestions aren't shown until the last language server has responded or timed-out. Your slowest language server determines how long you'll be waiting.
The only project I know of that recognizes this is https://github.com/SilasMarvin/lsp-ai, which pivoted away from completions to chat interactions via code actions.
I feel like an LSP is very insufficient for the ideal UX of AI integrations. LSP would be fine for AI autocompletes of course, but i think we want a custom UX that we don't quite yet know. Eg what Zed offers here seems useful. I also really like what Claude Code does.
I don't know the LSP spec well enough to know if these sort of complex interactions would work with it, but it seems super out of scope for it imo.
This rings so true for me! Helix is beautiful and works fantastic, I'm pretty happy not having AI integrated into my editor so Helix is basically exactly as I want without any extras I don't!
This seems more in scope of those same people who want to make their editor into an IDE. And just like most other things, the editor is a poor integration point for AI. The shell and inter-process communications are the gold standard for integration and are where the best integrations emerging from. Things that work with your editor instead of trying to replace it. Aider being the best example I've seen so far... though I'd love to hear about others.
I can understand that, and it's great if it fits your needs. It's annoying when apps that just have to do one thing and do it well instead are focusing on hype features. My recent rant is about Warp terminal that has a "different font size for different tabs" issue open for years, but silently integrated all sorts of AI into the terminal.
And yet, it's hard to ignore the fact that coding practices are undergoing a one-in-a-generation shift, and experienced programmers are benefiting most from it. Many of us had to ditch the comfort of terminal editors and switch to Microsoft's VSCode clones just to have these new incredible powers and productivity boosts.
Having AI code assistants built into the fast terminal editor sounds like a dream. And editors like Helix could totally deliver here if the authors were a bit more open to the idea.
https://github.com/helix-editor/helix/discussions/4037