Skip to content

Use AnnotatedTextEdits throughout HLS #3210

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
michaelpj opened this issue Sep 22, 2022 · 6 comments
Open

Use AnnotatedTextEdits throughout HLS #3210

michaelpj opened this issue Sep 22, 2022 · 6 comments
Assignees
Labels
type: enhancement New feature or request

Comments

@michaelpj
Copy link
Collaborator

AnnotatedTextEdits are a feature of the LSP spec that allow more structured edits to be returned. In particular:

  • Multiple edits can be associated with a single annotation
  • The annotation can have a name and a description
  • The annotation can also indicate that the edit requires confirmation from the user

I haven't tested out what this looks like in the client, but in principle this should allow much nicer communication of what's going on with edits. For example, when adding imports for completions, we can annotate the edits for modifying imports to say what we're doing. The confirmation feature (if it actually works) seems nice for questionable or wide-ranging edits, like for renaming across modules.

We should try using them!

A good place to start would be here: https://github.com/haskell/haskell-language-server/blob/master/plugins/hls-refactor-plugin/src/Development/IDE/Plugin/CodeAction.hs#L202, which sends a message to the user to tell them what we did. Hopefully an AnnotatedTextEdit would do that job better.

@nilsalex
Copy link

nilsalex commented Oct 7, 2022

I would be interested in working on this @fendor

@michaelpj
Copy link
Collaborator Author

Did you get anywhere @nilsalex ?

@michaelpj
Copy link
Collaborator Author

See microsoft/vscode#151240

@michaelpj
Copy link
Collaborator Author

We will need to not send these if clients don't understand them. I had an idea for that. We can always translate an AnnotatedTextEdit into a TextEdit. So just before sending the response, we can check if the client supports what we're sending and downgrade it if it doesn't support that. I guess we can do this in combineResponses although that's somewhat gross.

We could potentially do this with something like this:

class Conform (m :: Method t k) where
  type Caps :: *
  caps :: Lens' ClientCapabilities Caps
  conform :: Caps -> ResponseResult m -> ResponseResult m

i.e. for a given method, given the capabilities relevant to that method, try to make the result we produced acceptable to the client by downgrading things.

This could probably live in lsp... and here's the issue I wrote, even: haskell/lsp#367

@nilsalex
Copy link

I played around with it a bit @michaelpj, switching to AnnotatedTextEdits for import list extensions (the place you suggested above).

Without requiring confirmation, I could not see any visual difference, neither in VS Code, nor with coc.nvim. With confirmation required, VS Code shows a list of changes before optionally applying them. I'll push my experiments to my fork.

@michaelpj
Copy link
Collaborator Author

That's a shame. I wish there was some guide in the spec showing what editors support what features, and what they actually do...

@michaelpj michaelpj added Hackathon This issue is suitable for hackathon sessions and removed level: easy The issue is suited for beginners labels May 17, 2023
@michaelpj michaelpj removed the Hackathon This issue is suitable for hackathon sessions label May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants