[Language Server] Hover needs to improve as xtext-eclipse.

[chetanladdha]

As for Xtext language server, Hover works only for the documentation section. For eclipse, hover gets provided at many places. We are not getting any advantage by Xtext grammar. At least it should be configurable where with the configuration we can select the eclipse behavior or different behavior.
I would like to understand sense to have hover only for documentation section.

Do we have any plan to make things separated and common for eclipse and LSP?

[cdietrich]

@svenefftinge what do you think

[svenefftinge]

I think with org.eclipse.xtext.ide.server.hover.HoverServicewe have a hook to do what ever you want in hover. I understood the feature request is about having a better default impl, that does also provide a signature. TBH I think it needs to be custom in most cases anyway so I would prefer to keep it as simple as it is.

[chetanladdha]

As per my understanding, hover related code is not Eclipse independent. Can we access/make the hover related code eclipse independent? Also, same request valid for most of the other features.

[cdietrich]

I don't get your point. It costs you ten lines of code to get the same behaviour as in eclipse

[chetanladdha]

Yes, I understand that. I mean if we have common code eclipse independent code for LSP and eclipse then it gives more consistency. Also, in a case of a custom feature, we don't need to maintain two codebases.

When Xtext generates the LSP, it needs to be an exactly same way to Eclipse. Why is this not true?

[cdietrich]

of course that is true, but not everything can be united, at least it has no high priority or can be done simple. e.g. i dont know what you customized implemented in eclipse for the hover.

• did you customize IEOjectDocumentationProvider
• did you customize Label Provider (api is eclipse and html dependent and cannot be used for lsp)
• did you implement nothing and just want the Greeting World first line, that can be easly manually implemented

[kthoms]

It is true that code that is Eclipse independent UI beahvior could be refactored to the IDE project. However, due to backward compatibility classes in Eclipse code must stay, but could derive from a generalized version in the .ide project.

Pull requests are welcome here.

[svenefftinge]

Ah, now I understand your request.
So the general strategy I would like to follow here is the following:

• we come up with new abstractions in the (UI-independent) IDE part.
• keep existing Eclipse hooks and implementations (for compatibility reasons)
• implement another Eclipse-specific implementation that delegates to the new IDE hook

The last item is what is missing and what you were asking for, right?
Also related is eclipse/xtext-eclipse#139 on which you already have commented :). So we want to do it but will work on it case by case and probably only cover the most important hooks (that is content assist, is a bit higher on the list than hover, although more complicated, too)

[chetanladdha]

Yes @svenefftinge, I am exactly requesting for last item.