#1076 LSP
Announcement: Initial Plugin Central release
Name: LSP
Version: 0.1
Requirements:
- JDK 11
- jEdit 5.5.0
- plugin: ErrorList 2.4.0
- plugin: SideKick 1.8
- plugin: ProjectViewer 3.6
- bundled library: org.eclipse.lsp4j 0.18.0
- bundled library: org.eclipse.lsp4j.jsonrpc 0.18.0
- bundled library: org.eclipse.xtext.xbase.lib 2.28.0
- bundled library: gson 2.9.1
- bundled library: guava 31.1-jre
- bundled library: commonmark 0.20.0
- bundled library: commons-compress 1.23.0
All bundled libraries are downloaded from Maven Central using Ivy.
Source Code: https://git.sr.ht/~damien/jedit-lsp/tree/v0.1
Short Description: This plugin turns jEdit into a Language Server Protocol (LSP) client, which provides a number of IDE-like features by running and interacting with LSP servers.
Long Description:
<html>
<p>This plugin turns jEdit into a Language Server Protocol (LSP) client, which provides a number of IDE-like features by running and interacting with LSP servers.</p>
<p>For more information on the protocol, see: https://microsoft.github.io/language-server-protocol/</p>
<p>To see a list of available LSP servers, see: https://microsoft.github.io/language-server-protocol/implementors/servers/</p>
<p>The LSP protocol supports many, many features, and this plugin only implements a tiny subset of them. Support for more can be added easily, limited primarily by time and effort.</p>
</html>
I keep receiving emails from you. Please remove me for the email list, thank you
On Wednesday, June 14, 2023 at 04:10:30 AM GMT+2, Damien via jEdit-devel jedit-devel@lists.sourceforge.net wrote:
[plugin-central-submission:#1076] LSP
Status: open
Group: None
Created: Wed Jun 14, 2023 02:09 AM UTC by Damien
Last Updated: Wed Jun 14, 2023 02:09 AM UTC
Owner: nobody
Announcement: Initial Plugin Central release
Name: LSP
Version: 0.1
Requirements:
- JDK 11
- jEdit 5.5.0
- plugin: ErrorList 2.4.0
- plugin: SideKick 1.8
- plugin: ProjectViewer 3.6
- bundled library: org.eclipse.lsp4j 0.18.0
- bundled library: org.eclipse.lsp4j.jsonrpc 0.18.0
- bundled library: org.eclipse.xtext.xbase.lib 2.28.0
- bundled library: gson 2.9.1
- bundled library: guava 31.1-jre
- bundled library: commonmark 0.20.0
- bundled library: commons-compress 1.23.0
All bundled libraries are downloaded from Maven Central using Ivy.
Source Code: https://git.sr.ht/~damien/jedit-lsp/tree/v0.1
Short Description: This plugin turns jEdit into a Language Server Protocol (LSP) client, which provides a number of IDE-like features by running and interacting with LSP servers.
Long Description:
This plugin turns jEdit into a Language Server Protocol (LSP) client, which provides a number of IDE-like features by running and interacting with LSP servers.
For more information on the protocol, see: https://microsoft.github.io/language-server-protocol/
To see a list of available LSP servers, see: https://microsoft.github.io/language-server-protocol/implementors/servers/
The LSP protocol supports many, many features, and this plugin only implements a tiny subset of them. Support for more can be added easily, limited primarily by time and effort.
Sent from sourceforge.net because jedit-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-central-submission/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-central-submission/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
jEdit Developers' List
jEdit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Related
Plugin Central Submission: #1076
Unsubscribe here:
https://sourceforge.net/projects/jedit/lists/jedit-devel
Hi Damien,
sorry for the delay.
Great plugin! I was toying myself with LSP integration but got nowhere due to time constraints.
I'll release the Beauty plugin update first because it should be fast and easy but will get back to you Today.
Really cool, thanks! I've played a bit with it and here are my remarks.
Only blocking questions that must be answered before initial release are related to bundled libs and dependencies, otherwise we can always expand in another release shortly.
Errors:
blocking The plugin depends on Console plugin for the print() macro in downloadEclipse.bsh.
blocking Deps:
- I don't like that common-codecs is bundled but it seems LSP is the first plugin using it.
- shall we have a LSP-deps plugin with bundled libraries that we can upgrade separately or depend on in other plugins? This would make sense if a different plugin implemented LSP but this would actually be bad: better improve on this one. Also how do you plan extensibility: for instance if I want to implement the debugger part of a client, would I be able to create another plugin or do we put everything in the same plugin?
User niceties:
- Maybe start server could check if the server is installed and then display an explicit error when not.
- Show subprocess output when exiting in error: I first had missing python3 command error; then "only supports java17" error.
-
WARNING: Unsupported notification method: language/statusappears in the logs when jdtls is startingCode:
- Some code in Utils.java could be replaced with jEdit own code
- some algorithms don't seem optimal (eg DiagnosticPainter storing icon for each line) but I'm not familiar with the hot code paths to say if it's good enough or to be fixed.
Behaviour:
- I got a stuck task in TaskMonitor when playing with jdtls. Its name is
lsp.Server$$Lambda...so I can't tell what got stuck.- how do I see the message associated with a diagnostics icon in the ruler? If ErrorList supported "info" errors, would it make sense to only use error list painter? Do other plugin show such icons? It rings a bell but I can't remember right now.
- I've got an issue on fresh install where the buffer is always a non-project file...
- it seems diagnostics icons don't move when I add a line in the editor before it.
Doc:
The awful builtin HTML viewer renders black text on a dark blue background: not the best legible contrast ;-)
jdtls requires python3 and java 17. Should be documented.
Hey Eric, thanks for the feedback!
I also don't have a lot of time to play around with stuff like this, but I had some time in between jobs to take a crack at it, and wanted to publish my results. So no worries at all on the delay, and thanks for helping to maintain jEdit's plugin ecosystem!
In terms of the Console dependency, I just pushed a small change to remove the need for that dependency by using
System.out.println()directly, rather thanprint().For the deps, I would lean towards the simplest possible solution, at least initially. I don't really foresee the need for additional LSP plugins (maybe a separate one to support the Debug Adapter Protocol that depends on LSP), and the dependencies of LSP shouldn't need to be updated very often. Breaking the LSP plugin up into multiple, to me, seems like it would increase the maintenance burden for not much benefit. I'm happy to hear of any scenarios you might be thinking of, though, where this might be more beneficial.
I agree with most of your comments on user niceties. The only comment I have is that the plugin is designed to work with system-installed servers as well; the installation functionality is just a convenience for anyone who doesn't already have the server available. So, I wouldn't want to necessarily show an error if the server was installed through some other means. I do think the "server couldn't be started" error could be made more visible, though it also shouldn't be too annoying either.
Can you be more specific about which functions in Utils.java could be replaced with jEdit functions?
The ProjectViewer dependency was intended to provide a language-agnostic way to determine the project's "root," which many other editors do manually via file detection. But, I agree that I think I have seen some issues with that flow, so I may consider introducing that type of behavior as a fallback. For Java, that would be looking for something like a settings.gradle, pom.xml, etc.
Lastly, should any changes here be used to re-tag 0.1 as long as it's before the actual release? Or should I instead begin introducing new tags like 0.1.1?
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.
I added some additional logging to help users debug issues like yours by suggesting that they run the command directly, since any solution to get the output directly is going to end up being pretty hacky. We would either need to tee the output for the entirety of the program (likely only keeping the last few lines for potential error-reporting purposes), or automatically restart the server with direct stdout control. Neither solution feels great to me, so I just went with the simplest option in the meantime.
here is how it's handled in vscode but I read they use ipc not stdout/stderr so can get a handle on the output. Would it be feasible in your plugin?
https://github.com/microsoft/vscode-languageserver-node/blob/main/client/src/common/client.ts#L1194C78-L1194C83
See https://github.com/eclipse-lsp4j/lsp4j/issues/258#issuecomment-874886549 ipc is out of scope in lsp4j itself and I don't know if jdtls implements this transport.
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 Node IPC, then we could also add an option to use that.
Yes, but it would be work for a later version.
Utils.deleteDirectory()is the same code asFileVFS.recursiveDelete(); that's it I guess.For this release:
- please can you tweak the html styling so that it's not black-on-blue when using java builtin browser?
- please can you add a short paragraph to the "Servers" documentation, describing the jdtls (mentioning python3 and java 17 dependencies) since its installation script and command are bundled?
Feel free to delete the tag and re-create, or re-tag and change in the ticket, as you prefer.
Thanks,
Ok, so the changes are done in https://git.sr.ht/~elelay/jedit-lsp/tree/proposal-for-release
This is my first exchange on sourcehut so maybe I made a mistake (yes, I put my own git.sr.ht email address instead of yours). Hope this reaches you.
Thanks,
I've just tried with pylsp and this is crazy!
You commented that
but apparently pylsp parses any open file in jedit and returns MANY errors of course since it's java code or yaml or whatever!
I'm confused as to whether pylsp is wrong or the plugin is wrong :-/
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.
I just pushed a few updates to
masterthat 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 actually pay attention to the didChangeWatchedFiles configuration pushed by the server. This is used to tell the client which files the server is interested in, so we can avoid notifying a server about files that it doesn't care about.
I also reduced the scope of what jEdit reports to a running server as opened or closed. When the server starts, it looks up the project root from Project Viewer, and any files opened outside of that project's root are ignored. Technically, jEdit should support running multiple instances of a single server based on that root (i.e. so you can have two different Java projects open, and jEdit will only notify a server of changes to the files that belong to its project), but that's what I consider an "eventual" feature.
@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.
Hi Damien,
the plugin causes trouble with my setup/python lsp: the other day I got a disk full of GBs of activity.log from it!
I had to quickly delete the file so I don't have logs right now but I'm not confident in releasing it as is. What about you? Do you use is daily? Do you feel confident to release it?
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 this plugin released, at least for its first version? Some changes have been made to address the logging verbosity, and I don't want to keep this on hold indefinitely. If other bugs or issues come up, they can be addressed in future releases.