ale
ale copied to clipboard
Support serve-d
serve-d is an LSP implementation for Dlang.
Even though dmd is quite fast, serve-d would be a massive performance improvement.
I'll start working on this once we resolve the issues in #1063.
@w0rp serve-d logs to stderr, would it be possible to make ale only read messages off of stdout?
Currently, it just throws several json parsing failures before giving up.
Well that's fun. Another detail not part of the LSP spec.
We'll have to add support for reading JSON from other output streams. I don't know why you'd write the part of the output you're supposed to parse are part of the normal operation of a program in stderr. That doesn't make sense.
Yeah. I mean, I could redirect stderr to /dev/null, but that'd only work on unix-like systems, so no windows support. On the other hand, I might PR a --disable-log flag to serve-d .
The output streams can be controlled for regular linters. It makes sense to support reading from stderr eventually. I'll create an issue asking for stdout output.
Wait wait wait, I think you misunderstood me. It writes messages to stdout, and log to stderr.
Okay then.
ALE doesn't read stderr at all for LSPs.
Oh then that's weird, because for some reason, when I last tried implementing a serve-d ale linter it logged some json parsing errors. I'll take a look, it's probably a problem with my impl.
There could be some other weird BS, like needing to ignore the first few lines of output or something.
Yeah, looks like ALE's trying to parse logger messages. Maybe it logs some messages to stdout 🤔
That might be the issue.
serve-d only logs debug information / trace messages to stderr, which might be useful for users to diagnose issues when they experience problems.
it uses stdout for all RPC communications and the latest releases have fixed a few JSON-RPC and LSP spec issues. Next release will fix a few more oddities, but right now it already works with a bunch of LSP clients, so I think it should be easy to integrate here as well.