Claude Code erhält native LSP-Unterstützung

 (github.com/anthropics)
18 Punkte von GN⁺ 2025-12-23 | 2 Kommentare | Auf WhatsApp teilen
  • Claude Code, ein KI-basiertes Coding-Tool für das Terminal, hat in der neuesten Version ein LSP-Tool (Language Server Protocol) hinzugefügt
  • Dadurch bietet es Code-Intelligence-Funktionen auf IDE-Niveau wie Go-to-Definition, Find References und Dokumentation per Hover
  • Der Befehl /terminal-setup unterstützt offiziell die Terminals Kitty, Alacritty, Zed und Warp
  • Im /theme-Bildschirm kann Syntax-Highlighting mit Ctrl+T ein-/ausgeschaltet werden
  • Es wurde ein Leitfaden für Terminal-Einstellungen hinzugefügt, falls Alt-Tastenkürzel unter macOS nicht funktionieren, und die macOS-Tastenkürzelnotation wurde zur Übereinstimmung mit den tatsächlichen Tastenkappen einheitlich von alt auf opt umgestellt
  • Die Ausgabe des Befehls /context wurde verbessert: Skills und Agents werden nach Quelle gruppiert, nach Slash-Befehlen geordnet und nach Token-Verbrauch sortiert

Verwandte Beiträge

2 Kommentare

 
aqqnucs 2025-12-23

Ich habe Serena verwendet, aber eingebaut ist am Ende doch genau das Richtige.
 
GN⁺ 2025-12-23
Hacker-News-Kommentare

  • Ich verstehe nicht, warum JetBrains seine Refactoring-Tools nicht in AI-Systeme integriert hat
    Selbst einfache Aufgaben wie das Umbenennen von Funktionen hätten dann mit viel kleinerem Kontext statt durch Bearbeitung von Hunderten Dateien erledigt werden können, was wirklich schade ist
    LSP-Unterstützung ist ein guter Anfang, aber ohne Code-Transformationsfunktionen bleibt es weiterhin unzureichend
    Auch die LSP-Qualität von JetBrains ist nicht besser als die übliche

    • In letzter Zeit wirkt JetBrains etwas orientierungslos
      Nachdem sie den Commit-Dialog entfernt und die Preise erhöht haben, habe ich ernsthaft überlegt, nach über zehn Jahren Nutzung zu wechseln
      Ein aktuelles Beispiel für so einen Fehltritt sieht man auch in diesem Blogpost
    • Das wirkt wie ein typisches Innovator’s Dilemma
      JetBrains hat mit seiner PSI-Engine das beste Verständnis von Code-Semantik, ist aber weiterhin an das Paradigma gebunden, dass Menschen die IDE direkt bedienen
      Claude Code oder Cursor sehen den Editor als Canvas, den die AI frei steuern kann, während JetBrains AI nur als einfaches Sidebar-Plugin behandelt
      Wenn sie ihre internen Refactoring-Tools nicht für Agenten öffnen, verschwindet die Reibung beim Wechsel zu VS Code
    • JetBrains sollte sich nicht an seiner eigenen AI Junie festbeißen, sondern sich darauf konzentrieren, mit bereits etablierten Tools zu integrieren
      Sonst wird VS Code den Markt verschlingen
    • Das Problem war Arroganz
      Früher hatten sie hohe Eintrittsbarrieren, aber VS Code hat das eingerissen
      Sie haben den Wandel überhaupt nicht kommen sehen und wirken jetzt orientierungslos
    • Microsoft macht einen ähnlichen Fehler
      Sie haben Roslyn und Copilot nicht sauber zusammengebracht
      Ein Roslyn-Analyzer ist nicht nur ein einfacher Linter, sondern ein mächtiges Werkzeug, das sogar Code-Transformationen durchführen kann, daher ist es frustrierend zu sehen, wie AI das immer noch mit einfachem Find/Replace erledigt
      Wenn ein Roslyn-basierter Agent auftaucht, wird die Effizienz bei der Arbeit an großen Codebasen explosionsartig steigen

  • Ich bin gegenüber der Kombination Claude Code / Codex CLI + LSP sehr positiv eingestellt
    Ich habe am Wochenende Codex ausprobiert, und weil es beim Umbenennen von Funktionen oder Verschieben von Symbolen Verweise verpasst hat, habe ich selbst einen Skill gebaut, der das Python-Refactoring-Tool Rope anbindet
    Ich bin ziemlich zufrieden damit

    • Im Grunde hat ein OpenAI-Ingenieur statt der F2-Taste den Copilot-Button gedrückt und deshalb das Umbenennen von Referenzen versemmelt
      Dass es keine LSP-Unterstützung gibt, ist wirklich seltsam
    • Mit Codex Version 5.1 war es nicht besonders gut, aber ich frage mich, ob es jetzt besser ist als Claude Code
    • Es überrascht mich, dass man so etwas selbst innerhalb von OpenAI bauen muss
      Das zeigt, wie viel hier noch zu tun ist

  • Da die offizielle Dokumentation unzureichend ist, teile ich, was ich selbst herausgefunden habe
    Mit dem Befehl /plugin öffnet man den Plugin-Manager von Claude Code, sucht im Discover-Tab nach lsp, aktiviert es mit der Leertaste und installiert es dann mit i

    • Ich war anfangs auch überrascht, als Claude mich fragte, ob das Go-LSP installiert werden soll
      Im aktuellen Changelog habe ich dann gesehen, dass die Funktion erst vor drei Tagen hinzugefügt wurde
      Sie ist noch experimentell und deshalb standardmäßig deaktiviert
    • Auch in der neuesten Version erscheint bei der Suche nach mcp nichts
      Die Funktion wirkt noch unfertig
      Hoffentlich wird Claude künftig LSP automatisch erkennen
    • Wenn man ein benutzerdefiniertes LSP hinzufügen will, muss man es in einen Claude-Code-Plugin-Wrapper packen
      Die zugehörige Dokumentation gibt es hier

  • Die Claude-Code-UX von Anthropic ist unter den großen AI-Produkten die schlechteste
    Schon simples Kopieren und Einfügen von Text ist umständlich, und Nutzerfeedback wird ignoriert
    In diesem Zustand weiß ich nicht, warum ich das statt ChatGPT verwenden sollte

  • Ich nutze seit sechs Monaten das Open-Source-Projekt OpenCode, und es hatte solche Funktionen bereits
    Der langsame Fortschritt geschlossener Software überrascht mich
    Ich kann es empfehlen, weil man es zusammen mit einem Claude- oder Copilot-Abo nutzen kann

    • Ich wollte OpenCode mögen, weil ich Open Source und Provider-Unabhängigkeit bevorzuge, aber in der Praxis war Claude Code stabiler
      OpenCode hatte Performance-Probleme wie 100 % CPU-Auslastung während wartender Freigaben oder Fehlverhalten durch Popovers
      Allerdings hat auch Claude Code Bugs wie Flackern beim Scrollen
    • Ich schaffe es nicht, OpenCode richtig auszureizen
      Claude Code liefert sofort gute Ergebnisse, während OpenCode schon bei der Modellanbindung schwierig ist und weniger effizient wirkt
      Vermutlich liegt das daran, dass das Prompt-Tuning von Claude Code schon länger gereift ist
    • Open Source kann schnell handeln, weil die Entscheidungsstruktur einfacher ist
      Man verschwendet keine Zeit damit, verschiedene Stakeholder zu überzeugen oder Sprints neu abzustimmen
    • Das Setup-Erlebnis von OpenCode ist unter den CLI-Tools das einfachste und intuitivste
      Allerdings gibt es immer wieder kleine Bugs und Abstürze
    • Das Entwicklungstempo von OpenCode ist extrem hoch
      Wenn morgens jemand AGI ankündigt, ist es abends schon integriert
      Ich teste auch zwischen vielen Tools hin und her, aber OpenCode entwickelt sich konstant weiter

  • Es wirkt seltsam, dass so viele Leute sich für Werkzeuge in CLI-Form begeistern
    IDE-basierte Agenten bieten solche Funktionen bereits von Haus aus, daher frage ich mich, ob es wirklich effizient ist, diff oder LSP extra im Terminal nachzubauen
    Cursor unterstützt so etwas schon seit Langem

    • LSP wurde ursprünglich so entworfen, dass ein Server von mehreren Clients gemeinsam genutzt wird
      Für eine CLI reicht es also, einen kleinen Client zu bauen, der sich mit dem LSP-Server verbindet
      Es gibt keinen Grund, warum nur IDEs exklusiv von LSP profitieren sollten
    • Auch Nicht-Entwickler finden die Claude-Code-CLI offenbar natürlicher
      Das Terminal ist nicht nur ein Ort zum Bearbeiten von Code, sondern ein Raum, in dem man den gesamten Computer orchestriert
      Das ist ähnlich wie bei kubectl, das sich auch nicht zu einer GUI weiterentwickelt hat
      Passender Artikel: It's on your computer
    • Ich frage mich, ob Agenten innerhalb von IDEs überhaupt Zugriff auf LSP haben
      Zed kann beispielsweise LSP-Informationen nicht nutzen, wenn kein MCP-Server vorhanden ist
    • Mein Editor und mein Chatbot laufen beide im Terminal, daher will ich gar nicht erst in eine IDE wechseln
      Die CLI fühlt sich besser an als die unvollständige UI einer Desktop-App
    • Der Vorteil der CLI ist die Freiheit von Abhängigkeit zu einer bestimmten IDE

  • Wie ich auch in meinem jüngsten Beitrag geschrieben habe, gibt es enorme Verschwendung von Tokens und Energie, weil LLMs ineffizient betrieben werden
    Entscheidend ist, es LLMs leichter zu machen, Werkzeuge zu nutzen
    Das ist ein Prinzip, das nicht nur fürs Programmieren gilt, sondern für alle Bereiche

    • In ein paar Jahren werden wir beschämt auf das heutige ineffiziente Tool-Ökosystem zurückblicken
      Wir sollten die Umweltschäden durch Verschwendung von Energie, Wasser und Ressourcen mitbedenken
    • Es gab bereits Versuche, solche Probleme zu lösen
      Zum Beispiel gibt es Projekte wie Serena

  • Mein Lieblingsagent Crush unterstützt LSP bereits
    Allerdings nutzt der Agent diese Funktion in der Praxis nicht besonders häufig
    Crush GitHub-Link

    • Ich frage mich, ob es einen Unterschied gemacht hätte, in AGENT.md die installierten LSP-Server explizit aufzuführen

  • Ich habe bisher noch keinen Fall gesehen, in dem LSP tatsächlich genutzt wurde
    Opus 4.5 hat ein stabiles QA-Timing, und auch Lint-Checks funktionieren außerhalb der IDE gut
    Wenn Definitionen tief versteckt sind, kann LSP nützlich sein
    Claude bietet laut eigener Angabe folgende LSP-Funktionen an

    • goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, outgoingCalls usw.

  • LSP sollte eine API in Form von Shell-Befehlen bereitstellen
    Dann würde die Integration mit LLMs einfacher und auch für Menschen nützlicher

    • Es gibt bereits CLI-Frontends wie lsp-cli
      Für LLMs ist es jedoch effizienter, LSP über ein dediziertes Tool zu verwenden als über einfache Shell-Befehle