Quick fix

[jurgenvinju]

Describe the bug

Like to have a feature to trigger quick fixes on diagnostic messages.

Expected behavior

data Message (Command quickfix=noop());

That would allow the checker that produces a message to attach any Command.

When the user selects the quickfix, the command is sent over de LSP bridge to the server. The server will have a CommandExecutor ready (the same that also handles the lenses).

Open to any kind of information that can be serialized as a rascal value. So no limits.

[DavyLandman]

I think this is done with the code actions, where you can connect a refactoring to and diagnostic error. In that way there is a quick fix. So if we do this right (when implementing refactorings) well het this.

If you don't mind I'll tag this as feature request, not a bug.

[jurgenvinju]

So if we do this right (when implementing refactorings) well het this.

that does not make sense to me. I'm asking for a specific feature that links the "refactorings" or "quickfixes" that are embedded in our Message format to the code actions.

They are all "code actions", refactorings, quickfixes and lense commands alike, and they all need to be evaluated by the same command executor that the Rascal developers writes for their LSP server via util::LanguageServer

The difference lies in the way the user chooses for the action and fills in parameters.

• Quickfixes have all the parameters already resolved from the context of where the issue was created. The Command is a closed but informative term to be evaluated.
• Lenses get their parameters filled from the lense creator. The Command is again closed.
• Refactorings may have wizards and previews and such to acquire more information from the user (such as the renamed identifier). Parts of the command's fields may be filled in by user input before it is sent to the command evaluator.

[DavyLandman]

My understanding:

• Quickfixes in LSP are part of code-actions (See CodeActionKind::QuickFix).
• CodeActions can be linked to diagnostics. (Note that is also a set of diagnostics that VS Code shares with us when we actually get to execute a code action, but that's a different mess).
• Code actions have no way to ask for interaction with the user.
• Diagnostics cannot be linked to code-actions/commands. (although you can give them an error code, which can then be used from the code-action)
• The way quickfixes work in LSP is the exact same as refactoring, VS Code asks us (very frequently) if at a certain point in the tree, there are code-actions available, we get to reply with code-actions that we support in that place.

That lead me to reason that we should consider merging the quick-fix work with the effort to bring refactorings to rascal-lsp. I understand your point that quick-fixes are less complex than regular refactorings, as they require no extra interaction of user input (however, to be clear, CodeActions do not contain a way to model any of that input either). I wanted to point out that a lot of the mechanisms for registering & dealing with them are overlapping with generic refactorings. Especially since the UI interactions that would be needed for other style of refactoring will require a different part of the API.

If you prefer we split this up, we could try that indeed, but I fear that effort wise it would only save off a bit.