[feature request] change (as opposed to rename) environement

[martinra]

I would like to add a feature to change an environment, which when triggered changes ENV in \begin{ENV} and \end{ENV} of the innermost environment relative to the cursor. This would recover a feature of vimtex.

I think I can implement the set of code changes paralleling the implementations in features/rename. However, when trying to plan an implementation and how to expose the feature, I first looked into rename and found that its semantics are not the one I am looking for. Looking further through the LSP documentation, I did not find any CodeAction that encodes it.

Is there room for such a feature in texlab? And if so, what part of the LSP should one use to expose it?

[pfoerster]

I would like to add a feature to change an environment, which when triggered changes ENV in \begin{ENV} and \end{ENV} of the innermost environment relative to the cursor.

I am bit surprised to see that this feature is no longer there since version 3.0.0 and I am not sure why. This was definitely an accidental change. See here: https://github.com/latex-lsp/texlab/blob/v2.2.2/src/rename/latex_env.rs

I first looked into rename and found that its semantics are not the one I am looking for.

I agree that textDocument/rename is not the correct request for this feature when we re-introduce this feature. In this case, the user likely would expect that all occurrences are renamed too.

And if so, what part of the LSP should one use to expose it?

I think CodeActions are fine for this feature.

I did not find any CodeAction that encodes it.

Actually, we are free to define our own code action (e. g. something like 'source.changeEnvironment'). Looking at the type definition, we can see that the kind is just a string. In fact, the server must announce the supported actions during initialization.

Is there room for such a feature in texlab?

Sure :)

[pfoerster]

@martinra

I think CodeActions are fine for this feature.

Actually, I have to correct myself here. Unfortunately, code actions do not allow passing additional parameters which is needed in this case to set the new name. I think, we have to resort to the textDocument/rename request although it has strictly speaking not the correct semantics.

[martinra]

I have thought about possibilities to avoid locking texlab out of the possibility to rename environments. textDocument/rename with the position on an environment would ideally rename that environment as that's what the LSP documentation suggests. So far I could think of two possibilities:

(1) One possibility is to use textDocument/rename on a \begin or \end part of \begin{ENV} ... \end{ENV}. This would strictly speaking rename the keyword begin or end, which is anyway not allowed. This way we would occupy a somewhat empty niche in the semantic space.

(2) I read through the exact documentation of CodeAction and found one way to pass parameters without completely violating the protocol. There is a diagnostics argument, that is intended to support the server in finding suitable CodeActions. One could pass something along the lines of "Can be renamed to ENVNEW". The server is allows to ignore the diagnostics argument, so this would be forward/backward compatible.

Right now I think (1) is a quite suitable way of doing things. Can you give me some critical feedback on this?

If we go for either (or any third solution), I think I'll write the rename environment and change environment in one merge request, if that suits you. This would be to avoid any oversights in their interaction when I wrap things in neovim.

[pfoerster]

(1) One possibility is to use textDocument/rename on a \begin or \end part of \begin{ENV} ... \end{ENV}. This would strictly speaking rename the keyword begin or end, which is anyway not allowed. This way we would occupy a somewhat empty niche in the semantic space.

While this would technically work, it kind of messes with the textDocument/prepareRename request. This request would either need to return the range of the \begin (which could be confusing) or move the rename range outside of the cursor (which is not explicity disallowed but feels wrong to do).

(2) I read through the exact documentation of CodeAction and found one way to pass parameters without completely violating the protocol. There is a diagnostics argument, that is intended to support the server in finding suitable CodeActions. One could pass something along the lines of "Can be renamed to ENVNEW"

I am still not sure how the server would receive the new name. The code action needs to contain a Command or a WorkspaceEdit, which we cannot provide because we do not know the new name.

Speaking about Command: I think, the only spec-compliant way to (re-)implement this feature right now would be to provide a custom command (something like texlab.changeEnvironment via workspace/executeCommand) that receives the cursor position and the new name. The command then applies a WorkspaceEdit which renames the environment. In this case, the client would be responsible for calling the command with the required arguments (e. g. command palette in VSCode or a custom Vim command). Maybe, we can optionally provide a command to allow the client to check if there is actually an environment at the cursor position.

[clason]

Yes, a custom command is the way to go here. Texlab has always been examplary at implementing the specification exactly (not like some other servers I could mention...)

And just as a reminder from the Neovim side: it was always the official design goal of the built-in LSP client to have server-specific plugins that handle custom commands and whatnot. Lspconfig was only ever meant to get the "simple" server up and running quickly, without bells and whistles.

[martinra]

Thank you! I wasn't aware of workspace/executeCommand (still lerning LSP). I'm at it and learning more of the texlab architecture. It might be a bit slow, but I'll post once I have an implementation.

[pfoerster]

@martinra Thank you for the PR! This feature has been released with v5.4.0 🚀