LSP — Semantic Diagnostics
LSP — Semantic Diagnostics
Start with meaning, then move to detail.
This lesson explains LSP — Semantic Diagnostics as part of getting started with Hermes correctly. You will learn what it does, when it matters, and the smallest safe test that proves it works.
If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?
For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.
For advanced readers, inspect When LSP runs, Supported languages, PowerShell, then verify failure modes and version compatibility.
No prior experience is required; follow the steps on a safe test setup first.
A clear outcome before you read.
- Understand LSP — Semantic Diagnostics without assumed prior knowledge.
- Separate the source description from what still needs testing in your environment.
- Read the first command and identify its inputs and outputs before copying it.
Real language servers (pyright, gopls, rust-analyzer, …) wired into the post-write lint check used by write_file and patch.
What does the source say, and in what order?
- 01When LSP runs
Start here to understand the core idea or structure.
- 02Supported languages
Read this after the foundation, then connect it to the previous step.
- 03PowerShell
Read this after the foundation, then connect it to the previous step.
- 04CLI
Read this after the foundation, then connect it to the previous step.
- 05Configuration
Read this after the foundation, then connect it to the previous step.
- 06Per-server keys
Read this after the foundation, then connect it to the previous step.
- 07Installation locations
Read this after the foundation, then connect it to the previous step.
- 08Performance characteristics
Read this after the foundation, then connect it to the previous step.
- 09Disabling
Read this after the foundation, then connect it to the previous step.
- 10Troubleshooting
Finish here to verify the result and special cases.
Copy only after you understand the effect.
{
"bytes_written": 42,
"dirs_created": false,
"lint": {"status": "ok", "output": ""},
"lsp_diagnostics": "LSP diagnostics introduced by this edit:\n<diagnostics file=\"/path/to/foo.py\">\nERROR [42:5] Cannot find name 'foo' [reportUndefinedVariable] (Pyright)\nERROR [50:1] Argument of type \"str\" is not assignable to \"int\" [reportArgumentType] (Pyright)\n</diagnostics>"
}hermes lsp status # service state + per-server install status
hermes lsp list # registry, optionally --installed-only
hermes lsp install <id> # eagerly install one server
hermes lsp install-all # try every server with a known recipe
hermes lsp restart # tear down running clients
hermes lsp which <id> # print resolved binary path# config.yaml
lsp:
# Master toggle. Disabling skips the entire subsystem — no servers
# spawn, no background event loop runs.
enabled: true
# How long to wait for diagnostics after each write.
wait_mode: document # "document" or "full"
# Max seconds to wait for the server to re-check the file after an
# edit. Only *fresh* diagnostics (produced for the post-edit
# content) are ever reported; if the server doesn't finish within
# this budget, the edit reports "no LSP data" rather than stale
# errors from before the edit. Raise this for slow servers on big
# projects (Read the first command and identify its inputs and outputs before copying it.
Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.