Reconsider requiring LogOutputChannel for LanguageClientOptions.outputChannel

[davidanthoff]

It makes sense to me that traceOutputChannel uses LogOutputChannel, but for the regular outputChannel this now leads to a weird UI experience IMO. The new client now tags every output on stderr as an error, which seems not right. Lots of pieces of code just write generic logging output/information to stderr (we do that for example in the Julia extension) that should not be tagged as an error.

I think in general it is not ideal to make assumptions about what a LS will write to stderr, at the end that is just unstructured output, and then pressing that into a more structured format in the output channel seems too much of an assumption to me.

[dbaeumer]

All I can think of is to make this user configurable. Problem might be the typing.

[dbaeumer]

The old implementation basically emulated what a LogOutputChannel does by adding prefixes and date/timestamps as well.

[davidanthoff]

The regular output channel outputChannel didn't add date/timestamps, right? It was just a 1:1 printing of the stderr of the LS process, which is super useful.