Output Formats & Editor Integration

Linters need multiple output formats:

• Human: file.py:12:5: E501 line too long (105 > 80 characters). Default.
• JSON: machine-readable for tools.
• JUnit XML: CI integration.
• GitHub Actions: ::warning file=...,line=...,col=...::message annotations.
• SARIF: standard for security findings.

Editor integration via LSP (Language Server Protocol):

• Editor sends textDocument/didChange.
• Server runs lint on the buffer (in-memory, not on disk).
• Server returns textDocument/publishDiagnostics: [{range, severity, message, code}, ...].
• Editor draws squiggles + populates Problems panel.

Quick fixes:

• Each diagnostic CAN come with a codeAction describing an edit.
• Editor offers "Quick Fix" (Ctrl+.) → applies edit.
• Examples: "Add unused import to __all__", "Replace == with is", "Add # noqa".

{
  "diagnostic": {
    "range": {"start": {"line": 11, "character": 0}, "end": {"line": 11, "character": 105}},
    "severity": 2,
    "code": "E501",
    "message": "line too long (105 > 80)"
  },
  "actions": [
    {"title": "Wrap line", "kind": "quickfix", "edit": { ... }}
  ]
}

Performance matters: editor calls lint on EVERY keystroke (debounced ~150ms). Lint must be ms-fast for medium files. Hence Ruff's reputation — written in Rust, 100x faster than pylint.

Caching: hash file content; skip re-lint if unchanged.

CI integration: --exit-zero (always exit 0 for advisory) vs default (exit non-zero on findings, fails the build).