Consider adding `ruff.lint.run` to the native server

[dhruvmanila]

We didn't add this setting when implementing the native server but there are couple of request for this:

• `ruff-lsp` is deprecated; please upgrade to the native language server (`ruff server`) #15991 (comment)
• Searching for settings #18909 (comment)

[hunterhogan]

(Caveat: I don't have formal programming training or professional experience, so my technical vocabulary is limited and sometimes wrong. "Quotes" are my signal that I am trying to express a technical concept, but I do not believe I am using the correct technical term.)

Spell checking

Observation: The Grammarly app seems to forgo analysis of a sentence if the user is still composing it.

I am fairly confident that many spell checkers have similar mechanisms for validating a word.

I don't know if those subprocesses, however, could be applied to a real-time linter.

"Cheap" signals

Analyze-on-save and analyze-on-keystroke are both "cheap" signals. I cannot think of a "cheap" signal that is more targeted than on-save. If Ruff has the ability to track the location of the cursor, then perhaps y'all can figure out a clever, "cheap" way to use that as a signal to delay analysis of 1) the physical line on which the cursor is, 2) the "expression" in which the cursor is embedded, 3) some diagnostics about the "statement", "code block", FunctionDef/ClassDef/AsyncFunctionDef in which the cursor is embedded, and/or 4) other "levels" as appropriate and practical. Other than delaying analysis of the physical line, I suspect that the other ideas would require a bunch of "flags" to be added to various things, and I suspect it would be inefficient, have a low ROI, and be effectively impossible to maintain.

[dhruvmanila]

Thank you for the feedback. The heuristics that you've proposed about tracking various locations of the cursor are interesting but would be quite complicated and could impact the performance because it would require doing additional work on every keystroke. The main reason that those two signals (on save, on change) would cover most, if not all, of the use cases is because the client (editor) would be notifying us about those events and the server would just need to react on those events.