Php-language-server: Is there some way to disable log messages?

[w0rp]

I'm currently trying to implement an LSP client which will connect to this language server. I am wondering, is there some way to disable the window/logMessage messages or maybe set a minimum log level so only errors are reported? Processing of the log messages in Vim has to happen synchronously, so processing a large number of messages could slow down user input.

[duplicate-issues[bot]]

Hey @w0rp,

We did a quick check and this issue looks very darn similar to

• #446 - show whole variable declaration
• #445 - Formatting crashed
• #443 - Request textDocument/formatting failed / ErrorException: shell_exec() has been disabled for security reasons

This could be a coincidence, but if any of these issues solves your problem then I did a good job :smile:

If not, the maintainers will get to this issue shortly.

Cheers,
Your Friendly Neighborhood ProBot

[w0rp]

Thank you automated robot process, but this time you are incorrect.

[felixfbecker]

Why not implement the loglevel filter in the client?

[w0rp]

I'm wondering if there's a way to tell the server not to send the log messages, maybe by changing the capabilities in the initialize request. As long as the log messages are being sent, the client has to process them to be able to work with the messages it wants.

[felixfbecker]

I don't fully understand why the message processing is synchronous, that sounds like a pretty big limitation in general, not just for log messages

[w0rp]

It's the same as in most uses of JavaScript.

The job for running the language server runs in the background. The JSON string for a request is processed in the single thread that Vim runs in, and then that string is given to a channel function which sends the message to the process in another thread. All messages from the server are handled in whatever thread the job is running in, and then the messages are given to a callback function, which runs in the same thread that user input is handled in. Any processing of messages from that point happens in the one thread that Vim runs in.

As long as the number of messages isn't too large, this model works pretty well. Process communication itself happens in a second thread, and interaction with Vim, like processing a JSON string and showing errors, happens in the first thread, which is the same thread which handles user input.

I'm concerned that a large number of log messages will slow down Vim, as the processing of the lines of JSON-RPC can only happen in the main thread. The only way I can think to solve that is to tell the server, possibly through a command line argument, maybe php.ini configuration, or through some kind of capability in the initialize messaage, to not send too many log messages.

[felixfbecker]

VS Code is running in JavaScript and has no problem processing the number of messages, so I would argue if vim has then it is not optimised enough

[w0rp]

It's not a problem yet, but it could be with large enough projects. Just opening a 2 line PHP file and looking at the channel log, I received 216 log messages. I think it would be reasonable to offer an option for setting a log level, so that only error messages can be sent to the client.

[prabirshrestha]

@felixfbecker It is actually more of text editor limitations rather than scripting language for the texteditor/ide.

Since extensions in VsCode runs in worker thread (I think), a bad extension can never slow down VsCode.

In Vim, vimscript runs on the UI thread which means it can slow down the vim ui. Unlike Javascript vim script doesn't support JIT, so it will always be magnitude slower than Javascript running in v8.

Neovim on the other hand solves this problem by remote plugins which works similar to how vscode plugins work. This allows the plugin authors to spin a process that does the complicated work and interact with neovim using it's own rpc protocol. There is a slight problem with this since the process can be written in any other language i.e., means if I write in python, everyone else needs to have python installed instead of making it work with vanilla vim. Neovim will be including lua remote plugin which would solve this issue, but since Vim doesn't have remote plugins the issue would still hold true.