I am trying to use the linter package and am stuck on an issue with the forceLinting(). In our use case, we have editor states that can affect the parsing/linting of the editor content. When these state fields change I need the linter to re-run to react, but if I call forceLinting(), it does nothing unless there is an outstanding state change with docChanged set (it is predicated on this.set being true). Is there something I am missing? Is there some other clean way to get the linter to re-run on certain non-document state changes?
Do you think this patch solves your issue? It allows you to specify a predicate to indicate when linting should be updated on editor state changes.
Yes, I think that would work well. As I noted, we already have all of. our context represented in state fields, so it would be easy to check for a change in an update.
I’ve tagged 6.2.0 with this feature.
Unfortunately it’s not clear how this should be configured and called…
A simple example would be helpful.
This is a simplified excerpt form the code we created using this feature:
function linterExtensions() {
return [
linter(
(view) => {
const state = view.state;
// Get our state field value that affects the lint results.
const names = state.field(nameField);
// Compute lint values from state.doc and names
// ...
return [{from, to, message, severity}];
},
{
// Returns true if we need to update our lint results based on a non-document change
// in the update. In this code, we are checking for a field that we have created and updated
// elsewhere called "namesField".
needsRefresh: (update) => {
const startNames = update.startState.field(namesField);
const newNames = update.state.field(namesField);
return startNames !== newNames;
},
}
),
lintGutter(),
];
}
1 Like
Thank you, that’s helpful!