What about Copilot support?

[rafaelrcamargo]

I know it would fit better as a plugin when the plugin ecosystem is ready, but nowadays copilot it's nearly essential for a lot of people, has someone done an integration, or is planning that?

[kirawi]

It's unlikely to be accepted as a feature to core until there is a a widely-adopted specification designed for editors. To my knowledge, such a standard has yet to be attempted. However, there has been movement in terms of external LSPs that provide similar functionality to what direct integration could provide: lsp-ai and helix-gpt. Beyond that, it has been deferred to the plugin system. While the initial MVP does not contain the necessary API for integration akin to VSCode, the API will be further built upon in subsequent PRs.

[rafaelrcamargo]

Yeah, mainly being a proprietary tech/product I imagine it.

[the-mikedavis]

It's more about being based on an open standard. Any integration code for copilot would not help also integrate tabnine for example, in contrast to open specs like LSP or DAP. Code that works specifically for some language/integration is better suited for plugins.

[rafaelrcamargo]

Yeap, 100% agreed, even describing the implementation sounds like a plugin description ahaha. Looking forward to that!

[Rottschaferanders]

Thank you for the discussion so far. I understand that the Helix team may not currently have plans to add Github Copilot integration to the main editor codebase, and that it may be better suited as a plugin in the future. However, I would like to emphasize the importance of making the plugin system more accessible for users to create their own plugins, including ones that integrate with external tools like Github Copilot.

Having a more accessible plugin system would allow Helix to expand its functionality and cater to a wider range of developers with varying needs. Additionally, I believe that an integration with Github Copilot would be a valuable addition to Helix, and it may require some work on the Helix side to make it possible.

I understand that there may be technical challenges and limitations to creating such an integration, but I would like to encourage the Helix team to explore the possibilities and work towards making it a reality. Thank you for your consideration.

[pickfire]

Can keep an eye on #2507 and once it is merged, adding LSP-copilot as a separate LSP could be a reality. @beyondCritics might be interested in this to be a serious coder. :P

[phillipspc]

Can keep an eye on #2507 and once it is merged, adding LSP-copilot as a separate LSP could be a reality.

Is it accurate to say that LSP-copilot could be implemented today, but it would replace the existing LSP for a given language (which is obviously not ideal)? If so, given how much interest there is in Copilot, it seems like that'd be a worthwhile experiment in the meantime (while we wait for multi LSP support). As to who performs that experiment... someone who knows more about implementing LSPs then me? 😆

[archseer]

There's no need to "implement" a LSP, LSP-copilot is already an implementation. You just need some toml config.

[phillipspc]

@archseer Ok, but this LSP is subscription based. Surely there has to be some sort of authentication flow at least? All I'm saying is that if there's appetite for getting Github Copilot in Helix, it seems like there's work that could be done on that front before multi LSP support is added. To be clear: I'm not making demands, just making an observation.

[gabydd]

LSP-copilot isn't actually a language server implementation of copilot, the copilot agent.js (https://github.com/github/copilot.vim/tree/release/copilot%2Fdist) file actually already uses jsonrpc, but it uses requests not standard to the lsp spec for it's functionality. So LSP-copilot is actually sublime text plugin that uses sublime lsp(sublime extension that implements a lsp client) to communicate with the copilot server and then integrates the copilot completions into the sublime UI. As I suggested in my earlier comment the two ways forward I see is either someone could wrap the copilot server in another language server to make it spec compliant or fork helix and use the builtin lsp architecture to communicate with copilot and integrate it into the ui.

I personally don't use copilot nor have the time to take this on though.

[beyondCritics]

IMHO top notch AI pair programming assistance is a feature which will be totally fundamental for any serious coder very soon.
I really love the helix editor and hope it has a great future, but without coding assistance support i believe it will struggle to get the attention it deserves.

[archseer]

I'll repeat this again: I personally don't use feature so I won't put any work towards it. If you'd like to see the feature then please work on a prototype

[eliliam]

@archseer it seems like this work has already been done in #4037 (comment) with the associated PR #6865. Is this something that you have seen or have any interest in progressing?

[kirawi]

The latter PR introduces non-standard LSP extensions, so it won't ever be merged.

[lynnpepin]

@dead10ck , I hate to say, but I'm typing this in a meeting which implies this very thing: We are expected to use CoPilot. It's being sold as a way to improve security without compromising IP.

To be clear, I don't believe these marketing claims Microsoft is making. I don't like CoPilot, and I'm happy Helix is not maintaining its standards to merge CoPilot. But... The unthinkable meeting has indeed happened :( I found this thread during research on it, to be honest.

[dead10ck]

@lynnpepin oh my. If my company told me they think that having a computer write its own code with no semantic understanding of it will make them "more secure", I would be quite alarmed.

Maybe I'm out of the loop, but I'm under the impression that the value add that most people generally agree upon that AI coding assistants bring is that of productivity and saving time, not that the ML model is capable of generating more secure code than a person. That's quite a bold claim.

[hiAndrewQuinn]

Dropping by to say no Copilot support was, and is, absolutely the dealbreaker for me.

I have one third-party plugin on vim installed and it is Copilot support. That is how absurdly useful and generalizable this tool is to me. I use it everywhere I possibly can, for every kind of language. It is my weapon of first resort.

If Helix supported Copilot I would switch in a heartbeat and never look back. The zero-config experience of Helix is far, far nicer than Vim, and let's not even get into Neovim.

I understand that it does not fit the ethos of the project, and I also understand that you were never crazy about including a plugin system at the start. I am here to let you know that you ignore this feature at your peril. And that if, on the other hand, you built in a :copilot-enable feature, you would massively gain ground, not lose it.

[archseer]

I am here to let you know that you ignore this feature at your peril.

Statements like these exist only to intimidate maintainers into implementing features you want. We aren't interested in market share, we simply work on an editor we personally use!

(or to quote another great writeup)

As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.

If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them.

To repeat myself again: I personally don't use Copilot, and so I won't put any work towards it. You're effectively assigning me days/weeks of work for a feature you want, but are you prepared to work on it?

So far the cohort of users that want Copilot seem willing to make demands, but nobody has actually put any work in (unlike other such features, like the file tree). Until somebody steps up to the plate, things are unlikely to change and no amount of discussion can change that.

[rolanday]

This is a totally fair position to take, but if Helix is just a personal science project accepting feature requests that align only with the maintainer's priorities and interests, then it's hardly a substitute for NeoVim. Respectfully, if want contrib, then best to provide a plug-in model, which is top request / barrier to adoption. But again, if just a personal project, then all good, but I can't imagine why anybody else would want to adopt Helix as their editor of choice -- esp. given deviates from standard vim bindings/motions.

[archseer]

To each their own! It's a standalone editor, you'll notice we don't advertise it as a substitute for anything.

why anybody else would want to adopt Helix

And yet there's lots of us that did!

We are of course working on a plugin system but these things take time. #8675

[rolanday]

Groovy. A plug-in system will certainly go a long way.

[AlexanderDickie]

I've made a draft pr for this- #6865

[textzenith]

I understand things have moved fast, but it's really a key feature for editors in the current day.

Helix is the best — you guys get that modern features should be baked into the editor in an ergonomic way so developers can focus on productivity. Don't just turn around and do the opposite thing with AI! Yes, it's a fast-moving technology with no standard that may have flown in from off the radar (for an opinionated text editor creator, perhaps), but... that's exactly why we need the wisdom of the Helix team in implementing it. I'm confident you cannot only implement this well, but do it better than in any other editor.

Well, with everybody wanting to do something with AI today, hopefully you can find a passionate contributor to take on the challenge. It'd be something to be proud of!

[00sapo]

Not Copilot, but similar. I use this right now in my config and it works. It would be better if I could have a feedback while the command is working in the background:

A-c = [":pipe sgpt --code --temperature 0.3 --no-cache 'Replace this code with a better version and complete it.'"]
A-C = [":sh echo working...", ":pipe-to cat > /tmp/helix-gpt", ":append-output cat /tmp/helix-gpt | sgpt --code --temperature 0.3 --no-cache 'Finish this code. Start typing from where I left.'", ":sh echo done!"]

Based on: https://github.com/TheR1D/shell_gpt

[joshbainbridge]

This is such a great idea! I thought this would be a fun project, so built a small rust CLI that is tailored somewhat to this task, that you can also pass instructions: https://github.com/joshbainbridge/aibro

I'm not a big user of copilot or similar tools, it just doesn't suite my way of working. But this is a great way to have it on hand while still being un-intrusive, and no plugin needed.

On the larger subject, this does appear to be a good candidate for a plugin system. But perhaps many tasks can be simply solved by extending the functionality around pipes and composing CLI tools.

[00sapo]

Building on my other answer, here is a quick way to emulate Copilot with just shell_gpt installed:

C-n = [
  ":insert-output echo '# FILL'",
  "join_selections",
  "extend_line_above",
  "extend_line_above",
  "extend_line_above",
  "extend_line_above",
  "extend_line_above",
  "extend_line_above",
  "extend_line_above",
  "extend_line_above",
  "extend_line_below",
  "extend_line_below",
  "extend_line_below",
  "extend_line_below",
  "extend_line_below",
  "extend_line_below",
  "extend_line_below",
  ":pipe sgpt --code --model gpt-3.5-turbo --temperature 0.3 --no-cache 'Using this code, fill the line having the comment \"# FILL\". Return the whole code, including previous and next lines and tabs as in the input.'",
]

Dependency: pipx install shell_gpt

[kennyishihara]

Using pipe with shell_gpt is actually quite a useful combination! This is a great workaround.

[kennyishihara]

Typically, I just want the copilot/chatgpt to generate a template code and not replace my existing code, so a slight modification to yours worked for me:

[keys.normal]
C-n = [
  "extend_line",
  ":insert-output echo 'FILL_THIS'",
  "extend_line_below",
  ":pipe sgpt --code --no-cache 'Using this comment, fill the line having the comment FILL_THIS.'",
]

Then I write a comment inside my script like

# Write a python code to print hello world

and while the cursor (in normal mode) is on that comment line, I do C-n and then it will fill the comment with the generated code.

Similarly if you want to do it for insert mode:

[keys.insert]
C-n = [
  "normal_mode",
  "extend_line",
  ":insert-output echo 'FILL_THIS'",
  "extend_line_below",
  ":pipe sgpt --code --no-cache 'Using this comment, fill the line having the comment FILL_THIS.'",
]

Thanks again for this!

[blitzarx1]

Ok, I understand that copilot will not be part of helix. But they say we can use copilot lsp https://github.com/TerminalFi/LSP-copilot. Does anyone have working config for this lsp and can somebody explain the current workflow if I want to use copilot in Helix.

[00sapo]

There's a PR for this. You can't run it without some change to the client, so a plugin system is needed

[blitzarx1]

Ok, I see. Thanks!

[DJAndries]

Plugging an LSP code assistant that I've been working on: llmvm-codeassist

It can perform code completions with various models and include context such as type definitions in completion requests.

So far I've only tested it with Helix and Rust.

[peterwilli]

I was actually making my own during the weekend, only to find out you did a way better job than I could do in just a day, I decided to join yours instead and expand from there, expect some PR's!

[efugier]

I did that https://github.com/efugier/smartcat over the weekend. It's not completion but it covers most of my use cases.

It's basically making llms unix citizens so that you can pipe stuff into, and because helix already is a top tier unix citizen they work great together!

E.g. select a function, hit | then sc -p "write tests for the following function" and go. By using the api you also gain access to the latest model, including the gpt-4 preview with 2023 training data, and actual control over what happens.

[blitzarx1]

Ah, ok. Thanks!)

[efugier]

I added a gif of a workflow in my readme, hope that helps.

I just have the default setup (the prompt works quite well with gpt-4-1106-preview !), all you have to do is install it with cargo install smartcat, launch it once (e.g., in the terminal sc -i "what's hello, world! in python") so that it setups the files config file, it will prompt you for your openai api key.

Once you got that working from helix you just have to select some text you want chatgpt to interact with, press the pipe | key and write something like sc -r -c "write tests for that function" and the output of the model will be appended right after your selection in the current buffer. The openai api is a bit slow but apart from that I'm super satisfied with it!

More details are in the readme, I wrote most examples for Vim because it's more popular but it works just the same with Helix, only the shortcut differs 🙂

[efugier]

@CBenoit exactly, it's not a drop in replacement at all but I built it precisely because copilot wasn't available for helix. It works sufficiently well for me with minimal effort, but it's not the same workflow.

[blitzarx1]

Great! Thanks for clarification. I will definitely give it a try

[7flash]

I was thinking in this direction as well, and this is the recent solution I come up with: https://github.com/7flash/helix-chatgpt

[jhugs]

Another tool that's worth playing around with: aichat

[darinkishore]

@efugier Hi! Could you share how you use it in your helix workflow?

[efugier]

Hey @darinkishore! Most of it is described in the readme but basically:

I have a handful of preconfigured prompts for recurring tasks (configurable in $HOME/.config/smartcat/prompts.toml):

• test writting tests for the selected code asking to use the correct framework and parametrize them if possible
• ref refactor and optimize for readability without being too verbose with too many comments
• and by default there's a "pre-"prompt instructing chatgpt to behave as a programmer who's output code is piped right into an editor or the CLI, so that it doesn't not adds the markdown marking or explain it. This default prompt is configurable as well.

Then if you want to write tests for a given function, you can select it in helix, then press | and write sc -r test (-r makes it repeat the highlighted code instead of replacing it).

If you want to refactor the selected function hit | then sc ref.

If you want custom (as in not in your configuration) things done you can use -i and -p:

• sc -i "the program will extend the prompt with this and not read stdin"
• sc -p "the program will extend the prompt with this and then read stdin"

For instance, to iterate on a highlighted function in helix sc -p "add comments to make each step clear", will extend the the default prompt (already telling it to behave nicely as a cli tool with no bloat) with your custom one. sc ref -p "focus on code performances" works in a similar manner, extending the refactor prompt.

If you want a baseline implementation of something sc -i "function to aggregate the column X of a pyspark data in Y manner". Then if you want to iterate sc -e -i "make it more concise" (-e extends the last conversation).

And that's pretty much it. The idea was to have a highly versatile and configurable tool integrating seamlessly in the unix ecosystem, and because Helix is such a great unix citizen already, both work super well together using the helix's pipe feature!

[dariooddenino]

I tried using this for a while, but I find it almost unusable.
It takes several seconds to generate an output, which then requires to be heavily edited to get anything decent.
In the end this takes me more time than writing the code / docs on my own.

Am I doing anything wrong? I'm testing this with the latest gpt4-turbo preview.

[efugier]

The time to answer depends on the input size and the model you are using.

Try playing with those two factors. I use the latest gpt4-preview which can take quite a long time to answer but has great quality and requires the least amount of edits and iterations.

I have no control over the speed of the API but these limitation are part of my workflow and don't bother me. I use the time to think about what's next and not for every task, this isn't really a completion tool.

[leona]

@dariooddenino try 3.5-turbo that's the one copilot uses. And then you need a decent prompt which is a bit of a headache to get right. Copilot also uses a proxy endpoint that makes requests much faster.

[leona]

If anybody is still looking for a solution, I created an LSP assistant to do this here https://github.com/leona/helix-gpt with support for Copilot & OpenAI models

I wasn't really happy with any of the current options, and thought it would be something fun to make. It currently does straight code completion, no suggestions/explanations, and no need to bind any keys.

Right now it uses the completionProvider capability, so displays as a completion dropdown. If Helix adds support for the inlineCompletionProvider in LSP 3.18 then I'll to switch over to that and have the hinting like I've seen in vscode.

The prompt could do with improvements, as it can sometimes include more than what you asked. You can switch to gpt-4 and it would solve it but I personally like the speed and cost of the turbo model.

[lemontheme]

Wow, thank you! Setup was easy, thanks to details like --authCopilot. Suggestions appear relatively quickly and are ranked at the top of the suggestions list. Nice!

There's some functionality in @DJAndries's codeassist that might be nice to see copied over (if that's even possible without Rust), but this is already amazing, and about 10 times easier to set up.

[leona]

Glad you like it! I've seen a lot of people requesting this, and I only recently switched to Helix so this was something I missed as well. Also cheers for the Reddit post.

The suggestions from the openai and copilot chat endpoints were kinda slow and not very reliable at first, but I managed to hook vscode up to mitmproxy and find this endpoint thats made it a million times better, both in the completions themselves and performance.

I'll take a look at codeassist, cheers!

[David-Else]

Could you describe how helix-gpt works, for example, does it understand the context of the file, or maybe the whole project? I am looking forward to checking it out.

[leo-mangold]

Hey this is amazing, I just can't get it to work. I'm a helix noob tho so please excuse my incompetence. This is what I did:

• downloaded the js file and put it in ~/bin/helix-gpt.js
• ran the script with --authCopilot and retrieved my key which i then put into a file: ~/bin/.env
• created a ~/.config/helix/languages.toml file and added the code below
• opened a .ts file in helix
• press ctrl+x to open suggestions (is this how your supposed to do this?)
• and no copilot suggestions shown

When i run bun run ~/bin/helix-gpt.js a process is running without errors and no output.

I also tried to run :lsp-workspace-commands in helix to see if its running but I only see this:

Here are my files:

~/.config/helix/languages.toml

[language-server.gpt]
command = "bun"
args = ["run", "~/bin/helix-gpt.js --handler "]

[language-server.ts]
command = "typescript-language-server"
args = ["--stdio"]
language-id = "javascript"

[language-server.efm-lsp-prettier]
command = "efm-langserver"

[language-server.efm-lsp-prettier.config]
documentFormatting = true
languages = { typescript = [ { formatCommand ="prettier --stdin-filepath ${INPUT}", formatStdin = true } ] }

[[language]]
name = "typescript"
language-servers = [
    { name = "efm-lsp-prettier", only-features = [ "format" ] },
    "ts",
    "gpt"
]

~/.config/helix/config.toml

theme = "amberwood"

[editor]
line-number = "relative"
auto-save = true
color-modes = true

[editor.cursor-shape]
insert = "bar"
normal = "block"
select = "underline"

[editor.file-picker]
hidden = true

[keys.normal]
"ret" = "expand_selection"
"backspace" = "shrink_selection"

~/bin/.env

COPILOT_API_KEY=...
HANDLER=copilot

What am I missing here? Do you know some good ways to check if a lsp is connected and running, or to test the lsp directly?

Thanks in advance!

[leona]

@leo-mangold Would you mind opening an issue in the repo? Just going a bit off topic here I think.

@David-Else I could maybe add some context to the readme alright about how it works. But basically it triggers a completion when any of these characters are pressed ["{", "(", " "] and it has context of the entire current file only. Works pretty much the same as vscode, except without the nice inline completions.

[adriangalilea]

I fully understand the decision not to implement copilot...

But! Perhaps the interface of showing text suggestions can be on Helix so LSP's can use it.

This is generic enough that maybe is better implemented as a primitive natively on Helix, and would improve the DX drastically of using any completion AI.

[sbrow]

I apologize for going a bit off-topic here, but as this seems to have gotten a bit heated, I'd like to bring some positivity to it.

Background

My history of editors (professionally, at least), looks like this:

1. Sublime Text 3? [I think]
2. VS Code
3. Spacemacs (Emacs)
4. PhpStorm (JetBrains)
5. LazyVim (a NeoVim distro)

I am reasonably happy with LazyVim, it gives me a "Full IDE" type of experience, and does pretty well as a polyglot editor. However, it requires an entire repo of configuration files and countless plugins to get it there. Also, I miss emac's TRAMP mode.

I'm always looking for new tools, so when I heard about helix, I had to try it out. What amazes me the most is how similar of experience I can get to LazyVim, with zero plugins, and practically no configuration (Except some keybinds I can't live without, e.g. D). Sure, I could pick nits all day, but when you factor in the young age of helix, it comes out very strong.

I think some of this power comes from its lack of plugins, and more specifically from how it can pick up any LSPs you have in your path and give you configuration-free Language support. I'd love to live in a world where I can simply add helix and the LSPs I need to my projects' flake.nix files, and have a beautiful, ready-to-go IDE wherever I am.

---

Back to Copilot

The things that actually pushed me over the edge moving from JetBrains to NeoVim were:

1. The Copilot support didn't work at the time, and their in-house solution wasn't out yet.
2. It didn't play very nice with nix, nix flakes, and direnv.

So, with that in mind,

As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.

I couldn't agree more! We are humble users of your burgeoning application. We are not clients, we have not bought your product, and you owe. us. nothing.

To repeat myself again: I personally don't use Copilot, and so I won't put any work towards it.

If you have tried using AI assistants and they didn't work for you- fair enough. However, if you haven't given them a solid try, I think you are doing yourself a disservice, as I (and others, it seems) have grown to rely on these tools to save time and keystrokes, which (IMO) is what mode based editors are all about.

You're effectively assigning me days/weeks of work for a feature you want, but are you prepared to work on it?

Again, an incredibly fair point. TBBH at this point in my life, I am too busy with my main job and my side hustle to try and dive in to something like this. However, I see a ton of promise in this project, and I'd love to make helix my main editor.

(TL; DR) The Call To Action

I can't commit time to this project, but I'd be happy to contribute some bounties if that's something the maintainers would be open to. I'd be willing to pay $100 USD, (maybe more), to get this feature supported "out-of-the-box". Whether it be an LSP based solution or whatever- if all I have to do is configure some urls / api keys, I'm happy.

I realize that amount doesn't begin to cover the amount of work that would go into this, but I hope that are some other devs in this thread that would be willing to pitch in enough to make it viable, and worthy of your time.

Either way, thanks for the awesome product! I do think helix's model of editing is "better" than the traditional vim style, and I'm really looking forward to seeing where it goes from here.

Thank You

[t-lock]

@sbrow If one of my clients told me they were "willing to pay" $100 for a custom feature for them, I would probably just fire that client. We charge x rate per hour, for as many hours as it takes to finish a feature, where x is greater than $100, and this is not a feature that can be completed in an hour.

Note: I am not a contributor to Helix, just a user, who is following along with this thread. My attitude doesn't reflect the actual maintainers' attitudes, but I suspect that no one would appreciate the extraordinarily low offer. Its even worse than the whole "I wont contribute / no one will use your project if you don't build the feature I want" people, because you're saying you value their time, but you value it at probably less than one dollar per hour. So much for "bringing positivity" to the thread.

[sbrow]

@t-lock Pretty sure I said that $100 was not enough to cover the feature. The goal was to inspire others that may not want to contribute their time to the problem to maybe pitch in and make it viable. I certainly don't make $100/hr, so it's not like I can waltz in here and drop $5k on a single feature. I looked at what I'm paying for a year of copilot and what I used to pay for PHPStorm, and used that as a guide.

I'm sorry if I offended you. I tried very hard to not be demanding and contribute to the solution in the small way that I could, instead of complaining and walking away like is all too common in open source.

I don't expect anyone in a first-world nation to be solely motivated to complete a feature request for $100. But if everyone who upvoted this thread (77 at time of writing) pitched in that amount, then maybe that would be something. I have no idea exactly how many hours this feature would take, but I believe that is the whole point of a bounty system- you don't have to do anything until the number gets to an amount that motivates you.

[mukund109]

I would also be willing to pay $100 a year.

[blitzarx1]

I am in the team of payers!

[adriangalilea]

I would also add to the bounty

[lemontheme]

I use Helix fulltime in a professional context. There are a few things I miss from previous editors/IDEs but, since I'm already in the terminal, I can usually find a satisfactory work-around.

Seeing my colleagues with AI code assistants write boiler plate code at a fraction of the time it takes me, however, makes me question if I'm doing myself – or rather, the thing I'm paid for: my productivity – a disservice.

That said, I think this thread collectively underestimates how much tweaking actually goes into an actually useful AI code assistant. I'm talking AST parses of the code, tons of prompt engineering, potential re-prompting for consistency, output validation. Then there are the more obvious steps, like integrating with a broad set of (mostly proprietary) LLM web APIs. There is some standardization on the OpenAI spec (which is kind of a win, except for giving OpenAI disproportionate say in shaping the future of LLM APIs.) Also, it's a moving target, obviously.

The way I see it, this thread can/should be split up into several related, but separate discussions:

1. No, integrating with Copilot directly is out. It's a proprietary tool that goes against the open spirit of Helix. It's developmental history is fraught. Why should the Helix team volunteer time toward expanding Microsoft's – or, at that, any proprietary company's – reach? On the contrary, the approach that makes most sense to me is BYOLLM – Bring Your Own LLM.

2. Helix's code interface could benefit from several additions that would make LLM completions work better, e.g. multiline suggestions, triggering completions, smartly canceling completion requests, Q&A actions.

3. The most tricky part: How should LLMs be interacted with? Over what interface? What I find telling, for instance, is that most vim/nvim plugins for AI code completion do not use an LSP. Why is that? What are we missing if we rely solely on LSPs? To this end, attention could be paid to open-source projects such as https://github.com/huggingface/llm-ls/ (which is an LSP) or https://github.com/DJAndries/llmv (which I've been meaning to test for ages, except the setup is somewhat intimidating).

Probably even this categorisation doesn't cover everything.

I'd love to see progress on this topic. AI code assistants aren't going away, I think. Their usefulness today can absolutely be debated, as can their copyright issues, certainly – but it's getting harder to ignore them.

We can't expect the core Helix team to pick up this immense task on their own though. We need a way to split it up so that we can all contribute some piece of the puzzle.

[adriangalilea]

Spot on,

Which is why I advocate for the interfaces/api's required by an LLM, most notably for me, "ghost text suggestion" + tab for auto-complete. A conversation with an LLM I can have in a tmux popup or what have you, but the text suggestion feature will be everywhere and used by present and future coding assistants, such feature I argue, should be in the core, so that any coding assistant can make use of it when giving support to helix through plugins or otherwise.

#10259

[kirawi]

Realistically, developing a standard is something major companies pushing LLMs should be responsible for. Particularly Microsoft since they're heavily pushing Copilot and they developed the LSP & DAP protocols. It's at least as much work as developing Helix is (IIRC).

[kirawi]

However, there would be room for contributions to the plugin system after the initial PR is merged to make a potential LLM plugin more ergonomic to use (e.g. the API exposed is minimal for the MVP PR)

[MatrixManAtYrService]

I sort of wonder if "in" the editor is the way to go here. I'm imagining some frame "around" the editor, in the style of tmux or zellij (or perhaps as a zellij plugin).

This way the AI could consider more than just the editor contents:

• test results
• logs
• shell sessions
• debugger output
• profiler output
• your notes about what you're trying to achieve and what you want help with

You'd want to specify which panes contain context that you want considered, which one has the editor that you want suggestions in, and where to put the suggestions until they're accepted. Most of this could be editor agnostic, although you might want a plugin for the editor which:

1. makes the full contents of the open files available, not just the visible parts
2. indicates which parts are visible, and which are selected (selecting a region could trigger suggestions for replacement of that region)
3. applies the suggestion once it was accepted by the user

So the frame need not change the way the editor looks at all. The content of the suggestion would appear nearby, and a hotkey would apply it to the open file.

This means doing much less on a per-editor basis. A dedicated and standardized suggestions API, via plugin or otherwise, would be nice, but the other option is that the AI could just write chars to /dev/tty and apply the suggestion in the same way that a human would.

[ShaddyDC]

Those are some intriguing ideas! On the other hand, you already mention that potentially more than the currently-visible portion of the code is relevant. What about the files that aren't currently open? Shouldn't potentially the entire project be available as context?
That again speaks in favour of a tighter integration, where the copilot can directly communicate with the test runner and the project folder and everything else, because you're not getting the entire project from the terminal.

I do not know what the right approach here is, but wrapping the terminal seems limitting, assuming it's not just one of multiple input feeds.
Then again, you'll have to make the tradeoffs somewhere.

[mikkelfj]

I agree that a larger context is needed, as I believe I already state somewhere earlier on.

• Helix doesn't really have a project concept making it non-trivial to cover data beyond currently open files.
• LSPs do provide some sense of project overview anyway, e.g. via compile_commands.json [1], so it is possible.
• LLMs do not have large enough context windows yet, but it is changing.
• Terminal tooling is not very good UI, especially not wrt. current editing context.

This suggests that Helix should be able to do something similar to LSPs to get a larger context for AIs, and that AIs that only look at the current code snippet to generate something like standard code for a SQL prepare statement or whatever, is ridiculously limited.

I don't think LLMs like GPT-4o is up to any kind of creative support yet, but they do understand context can help with trivialities if the get the right information and instruction. Getting the right information in the right amount is the real problem here, but likely solveable. LLama3 with 8b parameters which are practical to run locally, simply experiences instant amnesia if you feed it too much context.

[1] https://clang.llvm.org/docs/JSONCompilationDatabase.html

[7flash]

I agree that a larger context is needed, as I believe I already state somewhere earlier on.

• Helix doesn't really have a project concept making it non-trivial to cover data beyond currently open files.
• LSPs do provide some sense of project overview anyway, e.g. via compile_commands.json [1], so it is possible.
• LLMs do not have large enough context windows yet, but it is changing.
• Terminal tooling is not very good UI, especially not wrt. current editing context.

This suggests that Helix should be able to do something similar to LSPs to get a larger context for AIs, and that AIs that only look at the current code snippet to generate something like standard code for a SQL prepare statement or whatever, is ridiculously limited.

I don't think LLMs like GPT-4o is up to any kind of creative support yet, but they do understand context can help with trivialities if the get the right information and instruction. Getting the right information in the right amount is the real problem here, but likely solveable. LLama3 with 8b parameters which are practical to run locally, simply experiences instant amnesia if you feed it too much context.

[1] clang.llvm.org/docs/JSONCompilationDatabase.html

Here is my solution: https://github.com/7flash/gurrai

• Terminal tooling is not very good UI, especially not wrt. current editing context.

Its the best, better than any visual text editor, gurrai creates a new file for every prompt, opens it in helix, then writes response into a new file, and opens it with helix

• LLMs do not have large enough context windows yet, but it is changing.

You can select part of file to be included into your prompt with file:./path.txt#title

• LSPs do provide some sense of project overview anyway, e.g. via compile_commands.json [1], so it is possible.

Since every prompt is a file, you can dynamically generate them to include output of lsp or linter commands

• Helix doesn't really have a project concept making it non-trivial to cover data beyond currently open files.

gurrai allows to reference local files relative to closest "prompts" directory and package.json by adding file:./path into prompt and it will be resolved to file content, or file:/ for absolute paths

[JuHyung-Son]

Unfortunately, without this feature, helix will just be another old editor. Users who came over from vim will go back to vim(including me). Look at the huge number of users that cursor has created just by having a good integration of llm.

[tafia]

Helix is awesome and definitely doesn't feel like "old" to me.
I have a mixed feeling about copilot, sometimes it is good sometimes not. Getting better though but I am not sure I'd call it a killer feature at all compared to kakoune style and the no-plugin experience helix provides.

[storopoli]

Farewell and Good Riddance!

[formbook]

I don't know what goes into supporting the likes of copilot and supermaven, but Neovim seemed to do it pretty easily. I could be wrong, but it seems to me that it's a philosophical rather than a technical decision to not integrate what is arguably the biggest text editing innovation in our lifetime.

It means I can only use helix for the odd config editing and not on my real projects because the automation of boilerplate is a convenience I can't go without now that it's standard in every major editor. I don't use any of the built-in chat garbage, if I want anything like that I will use the LLM websites.

I think copilot and a telescope like live search grep is all thats missing from helix being a real option for software development and I don't understand why it's not a priority, unless you don't care about getting more users which is fair enough. Thankfully Zed exists in the meantime.

[MatrixManAtYrService]

The difference is that neovim already had a mature plugin system when copilot was invented. I expect that if you proposed that neovim integrate directly with copilot, you'd get similar pushback. They'd be saying "we have a plugin system so that we don't have to maintain integrations of that sort".

it seems to me that it's a philosophical rather than a technical decision to not integrate

If you want a philosophical distinction, maybe look at the things that Helix has prioritized instead of a plugin system? I really don't think this about pro vs anti LLM sentiment. Even if there might be some of both lying around here and there, the blocker is technical: The helix plugin system is not ready, and integrating without the kind of decoupling that a plugin system provides is madness.

(disclaimer: I don't speak for anybody, these are just the feelings I get from lurking here and there)

[kirawi]

The above is true, but from what I've read, it's also not trivial to write a great integration either. There is the standardization issue, of course (even beyond the API, e.g. in how the instruct models are finetuned for particular structured formats). And with the fast-moving pace of LLM research/techniques, it just fundamentally clashes with the methodical approach taken for core features. Even if we could write a decent implementation, I don't think we're interested in half-measures since those are better fit for plugins.