Symbol Rename

[Mandarancio]

Implementation of symbol renaming using the results from the lsp server:

• using get_token_range when no selection is active to get the symbol under the cursor
• using the result from lsp to rename the symbol across the project:
  • open all affected document
  • select and replace all symbol occurencies

I did not implement an automatic file save of the changes as it force the developer to open, (review), and save the changes manually (it could be a configuration).

There is still work to do as the LSP after the refactoring seems to be out of sync with the updated files, help with testing and debugging is needed

[jgmdev]

I have implemented this some time ago with support for previewing and approving the changes graphically pragtical/lsp#3

[Mandarancio]

@jgmdev nice, there are any plans to merge it into lite-xl-lsp?

[jgmdev]

Can be picked by any one for merging.

[Guldoman]

For now this approach is probably fine, and allows to relatively easily revert the changes.

In the future, if we want to add some interface for it, we'll design something (for example something like what I do in the copilot plugin for the "panel completions", but a bit more complete).

[Mandarancio]

I just realized that different LSP have different responses, for example clangd will reply with something like this

{
  "results": {
    "changes": {
      "$FILE_URI_0": [ ... ],
      "$FILE_URI_1": [ ... ]
    }
  }
}

While pyright will answer like:

{
  "results": {
    "documentChanges": [
      {
        "textDocument": { "uri": "$FILE_URI_0" },
        "edits": [ ... ]
      }, {
        "textDocument": { "uri": "$FILE_URI_1" },
        "edits": [ ... ]
      }
    ]
  }
}

There is a way to uniform the responses?

[Mandarancio]

I just realized that different LSP have different responses, for example clangd will reply with something like this

{
  "results": {
    "changes": {
      "$FILE_URI_0": [ ... ],
      "$FILE_URI_1": [ ... ]
    }
  }
}

While pyright will answer like:

{
  "results": {
    "documentChanges": [
      {
        "textDocument": { "uri": "$FILE_URI_0" },
        "edits": [ ... ]
      }, {
        "textDocument": { "uri": "$FILE_URI_1" },
        "edits": [ ... ]
      }
    ]
  }
}

There is a way to uniform the responses?

Implemented workaround that convert the two types of answer to a same structure

[Guldoman]

A few more things:

1. Set our client capabilities (in server.lua) to support textDocument.rename (but not the "prepared" part).
2. Check the server capability (renameProvider) before sending the request.
3. If the server capability is set, add a rename entry in the context menu.

[Guldoman]

Also check for response.error and log it out.

[Mandarancio]

1. Done
2. It was already checked
3. I have doubt how I can access to the document servers at the time of the context menu initialisation
4. Done