Progress messages

[WhoIsSethDaniel]

Any chance for progress messages? Even something as simple as 'I am initializing', 'I am done initializing', 'I am formatting', 'I am done formatting' would be great.

The reason for this is that it isn't always clear, upon start, when the server is ready to start doing things. Also, for formatting (and similar tasks) I don't know if the server is doing something until suddenly my code changes. This can take awhile with perltidy and perlimports.

[bscan]

Hi Seth. I'm curious how long the Navigator is taking on startup. Normally, I'd expect it to be pretty fast. Below is a gif of me loading vscode on my somewhat slow Surface. It takes a bit for vscode to startup, load the file, and apply syntax highlighting, but relatively soon afterwards the Navigator starts and produces compilation errors. There's not much to do for initialization, so I believe most of the delay is waiting for the editor to start the server. Once it's running, it should be ready to respond to requests almost immediately. It runs a startup task to list all modules available for autocompletion, but this runs asynchronously, so the Navigator should be able to compile files in the meantime (while having slightly degraded autocompletion). Also, I only restart my editor a few times per week at max. I generally always leave it open, so I don't think about startup time much. Startup gif below:

And for Format document, I just timed it out. For an arbitrary 1000 line file (I used List::MoreUtils::PP) It takes about 1 second to perltidy and about 2 seconds to run perl imports. VSCode provides a visual indicator of an outstanding request, which is helpful in this case.
For editors that don't provide this, I'm not really sure where I could put a progress message. One possible speed-up could be splitting perltidy and perlimports into different calls. In the Python LSP, they have "Format Document" distinct from "Sort Imports". That would reduce the latency of the request. Sorting gif below

[WhoIsSethDaniel]

I'm not a vscode user so my experience is with neovim. Regardless, I don't think it matters that much which editor one uses.

Re: initialization: In some cases I can start neovim with a perl file, navigate to something, ask for 'go-to-definition' and it won't happen because the server is (presumably) still initializing. It's not a lot of time, but it is enough time for this to happen. The only feedback I get that the server is now ready is if there is a perlcritic error to display. Once the error is displayed I know the LSP server has completed initialization and I can continue.

Re: formatting: I don't actually use the built-in perltidy due to #11. I turn off perltidy support, but I have perlimports turned on. perlimports can be quite slow. At work there are numerous perl files where it will take 5+ seconds to do its job. It's often not obvious that it has completed its job since there is no feedback. perltidy can also take more than just 1 or 2 seconds, although I admit it's pretty rare. Although if you're on a VM with a slow disk even small tasks seem to take a second or two longer.

For what it's worth there are other LSP servers that send progress messages regardless of how long it is expected to take for an operation. An example would be Go's LSP server gopls. Nearly everything takes less than a second, particularly formatting, yet it sends progress messages. This is useful because I now know a) it is running and b) it has finished. Without those messages I wouldn't necessarily know that anything had happened. (gopls also takes a very long time to initialize on even modestly sized projects so it also helps there).

Consider, also, that not everyone is developing on a speedy, local host. I often am compelled to develop on a slow(er) VM in a remote location. So while these operations are fast on a local SSD they may be much slower on a VM with slow disk access.

[bscan]

Hi @WhoIsSethDaniel! Thanks for advocating for this idea, and I'm convinced by your argument. It certainly seems far better to get progress messages than have the Navigator appear frozen or non-functional. I just committed a first version as version 0.4.3 on NPM: adbb50a

By default, the progress messages are turned off, but you can enable them with the setting enableProgress. Before I can enable it by default, I'll also need to check capabilities since I believe not all clients have support for progress markers. Also, worth testing to make sure they work well across a few different editors.

With the Navigator, each file needs to first be compiled to get go-to definition results. The progress message should now show the first time a file is compiled. It's not sending any messages on server initialization, but I hope the file compilation message is sent early enough in the process. Progress messages should also be sent while document formatting. Let me know how it works for you, and I'll test in some other editors as well. Thanks!

[WhoIsSethDaniel]

Hi @bscan. I have yet to change anything but the version of the server, but ATM the server is crashing. Often it seems to crash not long after start. I'll continue to look at it and see if this is a problem on my end.

[WhoIsSethDaniel]

I just saw your reply. It seems you have a handle on the situation. Thanks again for doing this work.

[bscan]

Just pushed another version (0.4.5). Hopefully third time's the charm 😆 . I changed the necessary functions to be asynchronous, and the progress messages seem to be working. Let me know. Thanks!

[WhoIsSethDaniel]

I still have the same issue. ☹️

[WhoIsSethDaniel]

@bscan Much like when I modified the generated code in #53 (reply in thread) I did something similar here. And, again, it works. But this modification is a quick hack. What did I do?
I removed the startProgress and endProgress lines from out/formatting.js/maybeReturnEdits and placed them in out/server.js/connection.onDocumentFormatting. That function now looks like this:

 connection.onDocumentFormatting(async (params) => {
     let document = documents.get(params.textDocument.uri);
     let settings = documentSettings.get(params.textDocument.uri);
     const progressToken = await (0, progress_1.startProgress)(connection, 'Formatting doc', settings);
     const workspaceFolders = await getWorkspaceFoldersSafe();
     if (!document || !settings)
         return;
     console.log(params);
     const editOut = await (0, formatting_1.formatDoc)(params, document, settings, workspaceFolders, connection);
     (0, progress_1.endProgress)(connection, progressToken);
     return editOut;
 });

My only guess as to why this works is the extra async operation when getWorkspaceFoldersSafe is called.

[bscan]

Ah, this is a tricky one. My guess is that the extra async operations allow more time for the progress messages to be sent before the entire event loop is blocked by the formatting operation. I should probably just change the entire formatting operation to be async. Still not clear why this works on some editors and not others, although perhaps different clients process messages at different rates. I'll see if I can get this done this weekend.

[bscan]

Hi @WhoIsSethDaniel , I just got back to this now that #11 has been fixed. I suspect progress messages are even more important if waiting for both perltidy and perlimports to finish. I changed them both to run asynchronously via 99e7c2d . Thanks for the suggestions! Hopefully this change gets it working

[WhoIsSethDaniel]

it works well. Thanks!