Sublime Text: Port works only on small examples

[LDAP]

Hey,
I created a Sublime Text Plugin LDAP/LSP-ltex-ls which is using the LSP client plugin and your language server to provide language checking for latex and markdown in Sublime Text.

It is already working for little examples:

But it stuggles with only little more complex examples like:

%!TEX root = ../proposal.tex

This is an \textbf{test}.

% LTeX: language=de-DE
Das ist eine \textbf{Test}.

Das is eine falsche Satz.

In this case the Server does not send any textDocument/publishDiagnostics.
I attached the log for the above example.

lsp.log

--> outgoing request (to the LS)
<-- incoming request (to us)
-> outgoing notification
<- incoming notification
<<< incoming response to some previous outgoing request
>>> outgoing response to some previous incoming request
~~> outgoing error response to some previous incoming request
<~~ incoming error response to some previous outgoing request

---

The currently supported LSP capabilities in sublime can be found here. I implemented the extensions for progress and workspaceSpecificConfiguration.

---

I observed, as soon as I correct any spelling mistakes myself (above is -> ist) the grammar check begins to work again.

---

This may be unrelated but I got this message from time to time:

:: <~~ ltex-ls 31: {'message': 'Internal error.', 'data': "java.util.concurrent.CompletionException: java.lang.NoSuchMethodError: 'java.util.List org.languagetool.markup.AnnotatedText.getMapping()'\r\n\tat java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)\r\n\tat java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)\r\n\tat java.base/java.util.concurrent.CompletableFuture.biApply(CompletableFuture.java:1309)\r\n\tat java.base/java.util.concurrent.CompletableFuture$BiApply.tryFire(CompletableFuture.java:1276)\r\n\tat java.base/java.util.concurrent.CompletableFuture$CoCompletion.tryFire(CompletableFuture.java:1215)\r\n\tat java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)\r\n\tat java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2137)\r\n\tat org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleResponse(RemoteEndpoint.java:212)\r\n\tat org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:193)\r\n\tat org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:194)\r\n\tat org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)\r\n\tat org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)\r\n\tat java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)\r\n\tat java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)\r\n\tat java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)\r\n\tat java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)\r\n\tat java.base/java.lang.Thread.run(Thread.java:832)\r\nCaused by: java.lang.NoSuchMethodError: 'java.util.List org.languagetool.markup.AnnotatedText.getMapping()'\r\n\tat org.bsplines.ltexls.parsing.AnnotatedTextFragment.getSubstringOfPlainText(AnnotatedTextFragment.java:41)\r\n\tat org.bsplines.ltexls.languagetool.LanguageToolRuleMatch.<init>(LanguageToolRuleMatch.java:47)\r\n\tat org.bsplines.ltexls.languagetool.LanguageToolRuleMatch.<init>(LanguageToolRuleMatch.java:30)\r\n\tat org.bsplines.ltexls.languagetool.LanguageToolJavaInterface.check(LanguageToolJavaInterface.java:154)\r\n\tat org.bsplines.ltexls.server.DocumentChecker.checkAnnotatedTextFragment(DocumentChecker.java:131)\r\n\tat org.bsplines.ltexls.server.DocumentChecker.checkAnnotatedTextFragments(DocumentChecker.java:67)\r\n\tat org.bsplines.ltexls.server.DocumentChecker.check(DocumentChecker.java:194)\r\n\tat org.bsplines.ltexls.server.LtexTextDocumentItem.lambda$check$2(LtexTextDocumentItem.java:422)\r\n\tat java.base/java.util.concurrent.CompletableFuture.biApply(CompletableFuture.java:1307)\r\n\t... 14 more\r\n", 'code': -32603}

[valentjn]

I'll use this issue to respond to your e-mail as well. First, let me start by saying I'm very happy that LT_EX might be used for other editors than VS Code.

You have probably noticed that up to now, LT_EX LS has not been developed with other language clients than vscode-ltex in mind. Hence, its development has been kind of rough:

• The semantic versioning was only adhered to by vscode-ltex. LT_EX LS always took over the version from vscode-ltex. Consequently, breaking changes (i.e., changes that would break other language clients than vscode-ltex) could occur in non-major-point releases.
• There's a lot of documentation missing (readme, changelog, etc.).
• The, let's say, “proprietary” LSP extensions you mentioned lead to incompatibilities with vanilla language clients. (Their implementation was mainly driven by user demand for features in vscode-ltex. I'm not a fan of those extensions as they pretty much defeat the purpose of the LSP.)

I can try to improve the first two points, for instance by decoupling the versions of language server and client, and by adding some documentation.

The third point is of course harder to fix properly; the best way (apart from avoiding extensions altogether) would probably be to announce support for extensions in the LSP server/client capabilities during initialization, and to fall back to some vanilla mode if they are not supported. By the way, ltex/progress might be obsolete now that LSP progress notifications are supported by LSP4J.

Now to the actual issue: The message at the end of your post with the Internal error hints to a classpath problem. lib/ltexls-languagetool-patch-<LTEXLSVERSION>.jar needs to be loaded before lib/*. LSP-ltex-ls only seems to load lib/*, which means that this will fail non-deterministically (as the order of elements of a wildcard is unspecified). Note that LT_EX LS is supposed to be started with the startup scripts in bin/. Amongst other things, they take care of the classpath.

[LDAP]

The, let's say, “proprietary” LSP extensions you mentioned lead to incompatibilities with vanilla language clients. (Their implementation was mainly driven by user demand for features in vscode-ltex. I'm not a fan of those extensions as they pretty much defeat the purpose of the LSP.)

I actually did already implement those extension. I do process the progress messages and on workspaceSpecificConfiguration I answer with a empty message, since in sublime users can overwrite settings directly.

Now to the actual issue: The message at the end of your post with the Internal error hints to a classpath problem. lib/ltexls-languagetool-patch-.jar needs to be loaded before lib/. LSP-ltex-ls only seems to load lib/, which means that this will fail non-deterministically (as the order of elements of a wildcard is unspecified). Note that LTEX LS is supposed to be started with the startup scripts in bin/. Amongst other things, they take care of the classpath.

This did solve everything. LTEX for sublime is working now 🎆 . I did wonder before how you inject the patch into the classloader - now I know.

[LDAP]

I can try to improve the first two points, for instance by decoupling the versions of language server and client, and by adding some documentation.

Maybe in such case you can mention me in the commit/pull-request? I'll give my best to resolve the issues on sublime side.

[valentjn]

All of the points I mentioned should be improved now.

• LT_EX LS will adhere to Semantic Versioning from 9.0.0 on. Be careful in the future when updating to a new major-point release.
• There's now some documentation in the readme.
• LT_EX LS should be LSP-compliant again. ltex/progress has been replaced with LSP's $/progress (see Use serverInitiatedProgress instead of custom notifications #34), and ltex/workspaceSpecificConfiguration is now opt-in at initialization.

[LDAP]

Nice work. Gonna try 9.0.0 tomorrow with sublime.

[valentjn]

9.0.0 has been released, the points I mentioned are now fixed.