7 ms·

Tried it again few days ago. I kinda get that currently you can only use AI on Helix through LSP, but on top of that it does not have auto-refreshing files when

Tried it again few days ago. I kinda get that currently you can only use AI on Helix through LSP, but on top of that it does not have auto-refreshing files when changed outside - makes it really hard to work with external AIs, as I'm just constantly worrying if I'm editing a stale file.

burke 6mo ago
The latter is pretty easy to vibe-patch in: https://github.com/burke/helix/pull/1 https://github.com/burke/helix/pull/1
small_scombrus 6mo ago
I know it's not a proper fix, but helix does have `:reload` and `:reload-all` commands I have reload-all bound to Ctrl-r
- dcre 6mo ago
  Same!
vaylian 6mo ago
> you can only use AI on Helix through LSP How do other editors do this, if they don't use LSPs? Helix specifically choses LSP as the integration mechanism (in combination with TreeSitter) for supporting different programming languages, because it is a language-agnostic protocol and therefore only needs to be implemented once. Is there some established AI-agnostic protocol/interface? I don't think MCP would work here?
- small_scombrus 6mo ago
  > Is there some established AI-agnostic protocol/interface? AFAIK no
  - logicprog 6mo ago
    ACP? https://agentcommunicationprotocol.dev/introduction/welcome https://agentcommunicationprotocol.dev/introduction/welcome
- potro 6mo ago
  ACP Agent Client Protocol https://agentclientprotocol.com/get-started/registry https://agentclientprotocol.com/get-started/registry
  - beaker52 6mo ago
    This is a distinctly Zed solution - trying to move the agent experience into the editor, rather than just giving the agent an interface with which to control and read from the editor. Not only do the most popular editors have little-to-no incentive to implement it (they’re more interested in pushing their own first-class implementations, rather than integrating those of others), it’s much more work to integrate the evolving agent experience into the IDE than it would be to provide IDE integration points for the agents themselves. So, I think this project would have been much more successful if it had been more focussed on keeping the agent and IDE experiences separated but united by the protocol, instead of trying to deeply marry them. But that’s not in line with Zed’s vision and monetization strategy. It won’t be long before the big players start to release their own cloud-based editors. They’ll be cloud-based because the moat is wider, and they’ll try to move coding to the cloud in the way that Google Workspaces moved docs to the cloud. Probably with huge token discounts to capture people. If you squint, you can already see this starting to happen with Claude Desktop, which runs its agent loop on the cloud (you can tell because skills appear to need to be uploaded). Notably, Microsoft, with VSCode and GitHub have a web-based editor advantage in this space, but no models.
    - spudlyo 6mo ago
      It's not just Zed, Emacs has has a thriving ACP implementation in agent-shell[0], and allows for some very cool integrations[1]. There are a fair number of other clients[2] as well. [0]: https://github.com/xenodium/agent-shell https://github.com/xenodium/agent-shell [1]: https://www.youtube.com/watch?v=HJQ86HuSIJI https://www.youtube.com/watch?v=HJQ86HuSIJI [2]: https://agentclientprotocol.com/get-started/clients https://agentclientprotocol.com/get-started/clients
    - yammosk 6mo ago
      The second half of this is spot on. The now is making IDEs that can integrate with agents, not the other way around. Soon the Claude and Codex will do that for us on their hosts and the argument is it will save sending the context up.
- nikita2206 6mo ago
  Just watching filesystem for file changes and updating the in-memory view of the file on any change? This isn’t really relevant to MCP, though one option is to provide a different tool to the AI agent for file modifications, which would make modifications through the file editor itself.
  - vaylian 6mo ago
    > Just watching filesystem for file changes This is non-trivial, if you want to do it efficiently. On Linux you can set up an inotify listener for individual files, but not for entire directories. This also breaks down if you are working with data on non-local drives.
clouedoc 6mo ago
With time I actually came to get accustomed to it and to enjoy my files not reloading automatically with Claude Code changes.
dayjah 6mo ago
I was feeling this pain also; so I switched my workflow to watching file changes with lazygit, and then switching to helix to make small tweaks. Another option you may want to try is mux (github.com/coder/mux). It wraps the LLM in a nice interface which has the ability to do line/block comments on changes by the LLM that then goes goes into your next prompt. It’s very early stage though: v0.19.0.
g947o 6mo ago
GitHub Copilot, Claude Code and Codex provide fairly good IDE integrations. They don't just edit files behind your back. They actually edit the files you have in the IDEs using editor APIs and even show you a nice diff view. This way you never have content that is out of sync. I find this approach very usable and appealing. On the other hand, many of the AI tools and their companies think that you should completely ditch IDEs for CLIs only, because "nobody needs to write code anymore". Some of them even stopped maintaining IDE extensions and go all-in in CLIs. (I call that complete BS)
- buzzerbetrayed 6mo ago
  I don’t even open a text editor anymore 90% of the time. Seems clear to me that IDEs, in the traditional sense, don’t really have a place in the future of software creation. They might morph into something that does, but definitely not in their current form, imo.
  - satvikpendem 6mo ago
    If you actually want to engineer properly and review the code rather than pushing out vibe coded slop PRs, then IDEs absolutely do have a future.
    - mbrumlow 6mo ago
      > If you actually want to engineer properly. I think this statement is misguided, and potentially comes from a lack of experience in getting AI coders to produce quality. Proper engineering does not come about from the tools you use or how you use them. Proper engineering has always come from thought, and reasoning, it never was about the act of coding. It always was about the systems thinking and expressing the goals and desires that matched the requirements. IDEs were never needed to properly engineer and in the days of AI will become increasingly less important. Tools for planning, reviewing, and commenting on code are the future. The necessity to edit actual code is coming to an end.
      - 6mo ago
mgrandl 6mo ago
Man I heard about this being addressed soon for years. I have given up on Helix by now, but it’s wild that this still hasn’t been released.

burke 6mo ago

The latter is pretty easy to vibe-patch in: https://github.com/burke/helix/pull/1 https://github.com/burke/helix/pull/1

small_scombrus 6mo ago

I know it's not a proper fix, but helix does have `:reload` and `:reload-all` commands I have reload-all bound to Ctrl-r

dcre 6mo ago
Same!

vaylian 6mo ago

> you can only use AI on Helix through LSP How do other editors do this, if they don't use LSPs? Helix specifically choses LSP as the integration mechanism (in combination with TreeSitter) for supporting different programming languages, because it is a language-agnostic protocol and therefore only needs to be implemented once. Is there some established AI-agnostic protocol/interface? I don't think MCP would work here?

small_scombrus 6mo ago
> Is there some established AI-agnostic protocol/interface? AFAIK no
- logicprog 6mo ago
  ACP? https://agentcommunicationprotocol.dev/introduction/welcome https://agentcommunicationprotocol.dev/introduction/welcome
potro 6mo ago
ACP Agent Client Protocol https://agentclientprotocol.com/get-started/registry https://agentclientprotocol.com/get-started/registry
- beaker52 6mo ago
  This is a distinctly Zed solution - trying to move the agent experience into the editor, rather than just giving the agent an interface with which to control and read from the editor. Not only do the most popular editors have little-to-no incentive to implement it (they’re more interested in pushing their own first-class implementations, rather than integrating those of others), it’s much more work to integrate the evolving agent experience into the IDE than it would be to provide IDE integration points for the agents themselves. So, I think this project would have been much more successful if it had been more focussed on keeping the agent and IDE experiences separated but united by the protocol, instead of trying to deeply marry them. But that’s not in line with Zed’s vision and monetization strategy. It won’t be long before the big players start to release their own cloud-based editors. They’ll be cloud-based because the moat is wider, and they’ll try to move coding to the cloud in the way that Google Workspaces moved docs to the cloud. Probably with huge token discounts to capture people. If you squint, you can already see this starting to happen with Claude Desktop, which runs its agent loop on the cloud (you can tell because skills appear to need to be uploaded). Notably, Microsoft, with VSCode and GitHub have a web-based editor advantage in this space, but no models.
  - spudlyo 6mo ago
    It's not just Zed, Emacs has has a thriving ACP implementation in agent-shell[0], and allows for some very cool integrations[1]. There are a fair number of other clients[2] as well. [0]: https://github.com/xenodium/agent-shell https://github.com/xenodium/agent-shell [1]: https://www.youtube.com/watch?v=HJQ86HuSIJI https://www.youtube.com/watch?v=HJQ86HuSIJI [2]: https://agentclientprotocol.com/get-started/clients https://agentclientprotocol.com/get-started/clients
  - yammosk 6mo ago
    The second half of this is spot on. The now is making IDEs that can integrate with agents, not the other way around. Soon the Claude and Codex will do that for us on their hosts and the argument is it will save sending the context up.
nikita2206 6mo ago
Just watching filesystem for file changes and updating the in-memory view of the file on any change? This isn’t really relevant to MCP, though one option is to provide a different tool to the AI agent for file modifications, which would make modifications through the file editor itself.
- vaylian 6mo ago
  > Just watching filesystem for file changes This is non-trivial, if you want to do it efficiently. On Linux you can set up an inotify listener for individual files, but not for entire directories. This also breaks down if you are working with data on non-local drives.

clouedoc 6mo ago

With time I actually came to get accustomed to it and to enjoy my files not reloading automatically with Claude Code changes.

dayjah 6mo ago

I was feeling this pain also; so I switched my workflow to watching file changes with lazygit, and then switching to helix to make small tweaks. Another option you may want to try is mux (github.com/coder/mux). It wraps the LLM in a nice interface which has the ability to do line/block comments on changes by the LLM that then goes goes into your next prompt. It’s very early stage though: v0.19.0.

g947o 6mo ago

GitHub Copilot, Claude Code and Codex provide fairly good IDE integrations. They don't just edit files behind your back. They actually edit the files you have in the IDEs using editor APIs and even show you a nice diff view. This way you never have content that is out of sync. I find this approach very usable and appealing. On the other hand, many of the AI tools and their companies think that you should completely ditch IDEs for CLIs only, because "nobody needs to write code anymore". Some of them even stopped maintaining IDE extensions and go all-in in CLIs. (I call that complete BS)

buzzerbetrayed 6mo ago
I don’t even open a text editor anymore 90% of the time. Seems clear to me that IDEs, in the traditional sense, don’t really have a place in the future of software creation. They might morph into something that does, but definitely not in their current form, imo.
- satvikpendem 6mo ago
  If you actually want to engineer properly and review the code rather than pushing out vibe coded slop PRs, then IDEs absolutely do have a future.
  - mbrumlow 6mo ago
    > If you actually want to engineer properly. I think this statement is misguided, and potentially comes from a lack of experience in getting AI coders to produce quality. Proper engineering does not come about from the tools you use or how you use them. Proper engineering has always come from thought, and reasoning, it never was about the act of coding. It always was about the systems thinking and expressing the goals and desires that matched the requirements. IDEs were never needed to properly engineer and in the days of AI will become increasingly less important. Tools for planning, reviewing, and commenting on code are the future. The necessity to edit actual code is coming to an end.
    - 6mo ago

mgrandl 6mo ago

Man I heard about this being addressed soon for years. I have given up on Helix by now, but it’s wild that this still hasn’t been released.