LSP-Plugin (Language Server)¶

Code-Intelligenz auf Basis des Language Server Protocol — Fehler-Unterschlängelungen, Navigation, Hover, Vervollständigung, Signaturhilfe, Formatierung, Referenzen finden, Umbenennen und Gehe-zu-Symbol — für jede Sprache mit einem Language Server. Der Editor spricht über LSP mit dem Server; das Plugin ist der Client. Welche Server es gibt, ist datengetrieben (ein kleines JSON pro Sprache) — C++/clangd unten ist nur eine von mehreren mitgelieferten Definitionen.

Der Editor bündelt oder lädt keine Server

Ein Language Server ist ein separates Programm, das Sie einmal installieren. MTE erkennt einen installierten Server und richtet ihn auf Ihr Projekt; es liefert nie einen mit. Siehe Einen Language Server beschaffen.

Aktuelle Funktionen¶

Funktion	Wie
Diagnosen	Fehler/Warnungen des Servers erscheinen als Wellenlinien (rot = Fehler, bernstein = Warnung, blau = Info, grau = Hinweis), aktualisiert beim Tippen.
Gehe zu Definition	Cursor auf ein Symbol und F12, oder Suchen ▸ Code-Navigation ▸ Gehe zu Definition. Springt zur Definition und öffnet bei Bedarf eine andere Datei.
Referenzen finden	Cursor auf ein Symbol → Shift+F12 (oder Suchen ▸ Code-Navigation ▸ Referenzen finden). Ergebnisse öffnen sich in einem unteren Referenzen-Panel, nach Datei gruppiert mit Quellzeilen-Vorschau; Doppelklick springt.
Hover	Zeiger über einem Symbol ruhen lassen; ein Popup zeigt Typ/Signatur und Dokumentation (gerendert aus dem Markdown des Servers).
Vervollständigung	Ctrl+Space fragt den Server nach Vervollständigungen und mischt sie in das Vervollständigungs-Popup des Editors (vor den eingebauten Schlüsselwort-/Pufferwort-Vorschlägen), gefiltert beim Tippen.
Signaturhilfe	Das Tippen von `(` eines Aufrufs oder `,` zeigt einen Calltip mit der Funktionssignatur und dem hervorgehobenen aktiven Parameter; `)` schließt ihn.
Dokument formatieren	Alt+Shift+F (oder Bearbeiten ▸ Dokument formatieren) formatiert das ganze Dokument über den Server, als ein Rückgängig-Schritt. Den Stil bestimmt die Konfiguration des Servers (bei clangd eine `.clang-format`-Datei).
Referenzen finden (oben gelistet)	—
Symbol umbenennen	Cursor auf ein Symbol → Shift+F6 (oder Bearbeiten ▸ Symbol umbenennen). Neuen Namen eingeben; jede Verwendung wird aktualisiert. Umfasst das Umbenennen mehrere Dateien, werden Sie erst um Bestätigung gebeten — jede Datei wird geöffnet, geändert und modifiziert belassen, damit Sie prüfen und speichern.
Gehe zu Symbol (in Datei)	Ctrl+Shift+O öffnet die Befehlspalette mit allen Symbolen der aktuellen Datei (Funktionen, Klassen, Methoden…); tippen filtert, Enter springt. Jede Zeile zeigt Symbolart und Container.
Gehe zu Symbol im Arbeitsbereich	Ctrl+T durchsucht beim Tippen Symbole im ganzen Projekt (der Server matcht die Anfrage); Enter öffnet die Datei am Symbol.

Die Gehe-zu-Symbol-Auswahlen sind die Symbolmodi der Befehlspalette — siehe Befehlspalette.

Dateiübergreifende Referenzen und Umbenennen brauchen den Server-Index

Referenzen finden und Umbenennen erreichen andere Dateien erst, wenn der Server das Projekt indiziert hat. Für C/C++ heißt das compile_commands.json (siehe unten) und clangds Hintergrund-Index; ohne ihn arbeiten sie nur auf der aktuellen Datei.

Umbenennen ist vorerst Rückgängig pro Datei

Ein mehrdateiiges Umbenennen wird Datei für Datei angewendet, jede Datei ist also ein eigener Rückgängig-Schritt (der Bestätigungsdialog sagt das). Prüfen Sie die geänderten Tabs vor dem Speichern.

Die Server-Statusanzeige¶

Die Statusleiste zeigt ein kompaktes LSP:-Segment (links der anderen Plugin-Segmente), das jeden für Ihre offenen Dateien relevanten Language Server zusammenfasst:

LSP: cpp ✓  python ↻2  rust ✗

Zeichen	Bedeutung
`…`	Startet — der Server wurde gestartet und verhandelt gerade.
`✓`	Bereit — bedient Anfragen.
`↻n`	Neustart — der Server endete unerwartet; automatischer Neustartversuch n ist geplant.
`✗`	Dunkel — entweder ist für die Sprache kein Server installiert, oder der Server stürzte wiederholt ab und die automatischen Neustarts haben aufgegeben.

Das Segment erscheint, wenn das erste Dokument einer konfigurierten Sprache öffnet, verfolgt nur Sprachen mit tatsächlich offenen Dokumenten — das Schließen der letzten Datei einer Sprache entfernt ihren Eintrag (ein erneutes Öffnen bringt ihn sofort zurück) — und verschwindet ganz, wenn kein solches Dokument mehr offen ist.

Wenn ein Server abstürzt¶

Ein unerwartet beendeter Language Server wird automatisch neu gestartet, mit wachsender Verzögerung (1 s, 2 s, 4 s… gedeckelt bei 30 s). Währenddessen zeigt die Anzeige ↻n, und eine Statusleisten-Benachrichtigung meldet den ersten Absturz. Nach einem erfolgreichen Neustart werden Ihre offenen Dokumente dem Server erneut gemeldet, und die Diagnosen kommen von selbst zurück; veraltete Wellenlinien des toten Servers werden sofort gelöscht. Das Bearbeiten wird nie blockiert.

Nach 5 fehlgeschlagenen Versuchen in Folge gibt das Plugin auf: Die Anzeige zeigt ✗, eine Benachrichtigung verweist auf die Einstellungen, und die Sprache bleibt dunkel, bis Sie manuell neu starten. Ein Server, der mindestens eine Minute sauber lief, erhält bei einem späteren Absturz frische Versuche.

Manueller Neustart — eine der beiden Möglichkeiten:

Suchen ▸ Code-Navigation ▸ Language Server neu starten (kein Standard-Kürzel; auch über die Befehlspalette), oder
der Knopf Neu scannen / Server neu starten in Einstellungen ▸ Language Server.

Beide fahren alle Server herunter, wiederholen die Erkennung mit den aktuellen Einstellungen und setzen das Fehlerbudget zurück — nützlich nach der Installation eines fehlenden oder der Reparatur eines defekten Servers.

Einen Language Server beschaffen¶

Installieren Sie den Server für Ihre Sprache und stellen Sie sicher, dass er im PATH liegt (oder setzen Sie einen expliziten Pfad in den Einstellungen). Wird keiner gefunden, tut die Funktion für diese Sprache schlicht nichts — die Statusanzeige zeigt ✗, und das Protokoll vermerkt einen einmaligen Hinweis, aber nichts unterbricht Sie.

MTE liefert Server-Definitionen (nicht die Server) für viele Sprachen, meist genügt also die Installation des Servers — kein JSON-Editieren. Mitgelieferte Definitionen decken C/C++, Python, Rust, Go, TypeScript, JavaScript, C#, Java, HTML, CSS, JSON, YAML und Bash ab (plus vorausschauende Einträge für Kotlin, Swift und Objective-C, die aktiv werden, sobald diese Sprachen Syntaxhervorhebung erhalten).

Sprache	Server	Woher
C/C++	clangd	`winget install LLVM.LLVM` (Windows), die Komponente „C++ Clang tools“ im Visual-Studio-Installer, `brew install llvm` (macOS) oder das Paket `clang-tools-extra` Ihrer Distribution.
Python	pyright	`npm i -g pyright`.
TypeScript/JS	typescript-language-server	`npm i -g typescript-language-server typescript`.
Rust	rust-analyzer	`rustup component add rust-analyzer`.
Go	gopls	`go install golang.org/x/tools/gopls@latest`.

Prüfen Sie im Terminal, z. B. clangd --version. Für eine Sprache ohne mitgelieferte Definition fügen Sie eine hinzu wie in Eine Sprache hinzufügen beschrieben.

C/C++-Projekte brauchen `compile_commands.json`¶

clangd versteht Ihren Code nur dann präzise, wenn es die Compile-Flags kennt — aus einer Kompilierungsdatenbank (compile_commands.json). Ohne sie rät clangd, und dateiübergreifende Funktionen (Referenzen finden, Umbenennen) bleiben auf die offene Datei beschränkt.

MTE findet eine compile_commands.json automatisch — es durchsucht die Projektwurzel und übliche Build-Verzeichnisse (build/, out/, cmake-build-*, .mte-compile-commands/) und richtet clangd darauf. Die Datenbank erzeugen Sie; der Editor nicht (das zuverlässige Konfigurieren eines beliebigen Projekts braucht Ihre Toolchain-/SDK-Umgebung, die der Editor nicht hat). Fehlt sie in einem C/C++-Projekt, zeigt MTE einen einmaligen Hinweis (mit Nicht mehr anzeigen), der hierher verweist.

Erzeugen (CMake)¶

CMAKE_EXPORT_COMPILE_COMMANDS beachten nur die Ninja- und Makefile-Generatoren — der Visual-Studio-Generator ignoriert es (er erzeugt auch mit gesetztem Flag keine compile_commands.json). Erzeugen Sie die Datenbank also mit Ninja, in ein eigenes Verzeichnis, getrennt von Ihrem üblichen Build-Verzeichnis: CMake weigert sich, ein bestehendes Build-Verzeichnis mit anderem Generator neu zu konfigurieren — ein sonst mit Visual Studio gebautes Projekt braucht sein eigenes Ninja-Verzeichnis.

Das ist ein reiner Konfigurationsschritt (kein vollständiger Build nötig). Aus der Projektwurzel:

cmake -S . -B .mte-compile-commands -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

.mte-compile-commands/ gehört zu den von MTE gescannten Verzeichnissen, die entstehende compile_commands.json wird also automatisch gefunden. Jedes gescannte Verzeichnis funktioniert (build/, out/, cmake-build-* oder die Projektwurzel) — halten Sie es nur getrennt von einem mit anderem Generator konfigurierten Verzeichnis.
Führen Sie es in einer Umgebung aus, in der das Projekt wirklich konfiguriert: der richtige Compiler im PATH (z. B. ein x64 Native Tools Command Prompt unter Windows) und alle Variablen, die Ihr Projekt braucht (etwa QT6_DIR für ein Qt-Projekt). Findet cmake Compiler oder SDK nicht, wird die Datenbank leer oder ohne Include-Pfade, und clangd indiziert schlecht.
Öffnen Sie den Ordner danach neu. Das Protokoll sollte nicht mehr „no compile_commands.json“ melden; geben Sie clangd einen Moment für seinen Hintergrund-Index, bevor Referenzen/Umbenennen Dateien übergreifen.

Andere Build-Systeme: Bear (bear -- make), compiledb, Meson, Bazel und weitere können ebenfalls eine compile_commands.json erzeugen, die das Plugin findet.

Eine Sprache hinzufügen¶

Server werden durch JSON-Dateien beschrieben, die das Plugin beim Start aus <editor>/lsp-servers/*.json lädt. Jeder Eintrag bildet eine Sprache auf ihr Kommando plus Erkennungshinweise ab:

{
    "language":    "cpp",
    "command":     "clangd",
    "aliases":     ["clangd-18", "clangd-17"],
    "args":        ["--background-index"],
    "extensions":  [".cpp", ".h", ".hpp"],
    "searchDirs":  ["${LLVM}/bin", "${ProgramFiles}/LLVM/bin"],
    "docsAnchor":  "cpp-clangd",
    "compileCommandsArg": "--compile-commands-dir=${dir}"
}

language entspricht der vom Editor erkannten Sprach-ID; command/aliases sind die im PATH probierten Programmnamen; searchDirs (mit ${VAR}-Auflösung) sind zusätzliche Installationsorte.
compileCommandsArg (optional) wird angehängt, mit ${dir} ersetzt durch das gefundene Datenbank-Verzeichnis — so wird clangd auf compile_commands.json gerichtet.

Wie ein Server gefunden wird¶

Für ein passendes Dokument löst das Plugin den Server in dieser Reihenfolge auf: ein explizit konfigurierter Pfad → command und seine aliases im PATH → die searchDirs des Eintrags und Ökosystem-Orte. Der Server startet einmal pro Sprache und wird mit dem Editor beendet.

Language-Server-Einstellungen¶

Einstellungen ▸ Language Server listet jede Sprache mit vorhandener Server-Definition. Pro Sprache können Sie:

den Server aktivieren / deaktivieren (eine deaktivierte Sprache startet nie einen);
einen expliziten Programmpfad setzen (mit Durchsuchen…). Diese Vorgabe gewinnt gegen die PATH/searchDirs-Suche oben — nützlich, wenn der Server nicht im PATH liegt oder Sie einen bestimmten Build wollen.

Änderungen greifen bei OK / Übernehmen: Hat sich ein Aktivieren-Flag oder ein Pfad tatsächlich geändert, starten die Server automatisch mit den neuen Einstellungen neu (eine unberührte Seite stört laufende Server nie). Der Knopf Neu scannen / Server neu starten erzwingt zusätzlich Abbau und Neuerkennung mit den aktuellen Einstellungen — nützlich nach der Installation eines zuvor nicht gefundenen Servers; er setzt auch das Absturz-Neustart-Budget zurück.

Grenzen¶

Code-Färbung in Hover-Popups wird nicht angewendet (der Text ist formatiert — fett, Überschriften, Monospace-Code — aber nicht syntaxhervorgehoben).
Die Genauigkeit hängt vom Server ab: Bei C/C++ ohne compile_commands.json greift clangd auf Heuristiken zurück, und die Ergebnisse können unvollständig sein.