Add extension point for LS definition
Closed this issue · 17 comments
I think that to support different language servers we need a easy and programmatic way to define it. Such extension should give ability to spawn LS and match it with content type. Maybe should also give a place to define LS configuration.
Additional plugin per LS can be a place where content type can be defined and most probably syntax highlighting. Also actual implementation doesn't give an option to support more advanced case like TCP communication instead of stdin/stdout.
Also do you have any plan for cases where I have extended the protocol itself with something, I want to enable on the client side?
E.g. in this example [1] we have a special action, that sends an 'evaluate' request to the language server and displays it inline (CTRL + ENTER). Can you imagine how I would do that with Eclipse's LSP support?
@svenefftinge This is an interesting issue. I will also want to use an extended protocol in the future.
Is it necessary to have support for this in the basic LS support? The simple way to handle this is to "just" implement the action and let the handler talk with the server. I'm not sure what advantages one would have by doing it with an extension point or similar, given that a handler is needed anyway to process the answer.
@mniewrzal +1. Currently, all happens on preferences. See the examples in org.eclipse.languageservice.languages bundle that initiate language server (in a not very elegant way).
@svenefftinge Please open a separate issue for that.
Done #97
Any idea when this will be merged into master? I would love to use the extension point that got introduced in the commit mentioned above (in Michals fork)
I see, understand... Any ETA? (wild guess maybe)
Not really, it's more up to Eclipse IP team. A first iteration was already reviewed and I pushed an update containing legal "fixes" earlier today. I hope I'll hear again about it before the end of the week, then patches should be merged.
About extension points in general, I'd like to take advantage of the incubation status for some time before making them stable and API, so they could still evolve, even in a non-backward compatible way, for some time.
Such changes would be announceds on the lsp4e-dev mailing-list.
Sounds all good, thanks for the update. I will watch out on the lsp4e-dev list for further updates.
@martinlippert btw, do you have any comments about extension point structure? Is it easy to use it for integration with your language server?
Yes, it looks nice to me. Will play with it in the next few days and let you know about my experiences.
I am playing with the extension point from the fork at the moment and it looks good to me. Great work.
Change merged in LSP4E: https://git.eclipse.org/r/86026 . Thanks!
Great news!!! :-)
Is there already a continuous p2 repo being published anywhere?
That is great, thanks!!! Contributions from now on via Gerrit, I guess?
Yes