-
Notifications
You must be signed in to change notification settings - Fork 101
Description
It might make some sense to provide code actions to fix code for diagnostics results from lintr given the list of linters.
The fix of many linters could be quite easy (e.g. assignment_linter
, commas_linter
, implicit_integer_linter
, T_and_F_symbol_linter
) while others not trivial or impossible to fix (e.g. cyclocomp_linter
) without user discretion.
The problem here is that should the possible fix of each linter should be implemented in the lintr package itself, or another package, or in languageserver?
I guess lintr package is the ideal place to provide possible fixes, i.e. if a linter finds an issue in the code, then it has the best knowledge of how it should be fixed. If each lint result also provides an optional fix field that contains a list of edits (not necessarily using exactly the same data structure in lsp), each contains a range and new text (just like https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textEdit), then it is much easier for us to transform these edits to WorkspaceEdit provided in code actions.