Rafał Chłodnicki
Rafał Chłodnicki
LSP-eslint doesn't seem to report any error and just crashes silently. But if you try to run `eslint` manually then you'll see what the error is: ``` npx eslint --ext...
The fact that it works in VSCode is a bit of a mystery for me right now. I'll have a look at it later.
It appears that this warning (the one starting with `=============` line) is printed to stdout and our implementation is strict in the sense that it requires properly formatted RPC messages....
Moved this to the LSP repo. At the minimum, we should print the exception to make cases like this easier to diagnose in the future. Possibly we can gracefully handle...
Actually, VSCode uses IPC transport and not STDIO so it's not affected by this issue. I'm not sure we can or should even try to fix it as the fix...
> Wish I saw this issue before the rabbit hole 😅 Wish I would remember that I've investigated it before. :)
> I'm thinking of adding IPC support instead, it actually looks [pretty doable](https://stackoverflow.com/a/23854353/242684)! Well, it would need to be done in python though and that's probably "a bit" more work...
Any help here is appreciated so yeah :) If that's all it takes then it should be pretty easy to integrate it with the LSP code base and add it...
This crash happens because we are passing non-existant `cwd` path to `subprocess.open` when starting the transport. I would think that the transport doesn't really need any specific `cwd` anyway so...
Just as I said it, I've stumbled upon https://github.com/sublimelsp/LSP/issues/1978 for which this might be relevant.