eglot
eglot copied to clipboard
joaotavora
Support specifying extra VM arguments for the Java Language server
- eglot.el (eglot-java-vmargs): New defcustom. (eglot-eclipse-jdt): Specify VM arguments.
Thanks, if @joaotavora agrees I think we could merge this with the above changes.
This patch is large enough to need a copyright assignment to the Free Software Foundation. Have you already done that, or would you like to start that process now?
This patch is large enough to need a copyright assignment to the Free Software Foundation. Have you already done that, or would you like to start that process now?
I have not done any copyright assignment to the Free Software Foundation, but I'd like to start it. Could you give me some hints about how to do it? Thanks.
I have not done any copyright assignment to the Free Software Foundation, but I'd like to start it. Could you give me some hints about how to do it? Thanks.
Great, thank you for your contribution. Here are the instructions:
Please email the following information to [email protected], and we
will send you the assignment form for your past and future changes.
Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES
[What is the name of the program or package you're contributing to?]
Emacs
[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]
[Do you have an employer who might have a basis to claim to own
your changes? Do you attend a school which might make such a claim?]
[For the copyright registration, what country are you a citizen of?]
[What year were you born?]
[Please write your email address here.]
[Please write your postal address here.]
[Which files have you changed so far, and which new files have you written
so far?]
@skangas just a heads up about the JDT support.
When I added it very early on in the product, I was doing something I don't like to do. THere should be no complex catering for specific language servers in eglot.el itself except for entries in eglot-server-programs. JDT (and the somewhat quirky Rust rls), got something of a free pass (nothing against rls, it was something of a pioneer in this field).
Anyway avoiding language specific things in Eglot is exactly what LSP is about. In Eglot, it's precisely what differentiated it, in a good way, I think, from lsp-mode. There, there is a whole ecosystem of lsp-langx.el libraries and there is a trio of players: 1. major mode, 2. lsp client and 3. lsp-language-specific-code. In Eglot, there are only the first 2 and I think we should go towards that objective always, as we put eglot.el in he code.
Long story short, all this code should be in java-mode.el in Emacs. Or in some separate eglot-jdt.el library. I don't understand why Java is the only language where setting up a language server is such a pain. In any other language it's usually a question of launching a program, here, it's a very very horrible pain. None of this code belongs in Eglot.
That said, this does solve user problems. But here I would really consider making a separate deprecated eglot-jdt.el library, clearly specify that it is an exception and interim solution, and put all this cruft there. To not break user experience, this can be put at the end of eglot.el:
(provide 'eglot) ;; as normal
(require 'eglot-jdt nil t)
I'd probably also delete the rls specific support for its quirks in the process. rust-analyser (https://rust-analyzer.github.io/) seems much better.
@joaotavora Thanks, that's very useful. See also my separate question about this in the discussion, which you basically answered fully here. I can see the logic in your arguments, and I can only agree.
Your plan to move this into a separate file is good, and I think we could do that before or after merging this PR. Once we have moved this out into a separate library, we can start working on basically dumping that support code on whatever major mode(s) that wants to take it. Perhaps they will be more inclined to agree once we have eglot in core.
Regarding rls, I don't mind dropping that. I wonder if we should do that without asking someone else to take it over first? If rls is not very important these days, I think we could just dump it.
It seems like rust-analyzer is the officially blessed one: https://github.com/rust-lang/rfcs/pull/2912
FYI, someone has created a package eglot-java which improves eglot's java support and provides some additional useful functions, maybe the author @yveszoundi is interested in helping split java support into a separate library?
FYI, someone has created a package eglot-java which improves eglot's java support and provides some additional useful functions, maybe the author @yveszoundi is interested in helping split java support into a separate library?
OH really, that's good news. Then we should definitely advertise in the README.md (with the context that it is an exception), and maybe just delete all the java stuff in eglot.el? Does eglot-java replace eglot's JDT thing completely, or does it still rely on it? I.e. @zbelial why are you not using it?
OH really, that's good news. Then we should definitely advertise in the README.md (with the context that it is an exception), and maybe just delete all the java stuff in
eglot.el? Doeseglot-javareplace eglot's JDT thing completely, or does it still rely on it? I.e. @zbelial why are you not using it?
Currently it depends on eglot's eglot--eclipse-jdt-contact(this seems the only hard dependency in terms of java support. It detects where JDT is installed and sets CLASSPATH before calling eglot--eclipse-jdt-contact. )
That dependency is the only reason why I do not use it, since it still does not support specifying vm arguments.
Thanks for the updates here. Do you mind squashing the three commits into one? That makes it easier to review and merge.
Thanks for the updates here. Do you mind squashing the three commits into one? That makes it easier to review and merge.
Sure. I have squashed those three commits into one now. It seems to me that squash is done successfully, but this is the first time that I use rebase squash, is the latest commit ok?
Sure. I have squashed those three commits into one now. It seems to me that squash is done successfully, but this is the first time that I use rebase squash, is the latest commit ok?
The latest commit is fine. I think we are just waiting for the copyright assignment here. Thanks!
I hadn't noticed that before. That pr and this one demonstrate that some jdt users really need some way to configure jdt :)
Thinking a bit more about this, given that this is basically is only relevant until this gets moved elsewhere (see #809), I'm not sure we would want to advertize it as much as making it a defcustom implies. So could we please move this to a defvar instead?
I hadn't noticed that before. That pr and this one demonstrate that some jdt users really need some way to configure jdt :)
Yes, and JDT needs a lot of configuration. I wonder why, if that
eglot-java.el is apparently a thing, we don't dump all our JDT core that
way. Then, the day that JDT devs become enlightened by the power of
scripting and configuration files, we can just add some jdt.bash/bar
script into `eglot-server-programs' and eglot-java.el won't be loaded.
João
@zbelial , I made the relevant changes in eglot-java today. It should be available in upcoming MELPA builds.
- Catch up with recent
eglotcode changes (removed functions) - Add ability to pass extra JVM arguments to the LSP server (
eglot-java-eclipse-jdt-argscustomizable option)
/cc @skangas @manuel-uberti
Other relevant references
- https://github.com/joaotavora/eglot/pull/874
- https://github.com/joaotavora/eglot/pull/809
- https://github.com/joaotavora/eglot/pull/251
