Eglot rename, create, delete support

Eglot rename, create, delete support

[me]

Hi all,

The Language Server Protocol spec allows for servers to send requests to the
client (in this case Emacs/Eglot) to create, rename or delete files in the
project if the client advertises that it can do “resourceOperations”
[https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#resourceChanges].
Unfortunately Eglot does not support this in either HEAD or in Emacs 29. It’s
particularly useful for Java since the compiler for that language refuses to
compile a file if the name of a type does not match the file name, as well as
code actions for moving types from one package (namespace) to another.

I have a patch that adds support for rename requests to Eglot inside an
extension package for connecting to a Java language server, but it is very
hacky because it needs to advise eglot--apply-workspace-edit which will
mishandle parsing if it encounters an object with a different type than
TextDocumentEdit inside a workspace edit response
[https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspaceEdit].
Really, though, this code should be inside Eglot itself. I would share it on
the list but I do not have my copyright assigned yet, it's pushing around 125
lines with just rename support. As well I would like some review and to write
some tests as these are potentially destructive operations and I would like to
handle all the potential corner cases that might arise.

If someone could send me the copyright assignment forms that would be grand.

   	   Lina

Eglot rename, create, delete support

[Lina Bhaile]

(Resending due to wrong From:)

Hi all,

The Language Server Protocol spec allows for servers to send requests to the
client (in this case Emacs/Eglot) to create, rename or delete files in the
project if the client advertises that it can do “resourceOperations”
[https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#resourceChanges].
Unfortunately Eglot does not support this in either HEAD or in Emacs 29. It’s
particularly useful for Java since the compiler for that language refuses to
compile a file if the name of a type does not match the file name, as well as
code actions for moving types from one package (namespace) to another.

I have a patch that adds support for rename requests to Eglot inside an
extension package for connecting to a Java language server, but it is very
hacky because it needs to advise eglot--apply-workspace-edit which will
mishandle parsing if it encounters an object with a different type than
TextDocumentEdit inside a workspace edit response
[https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspaceEdit].
Really, though, this code should be inside Eglot itself. I would share it on
the list but I do not have my copyright assigned yet, it's pushing around 125
lines with just rename support. As well I would like some review and to write
some tests as these are potentially destructive operations and I would like to
handle all the potential corner cases that might arise.

If someone could send me the copyright assignment forms that would be grand.

   	   Lina

Re: Eglot rename, create, delete support

[Eli Zaretskii]

> Date: Mon, 04 Mar 2024 19:18:36 +0000
> From: "Lina Bhaile" <emacs-devel@linabee.uk>
> 
> (Resending due to wrong From:)
> 
> Hi all,
> 
> The Language Server Protocol spec allows for servers to send requests to the
> client (in this case Emacs/Eglot) to create, rename or delete files in the
> project if the client advertises that it can do “resourceOperations”
> [https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#resourceChanges].
> Unfortunately Eglot does not support this in either HEAD or in Emacs 29. It’s
> particularly useful for Java since the compiler for that language refuses to
> compile a file if the name of a type does not match the file name, as well as
> code actions for moving types from one package (namespace) to another.
> 
> I have a patch that adds support for rename requests to Eglot inside an
> extension package for connecting to a Java language server, but it is very
> hacky because it needs to advise eglot--apply-workspace-edit which will
> mishandle parsing if it encounters an object with a different type than
> TextDocumentEdit inside a workspace edit response
> [https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspaceEdit].
> Really, though, this code should be inside Eglot itself. I would share it on
> the list but I do not have my copyright assigned yet, it's pushing around 125
> lines with just rename support. As well I would like some review and to write
> some tests as these are potentially destructive operations and I would like to
> handle all the potential corner cases that might arise.
> 
> If someone could send me the copyright assignment forms that would be grand.

Form sent off-list.

When you are ready with the patch, please post it to our issue tracker
using "M-x submit-emacs-patch", preferably in the form generated by
"git format-patch".  You could post it while your legal paperwork is
still in progress, because patch review takes some time, and you might
get review comments to follow up on.

Thanks.

Re: Eglot rename, create, delete support

[Stefan Kangas]

me@linabee.uk writes:

> If someone could send me the copyright assignment forms that would be grand.

Hi Lina,

I didn't see anyone followup to your email from March, so I'm sending
this form to you now.  Sorry for the delay.



Please email the following information to assign@gnu.org, 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?]

Re: Eglot rename, create, delete support

[emacs-devel]

On 22 September 2024 12:46:37 BST, Stefan Kangas <stefankangas@gmail.com> wrote:
>I didn't see anyone followup to your email from March, so I'm sending
>this form to you now.  Sorry for the delay.

Hi Stefan, unfortunately me and FSF legal ran into a roadblock with regard to my university's IP policy. I've attempted to retrofit the functionality into Eglot using a bunch of advices, but didn't get anywhere before it turned out I didn't need to write Java anymore and so I lost interest. I'm probably going to end up writing more Java in the near future so I will probably get back to that when the need arises, but in the meantime if any hooks could be written into Eglot to make this easier I'm happy to elaborate on what I wish I could do with Eglot without advices.

Re: Eglot rename, create, delete support

[Stefan Kangas]

emacs-devel@linabee.uk writes:

> On 22 September 2024 12:46:37 BST, Stefan Kangas <stefankangas@gmail.com> wrote:
>>I didn't see anyone followup to your email from March, so I'm sending
>>this form to you now.  Sorry for the delay.
>
> Hi Stefan, unfortunately me and FSF legal ran into a roadblock with
> regard to my university's IP policy. I've attempted to retrofit the
> functionality into Eglot using a bunch of advices, but didn't get
> anywhere before it turned out I didn't need to write Java anymore and
> so I lost interest. I'm probably going to end up writing more Java in
> the near future so I will probably get back to that when the need
> arises, but in the meantime if any hooks could be written into Eglot
> to make this easier I'm happy to elaborate on what I wish I could do
> with Eglot without advices.

We are usually forthcoming when it comes to adding hooks that are
motivated by concrete use cases, indeed.  I'd recommend sending this
feature request to the bug tracker, detailing which hooks you need, and
let's take it from there.