Exactly. So given the situation up above where we had two seperate actions from one another the data field coming with the Diagnostic would look like this:
{
"data": {
"actions": [
{
"title": "Apply suggestion: \"pprint is outdated, update to 0.8.1\"",
"edit": {
"changes": {
"file:///Users/ckipp/Documents/scratch-workspace/actionable-diagnostic/Main.scala": [
{
"range": {
"start": {
"line": 1,
"character": 15
},
"end": {
"line": 1,
"character": 40
}
},
"newText": "com.lihaoyi::pprint:0.8.1"
}
]
}
}
},
{
"title": "Remove pprint as a dependency",
"edit": {
"changes": {
"file:///Users/ckipp/Documents/scratch-workspace/actionable-diagnostic/Main.scala": [
{
"range": {
"start": {
"line": 1,
"character": 15
},
"end": {
"line": 1,
"character": 40
}
},
"newText": ""
}
]
}
}
}
]
}
}
The schema for this would then basically be:
export interface ScalaAction {
title: string;
description?: string;
/**
* This would be a WorkspaceEdit according to the LSP spec, however to start we
* would only be supporting "changes". This should cover all the initial use-cases
* we thought of while also allowing us then to add in the resource operations later.
*/
edit: WorkspaceEdit;
}
Again, this is prretty minimal, but also the core of what we actually need. Later on we’d be able to dig into documentChanges which would allow for resource operations, but again I think this should be fine to start out with and would cover the vast majority of use-cases that we had in mind.
If we agree on this, I can shoot in a pr to Problem in sbt-interfaces to get the ball rolling on this and also update the scala-cli/metals prs to this as well.