Eclipse Community Forums: TMF (Xtext) » XText to VSCode integration

Home » Modeling » TMF (Xtext) » XText to VSCode integration

XText to VSCode integration [message #1829840]

Sun, 12 July 2020 16:15

Eclipse User

I have an implemented LSP via XText running in a VSCode extension that also works with eclipse with icons, labels etc, but unfortunately all the symbols look alike in VSCode.

When I've done an implementations with antlr4 solely I have change the symbols by via the LSP protocol by creating SymbolKinds or DocumentSymbols, but I haven't yet found out how to do that via XText. How do I change them depending on the type of the node?

Re: XText to VSCode integration [message #1829879 is a reply to message #1829840]

Mon, 13 July 2020 07:18

Eclipse User

hi, simply customizing and binding DocumentSymbolKindProvider does not work?

Re: XText to VSCode integration [message #1829890 is a reply to message #1829879]

Mon, 13 July 2020 09:10

Eclipse User

Right, thanks! Am I on the right track thinking that would require me to do the binding in the "*.ide" package in the class that extends the DefaultIdeModule class? And also to put some additional package on the classpath so it has access to the SymbolKind class? (I didn't find much information about this when searching the web. But I guess it's down to get to know Guice DI style a little better.)

Re: XText to VSCode integration [message #1829892 is a reply to message #1829890]

Mon, 13 July 2020 09:32

Eclipse User

The dependency should already there as well as yourdslidemodule
If you don't use pure maven or gradle you may have to add the transitive lsp4j dependency explicitly to MANIFEST.MF

[Updated on: Mon, 13 July 2020 09:35] by Moderator

Re: XText to VSCode integration [message #1829905 is a reply to message #1829892]

Mon, 13 July 2020 12:28

Eclipse User

Thanks! I know how to do this now. I just need to get past the dependency issue. (It can run the editor via eclipse with the changes in MANIFEST.MF, but the jar running via the vscode extension has problem finding the SymbolKind class I provided in my customized DocumentSymbolKindProvider class).
It started out as a clean maven project but somehow must have gotten this messed up along the way.

[Updated on: Mon, 13 July 2020 12:29] by Moderator

Re: XText to VSCode integration [message #1829910 is a reply to message #1829905]

Mon, 13 July 2020 14:38

Eclipse User

it should work with pure maven and gradle out of the box.
if you use eclipse/maven tycho you need to adapt the manifest.
in all cases there should be no problem to have the custom DocumentSymbolKindProvider + a dependency to org.eclipse.lsp4j (in the manifest case you need to install/add lsp4j to the target platform.

so what is exactly missing from the jar(s) you are running in vscode?

Re: XText to VSCode integration [message #1829925 is a reply to message #1829910]

Tue, 14 July 2020 04:58

Eclipse User

I got it working!

About the old issue: I tried but can't reproduce the old stacktrace. The only issue I had this time around was of the compile version of the classes (where I got complaints about Guice being compiled with version 54 instead of the compatible 52), so I compiled with 1.8 and then it went fine. (I don't mind using java 8 since I'm so used to that anyway.)

This should perhaps be a separate post but I'm not sure I feel this is a problem I need fixed. It's just that I see the default structure is to create the outline with dots for the children nodes instead of actually putting them into their parent node while populating the outline, so I get an outline looking like this:

object
->properties
  ->properties.object
    ->properties.object.property

instead of an outline looking this:

object 
       ->properties
            ->object
                 ->property

But I guess the solution here is the equivalence of what I did before and I this time I need to bind HierarchicalDocumentSymbolService to my own implementation and restructure the hierarchy to my taste (i.e trimming the name prefixes)?

[Updated on: Tue, 14 July 2020 04:59] by Moderator

Re: XText to VSCode integration [message #1829928 is a reply to message #1829925]

Tue, 14 July 2020 05:06

Eclipse User

binding DocumentSymbolNameProvider I mean... that seems to be even less work :)

Re: XText to VSCode integration [message #1829929 is a reply to message #1829928]

Tue, 14 July 2020 05:16

Eclipse User

which one is used for you
if (isHierarchicalDocumentSymbolSupport()) {
return serviceProvider.get(HierarchicalDocumentSymbolService.class);
} else {
return serviceProvider.get(DocumentSymbolService.class);
}
}

Re: XText to VSCode integration [message #1829931 is a reply to message #1829929]

Tue, 14 July 2020 06:02

Eclipse User

Ok, I think I see that the server provides both of these and that you are free to choose by configuration. I'm not sure since I don't debug the jar while running it through the extension in vscode. This seems to be read in through the client capabilities options via json config, right? I don't see where I should provide that setting in the extension. Or should that be set in the server?

Re: XText to VSCode integration [message #1829932 is a reply to message #1829931]

Tue, 14 July 2020 06:11

Eclipse User

as far as i understand that is something the client decides.
for testing. you can configure the extension to connect to the server via socket
https://github.com/itemis/xtext-languageserver-example/blob/master/vscode-extension/src/extension.ts

and start the server from eclipse in debug mode
https://github.com/itemis/xtext-languageserver-example/blob/master/org.xtext.example.mydsl.ide/src/org/xtext/example/mydsl/ide/RunServer.java

Re: XText to VSCode integration [message #1829933 is a reply to message #1829932]

Tue, 14 July 2020 06:21

Eclipse User

Nice! That will for sure make things easier. I'll set it up!

Re: XText to VSCode integration [message #1830477 is a reply to message #1829933]

Mon, 27 July 2020 10:17

Eclipse User

Sorry for not answering this right away. I got occupied with other bugs more important to fix. It seems like the default is HierarchicalDocumentSymbolService.class. It was a bit hard to debug though since I didn't have the sources for the classes in the project. But could at least see file and row so I figured it out.

For anyone else reading this the solution to the above problem of not getting a simple name instead of a qualified in the outline of say vscode, it is fixed easily by adding the SimpleNameProvider to the IDE module, e.g:

	
public Class<? extends IQualifiedNameProvider> bindIQualifiedNameProvider() {
		return SimpleNameProvider.class;
}

I'm not sure why it isn't configured by default but maybe there's a good reason for that.

[Updated on: Mon, 27 July 2020 13:46] by Moderator

Re: XText to VSCode integration [message #1830488 is a reply to message #1830477]

Mon, 27 July 2020 14:38

Eclipse User

The answer might be: there are more usescases withqualified name than with simple name. Thus the default was changed with Xtext 2.0
(Qualified NameProvider is primarily used for scoping)

[Updated on: Mon, 27 July 2020 14:41] by Moderator

Previous Topic:	Generating multiple objects within one rule
Next Topic:	Adding attributes to a references element

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 26 00:24:29 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter