Investigate opportunities for asynchronous operation (at least eye-candies)

[mickaelistria]

Connection with a language server is asynchronous. However, in most cases, the operations happen in the UI Thread and wait (with timeout) for the Language Server to respond. This freezes the UI.
We should investigate opportunity to introduce better support for asynchronous operations in the supported operations.

[angelozerr]

I'm in the case of my JSON server which is started with launch VSCode-JSON doesn't give response (I don't know why?). It means that this code freeze Eclipse and I must kill it after:

CompletableFuture<InitializeResult> result = languageClient.initialize(initParams);
try {
    initializeResult = result.get();
} catch (InterruptedException | ExecutionException e) {
    e.printStackTrace();
}

See https://github.com/eclipselabs/eclipse-language-service/blob/master/org.eclipse.languageserver/src/org/eclipse/languageserver/ProjectSpecificLanguageServerWrapper.java#L196

It should be better to use get with a little timeout (and try several time). This timeout + number of test could be customized with eclipse preferences. We could display too a popup to the user when timeout + number of test is done "Do you want to continue to wait?". The open (or not) of the popup could be too an eclipse preferences.

[mickaelistria]

Note that with use-case #39 being fixed, this is likely to become more easily detected when debugging a language-server: the Eclipse IDE will freeze if a breakpoint happens in a synchronous operation of the UI Thread.

[bruno-medeiros]

Spawn a background thread, await the output there, and meanwhile present a progress dialog to the user?

This is a problem already addressed in MelnormeEclipse, see https://github.com/bruno-medeiros/MelnormeEclipse/blob/master/plugin_ide.ui/src-lang/melnorme/lang/ide/ui/utils/operations/AbstractUIOperation.java and related classes. All common editor operations that rely on external tools (such as code completion, open definition, formatting) are based on AbstractUIOperation which spawns a background thread to await the output of the external tool. The UI doesn't freeze but a modal progress dialog is presented. (but only if the operation takes too long, more than 200ms or so, since it uses the workbench's org.eclipse.ui.progress.IProgressService.run(boolean, boolean, IRunnableWithProgress) )

The other aspect of doing things this way is that futures should be awaited by means of polling, using the java.util.concurrent.Future.get(long, TimeUnit) API, so that monitor cancelation can still be checked and responded to.

[mickaelistria]

The scope of the issue was more about really supporting asynchronous non-blocking work. Showing a progress report doesn't make it really asynchronous, as user is still stuck, it's "only" giving an eye-candy.
That said, eye-candies are much better than freezes, so yes, that would be good to have those where it makes sens.

[bruno-medeiros]

Well, it depends on the operation. If it's code completion or find definition there is really no point in doing anything other that a (delayed-start) progress dialog. You could technically do it completely asynchronously and not block the workbench with a dialog, but that would be super weird - if the user edits the source it would invalidate the background operation. Or even if the user didn't modify the source, but just navigated around, when the operation completed it would show a completion popup, or move to a different file/location out of nowhere, etc. ...

[mickaelistria]

Those topics are actually part of what I imagine in supporting asynchronous: start compoutation, do not block user (let them change to another line column if that's what they want) and then when result is received, decide whether to show them or not according to whether the current state has changed.
For some operations, this is not even doable at the moment because of Eclipse Platform doing it all in the UI Thread.

[bruno-medeiros]

Let me correct my previous statement: code-completion makes sense to block the UI with a progress monitor when code completion was invoked explicitly. If it invoked automatically (because user types . for example) then yeah, makes more sense to never show progress dialog (and invalidate if source changed in the meanwhile). I didn't even think about previous case since I was never a fan of auto-invocation, usually have it turned off. But a lot of users like it.

For some operations, this is not even doable at the moment because of Eclipse Platform doing it all in the UI Thread.

What operations are those?

[mickaelistria]

@bruno-medeiros completion for example is requested in UI Thread IIRC, so it's tricky to have it fully asynchronous. https://bugs.eclipse.org/bugs/show_bug.cgi?id=251156
If you have some time to contribute progressDialogs in place of freezes, that would be welcome ;)

[mniewrzal]

Another place where non UI blocking behavior would be welcome :)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=506467

[mickaelistria]

Replaced with https://bugs.eclipse.org/bugs/show_bug.cgi?id=508457