Skip to content
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

API RFC: Allow solutions callback in API #1705

Open
steelbrain opened this issue Jul 27, 2020 · 2 comments
Open

API RFC: Allow solutions callback in API #1705

steelbrain opened this issue Jul 27, 2020 · 2 comments

Comments

@steelbrain
Copy link
Owner

Currently solutions in Linter messages are an array, their callbacks can still be async tho. Nikolay pointed out in https://github.com/orgs/atom-ide-community/teams/atom-community/discussions/1/comments/5 that it would help with integrations in LSP-context if we made the solutions API async.

The usecase makes sense to me and it's not a major change. The API version will have to be bumped, semver-minor

@lierdakil
Copy link
Contributor

To make it clear(er), here is roughly what I had in mind (TypeScript syntax because I don't grok flowjs):

type SolutionsArray = Array<
  | {
      title?: string
      position: Range
      priority?: number
      currentText?: string
      replaceWith: string
    }
  | {
      title?: string
      position: Range
      priority?: number
      apply: () => any
    }
>
type Message = {
  // ...
  solutions?: SolutionsArray | (() => Promise<SolutionsArray>)
  // ...
}

But I think it'd be best to first poke around and experiment with some approaches in https://github.com/atom-ide-community/atom-ide-languageclient to see if it actually makes sense before implementing it in linter API. I might find time to do that sometime this week.

@aminya aminya pinned this issue Jan 1, 2021
@illright
Copy link

illright commented Jan 4, 2021

Yep, that makes sense in terms of the LSP API. The textDocument/publishDiagnostics notification will give us a list of diagnostics which we convert to messages, but in order to get the solutions for those messages, we must submit a textDocument/codeAction request, linking in the relevant diagnostics, which is exactly the job for this async callback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants