refact-lsp process handling

[olegklimov]

process_server_errors() approach is probably not a good idea (a thread?), it's better to save logs to ~/.cache/refact/logs/ by removing --logs-stderr.

The process does not restart with relevant settings change, specifically api_key, address_url, telemetry_code_snippets.

Errors that are kind of caught there:

			print(line)
			if "error" in line:
				self.statusbar.update_statusbar("error", line)

-- but they really need to go via LSP RPC. The simple test is to turn off wi-fi, does this produce a disconnected icon in the status bar or not?

[digital-phoenix]

I just confirmed that turning off the wi-fi produces a timeout error in the status bar.

[olegklimov]

produces a timeout error in the status bar

Cool, but we need error to go via LSP, not through stderr. We want a good product, written correctly, no hacks.

[digital-phoenix]

The error is generated from the rpc connection. The rpc connection uses stdio in favour of an http connection because the server is running locally.

[digital-phoenix]

The main reason the code monitors the process through stderr is to address the issue where the server would crash but the process would not terminate. By monitoring for crashes directly the code is able to cleanly close the server.

[olegklimov]

refact-lsp does not crash. I think we fixed all or nearly all error handling in rust, so unlikely it will panic or exit.

[digital-phoenix]

This code is over a month old. If the refact server doesn't crash anymore then this code can be removed.

[olegklimov]

I just exited Sublime Text, two processes left over.

[olegklimov]

Tested: process does not restart

The process does not restart with relevant settings change, specifically api_key, address_url, telemetry_code_snippets.

^^ this specifically doesn't work.

Here if I change "zzz" to "www" it doesn't restart the refact-lsp process with the new command line.

[hazratisulton]

Checked #16 - changing option in plugin settings restarts the refact-lsp.