Damien

Well, now that I've reported the problem I can't seem to reproduce it. I will certainly give that a shot if I run into it again, though.

jEdit becomes unresponsive to key presses

No, I haven't been using it as a daily driver lately, though I may run it through its paces more soon. Out of curiosity, did you have debug mode enabled for jEdit when the activity log filled up your disk? I'm thinking it might be good to have the LSP plugin throttle its own logging when it detects that the log file has reached a certain size.

@kerik-sf Any thoughts on getting the release kicked off? A number of improvements have been made since this request was first opened, and I think it's ready for an initial release.

I just pushed a few updates to master that should help reduce the pylsp errors you were seeing. Originally, the plugin's handling of "watched files" was very simple, since it worked with the servers I was testing with (eclipse.jdt.ls and gopls). Basically, jEdit would cast a wide net and send all buffer updates to all servers. In those cases, it seems like the servers simply treat that as a no-op, but pylsp instead reports an error. The more correct solution, and the one that I just pushed, is to...

This is my first time collaborating on something like this via sourcehut as well, but I managed to get all of your suggestions applied. That's very interesting, I don't think I've seen that behavior before, though I've only tested it so far with gopls and jdt.ls. It might be worth testing with a couple different language servers to confirm what seems to be working, and what doesn't.

It looks like jdtls does not support Node IPC, but you can specify a socket for it to connect to: https://github.com/eclipse-jdtls/eclipse.jdt.ls#managing-connection-types In terms of this plugin, we could add an option to have jEdit open a connection on a new port and substitute that port into the command that's run. That would leave stdout and stderr free for any errors that are printed, and hopefully make it more clear in those scenarios when it fails. If we can find a Java library that implements...

I just took a quick look at capturing the subprocess output when the server fails to start correctly, but unfortunately this looks pretty tricky. Anything printed to standard error should already be logged, and anything printed to standard output is used by lsp4j in its message processing. So if a subprocess prints an error message to standard output and then exits, it is not available to be read directly, since lsp4j is attempting to use it in its message processing, and doesn't expose it directly....