What about text suggestion support?
#10259
|
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. Originally posted by @adriangalilea in #4037 (comment) |
Replies: 2 comments 23 replies
|
lsp has completions which can support that, we are not adding lsp extensions to core |
|
Sorry, not sure if I understand what you are saying or if you misunderstood me. Helix-gpt gives me this: Which is what I think you mean by completions. What I'm saying is having baked in helix something that allows for inline suggestions/autocomplete text(dimmed) like I showed in the initial message. This is something that can be leveraged by other any completion LSP, having a dropdown/window is fine for alternative options, but the inline text is the optimal DX. Just to clarify, I don't want copilot or any particular provider, what I want is a better interface for any completions flow. |
|
Yes but there isn't an extension for this behavior specifically. Maybe it could be implemented in a hacky way by the LSP by using inlay hints but I'm not sure. |
|
While copilot or other current llm completions providers may come and go, the interface of text suggestion will be ubiquitous. I don't know if that level of smooth integration would be possible with plugins. And even if it was, consider the amount of LLM completion providers there will exist, do you want to offload them the task of rebuilding the text suggestion inside the editor every time? I think is worth considering having that baked into helix to allow that integration to whatever needs to use it more easily, perhaps create some sort of new standard.
I don't think LSP's are the way to go for this kind of feature, LSP's are for a specific purpose, that kind of text is for text suggestions. I understand this is not easy and you guys have other priorities, I sympathise and agree with your negation to integrate copilot, but I want you to consider this. |
|
AFAIK the maintainers have no interest in implementing non-standard APIs like that. What you're proposing sounds pretty niche too. Stuff like that is intended to be implemented by plugin developers once the plugin system lands. |
|
Though we don't have some way to plug an external thing to render inline we do have the capabilities in tree to render inline for things like inlay hints and soft wrap so it should be possible to expose the APIs to plugins once we have that |
Could be, even tho it doesn't seem like it now, it'll be obvious in retrospect. LLM's have been around a year, it's arguably the most rapid adoption on history, niche for now perhaps, standards are yet to be made. And if something is shaping up as a standard is that, you have it in gmail, you have it in copilot, and it feels very smooth.
The majority of programmers will use AI, text suggestions is one of the nicest flows for it and relying on a plugin for something the majority will need may create friction on the adoption of new providers, thus my argument for having that baked in. Of course, that can be done via plugins, I'm just saying that it may be a better idea to have it in the core. But it's alright, this is just my opinion, wanted to bring it up and see what other people thought. Thanks for chiming in regardless |
|
As far as I've seen, AI has only taken off for webdev (it's unusable/unreliable for systems-level languages even for simple functions in my experience). I just don't see it being widely adopted by professional software engineers outside of that because of many reasons beyond just practical use, e.g. explainability which all LLMs lack at the moment (someone also has to verify that the AI wrote the code well, and at that point you may as well have written it yourself). One of my past professors who has her phd in ML and actively follows LLM papers emphasized those ethical liabilities/concerns which could lead to legal issues as major blockers for adoption. Maybe in a few decades something will come up with that ability, but perhaps AI can be left to the post-post-modern text editor at that point :P (this is just my opinion) |
|
Have you used copilot in vscode? Professional programmers use it already, the main blocker for some parts of the industry is precisely the subpar DX on alternative editors, copilot is not chatgpt. I think you are confounding those, there's no need for explainability, copilot, in way too many instances feels as if it reads your mind, you just type out the start of a function, and in an instant you have that predictive text that more often than not is a perfect implementation of what you wanted to do. I don't think there is any logical reason not to use it, it saves you way too much time on boilerplate and you can focus on tackling the real problems, and the main reason for how amazing it is is the text prediction interface that you can tab to complete or decide to ignore, is not intrusive. |
|
Closing the loop on this two years later, since the pieces finally exist: First, credit where due: @devmanuelli already implemented
This is how it looks
One datapoint for #14876: I arrived independently at the same Not re-litigating core inclusion, just leaving the trail for whoever lands inlineCompletion support: the rendering primitive and the protocol are cleanly separable, and separating them is what made this buildable outside core at all. |
AFAIK the maintainers have no interest in implementing non-standard APIs like that. What you're proposing sounds pretty niche too. Stuff like that is intended to be implemented by plugin developers once the plugin system lands.