- Die von mehr als 2.000 Entwicklern gewünschte Debugging-Funktion wurde nun endlich in Zed umgesetzt
- Der Debugger wurde mit Fokus auf Geschwindigkeit, Vertrautheit und Konfigurierbarkeit entwickelt
- Unterstützung für populäre Sprachen wie Rust, C/C++, JavaScript, Go und Python sowie für Erweiterungen auf Basis des Debug Adapter Protocol (DAP) wird bereitgestellt
- Mit dem intuitiven LOCATORS-System lässt sich in den meisten Projekten ohne separate Konfiguration einfach debuggen
- Durch eine getrennte Architektur von UI- und Datenebene ist eine starke Grundlage für kollaboratives Debugging und Erweiterbarkeit geschaffen
Veröffentlichung des Zed-Debuggers
- Auf Wunsch von mehr als 2.000 Entwicklern wurde im Zed-Editor offiziell eine Debugging-Funktion eingeführt. Das ist ein sehr wichtiger Fortschritt auf dem Weg zu Zed 1.0
Hauptziele
- Geschwindigkeit: Schneller Kontextwechsel und eine effiziente Debugging-Erfahrung
- Vertrautheit: Im Einklang mit Zeds Designsprache und mit Unterstützung für alle Funktionen, die man von einem typischen Debugger-Workflow erwartet
- Konfigurierbarkeit: UI, Keybindings und Debug-Konfigurationen können frei an die eigenen Bedürfnisse angepasst werden
Sprach- und Erweiterungsunterstützung
- Wichtige Sprachen wie Rust, C/C++, JavaScript, Go und Python werden standardmäßig unterstützt
- Kann mit allen Debug-Adaptern zusammenarbeiten, die das Debug Adapter Protocol (DAP) implementieren
- Über das Erweiterungssystem lassen sich zusätzliche Sprachen und Debugging-Funktionen einfach hinzufügen
Einfache Debugging-Konfiguration
- Mit LOCATORS wurde ein neues System eingeführt, das Build-Konfigurationen in Debug-Konfigurationen umwandelt
- Nachdem einmal ein Build-Task in
tasks.json definiert wurde, kann er in debug.json referenziert oder über Zeds automatische Konfiguration genutzt werden
- Zed führt Locators automatisch aus, entweder integriert oder über ausführbare Dateien des Language Servers
- In den meisten Fällen ist die Nutzung sofort ohne separate Debug-Konfiguration möglich
- Aktuell gibt es Locator-Unterstützung für Cargo, Python, JavaScript und Go (weitere Sprachen folgen)
Funktionen von Debugging-Sitzungen
- Innerhalb von Zed lassen sich Programmzustände wie Threads, Variablen, Breakpoints und Call Stack einfach prüfen
- Das Debugger-Panel ist vollständig anpassbar, sodass Tabs per Drag-and-drop sortiert und Panels frei verschoben werden können
- Auch tastaturzentriertes Debugging wird unterstützt: Code-Navigation, Umschalten von Breakpoints und Wechsel zwischen Sitzungen sind ohne Maus möglich
Hochgradig erweiterbare Architektur
- Für eine Struktur, die Debugging in verschiedenen Sprachen, kollaborative Umgebungen, Erweiterungsunterstützung sowie effizientes Daten-Caching und -Management ermöglicht, wurde eine zweischichtige Architektur entworfen
- Datenebene: Kommuniziert direkt mit dem Debug-Adapter, hält den Sitzungsstatus, cached Antworten und verwaltet die Invalidierung veralteter Daten
- UI-Ebene: Fordert nur die benötigten Daten an und konzentriert sich auf das Rendern der Oberfläche
- Durch diese Trennung lässt sich kollaboratives (Multiplayer-)Debugging leicht umsetzen und zugleich Netzwerkbandbreite sparen
Erweiterungs-API und Einsatz von DAP
- Da es mehr als 70 verschiedene DAP-Implementierungen gibt, wird nicht alles standardmäßig unterstützt; stattdessen wurde Zeds Erweiterungs-API erweitert, um Debugger-Integrationen zu ermöglichen
- DAP-Unterstützung kann erweitert werden, etwa durch eigene Schemadefinitionen, Implementierung von Adapter-Download- und Ausführungslogik, Einspeisung von Standardwerten für Debug-Konfigurationen sowie Locator- und Auto-Integration
- Ähnlich wie bei der Erweiterung von LSP (Language Server Protocol) können Entwickler ihre eigenen Debug-Adapter leicht in Zed integrieren
Unterstützung für Inline-Variablenwerte
- Die Anzeige von Inline-Variablenwerten gehört nicht zu DAP, sondern zu LSP, und kann im bisherigen Ansatz nur bereitgestellt werden, wenn DAP und LSP beide zusammenwirken
- Einfache Mustererkennung etwa per regulärem Ausdruck ist wegen Problemen mit Scopes, Kommentaren usw. weniger präzise
- Mit Tree-sitter werden Variablen innerhalb des Scopes des aktuell ausgeführten Codes präzise identifiziert
- Sprachspezifische Unterstützung ist über
.scm-Dateien auch ohne separate LSP-Integration möglich
- Zum Start werden Python, Rust und Go unterstützt, weitere Sprachen sollen folgen
- Zed ist ein Editor, der von den Erfindern von Tree-sitter entwickelt wurde
Nächste Schritte
- Neue Ansichten: Erweiterte Funktionen wie Watch List, Memory View, Disassembly View und Stack Trace sind geplant
- Automatische Konfiguration: Ziel ist es, die Unterstützung automatischer Konfiguration auf mehr Sprachen und Build-Systeme auszuweiten
- Feinschliff und Ausbau: Feedback über Discord, GitHub usw. soll aufgenommen werden, mit klarer Bereitschaft zur aktiven Weiterentwicklung
Anhang
- Zed ist unter macOS und Linux verfügbar
- Das Unternehmen stellt Entwickler ein (bei Interesse siehe offizielle Website)
2 Kommentare
Gibt es hier jemanden, der Zed mit Java verwendet ...? Haha
Hacker-News-Kommentare
Ich freue mich sehr, dass am Debugger gearbeitet wird. Genau diese Funktion war der Hauptgrund, warum ich nicht vollständig zu Zed wechseln konnte. Allerdings ist es noch nicht ganz „so weit“. Schade finde ich das Fehlen eines Watch-Fensters, einer Stack-Trace-Ansicht und dass Daten-Breakpoints nicht erwähnt werden, weshalb ich das eher als Beta betrachte. Ich weiß zwar, dass diese Funktionen irgendwann kommen werden, aber das, was jetzt angeboten wird, reicht für 97 % meiner Debugging-Sessions noch nicht aus. Ich wünschte, die Unterstützung für mehrere gleichzeitige Debugging-Sessions und die Pläne für Multithread-Debugging wären in der Ankündigung klarer erwähnt worden. Mich interessieren besonders auch coole Ideen für Multithread-Debugging, wie bei RemedyBG einen bestimmten Thread zu „freezen“ oder nur einen einzelnen „solo“ laufen zu lassen
Hallo Laserbeam, ich habe den Debugger entwickelt und den Beitrag geschrieben. Eine grundlegende Stack-Trace-Ansicht wird bereits unterstützt. Bald wird eine Stack-Trace-Ansicht im Multi-Buffer-System eingeführt, und schon jetzt kann man während einer Debugging-Session mit der Aktion „show stack trace“ den Call-Stack in einem Multi-Buffer aufklappen und jeden Frame ansehen. Allerdings entspricht das noch nicht dem hohen Qualitätsstandard von Zed, deshalb haben wir damit noch nicht offensiv geworben. Der PR für Watch-Variablen/-Ausdrücke wird in den nächsten Tagen voraussichtlich gemergt. Die Funktion ist fertig, aber wir wollten kurz vor dem Release nichts einbauen, was noch nicht ausreichend getestet wurde. Daten-Breakpoints haben hohe Priorität, aber wir wollen uns zunächst eine Zeit lang auf die automatische Konfiguration konzentrieren, daher kann ich keinen genauen Zeitplan nennen. Mehrere Sessions und Multithread-Debugging werden ebenfalls bereits gleichzeitig unterstützt; es gibt noch Dinge zu verbessern, aber eine grundlegende Unterstützung ist vorhanden
Im Blogpost wird erwähnt, dass fortgeschrittene Ansichten in Entwicklung sind. Dieser erste Release und die Ankündigung konzentrieren sich darauf, das Fundament zu legen. Künftig sollen fortgeschrittene Ansichten wie Watch-Listen, Memory-View, Disassembly-View und Stack-Trace-View hinzukommen [passender Link]
Meine Debugging-Sessions bestehen immer nur aus normalen Breakpoints und Stepping. Für mich ist das daher völlig ausreichend
Sehe ich auch so, aber wenn man sich anschaut, mit welchem Tempo das Zed-Team entwickelt, habe ich das Gefühl, dass diese Funktionen bald nachkommen werden
Den Debugger habe ich noch nicht ausprobiert, aber bei mir ist es mit den Git-Funktionen ähnlich. Zed hat grundlegende Git-Features, aber es reicht noch nicht aus, um meinen bisherigen Workflow vollständig zu ersetzen. Ich hoffe, dass auch an Git weiter intensiv gearbeitet wird
Zed ist wirklich ein ziemlich guter Editor. Ich wechsle in letzter Zeit von Neovim zu Zed und bin sehr zufrieden. Alles ist extrem schnell, und die Vim-Bindings sind gut integriert. Der Agent-Modus ist ebenfalls praktisch. Im Vergleich zu VSCode fehlt zwar noch etwas im Erweiterungs-Ökosystem, aber viele der Dinge, die ich brauche, deckt es bereits gut ab. Der Debugger war bisher eine große Lücke, deshalb freue ich mich sehr, dass er jetzt dazugekommen ist
Ich frage mich, wie sehr sich die Vim-Bindings wirklich nach echtem Vim anfühlen. Die meisten Vim-Emulatoren sind zwar ähnlich genug, aber gerade dadurch oft so uneindeutig, dass man sich ständig vertippt, was noch frustrierender ist. Ich habe die Erfahrung gemacht, dass ein Editor, der sich überhaupt nicht wie Vim anfühlt, weniger nervt, als wenn die Finger ständig „falsch“ liegen
Mich würde interessieren, wie die Rust-Codevervollständigung in Zed ist. So eine magische Umgebung wie in Windsurf oder Cursor, wo mit „tab-tab-tab“ alles ganz natürlich autovervollständigt wird, wäre großartig. Gerade bei TypeScript oder Skriptsprachen funktioniert diese Art der Vervollständigung so gut, dass sie fast schon Refactoring automatisiert. IntelliJ/RustRover kam selbst mit JetBrains-Modellen oder Co-pilot nicht an das Niveau von Cursor oder Windsurf heran. Ich denke, das liegt an Rust selbst. 1) Ist so eine natürliche Autovervollständigung inzwischen auch in Rust möglich, und klappt das in Zed? 2) Wie fühlt sich Zed im Vergleich zu Cursor und Windsurf an, und wie im Vergleich zu RustRover bzw. dazu, wie JetBrains mit dem Rust-AST umgeht?
Zed wirkt wie die Verwirklichung dessen, was Lapce, Helix und Neovim bislang nicht geschafft haben. Als ich ungefähr 2021–2022 Helix benutzt habe, habe ich es wegen Bugs und mangelnder Integration schließlich aufgegeben; besonders die PHP-Unterstützung aus meiner früheren Firma war fast nicht vorhanden. Mit Neovim kam ich am besten zurecht, aber viele bekannte Community-Plugins hatten einen sehr dogmatischen Stil, und alternative Plugins waren zu langsam. Es war anstrengend, zu viele Optionen abwägen zu müssen, nur um eine halbwegs stabile Umgebung zu bekommen. Lapce wirkte auf mich einfach wie ein „VSCode-Klon“, und ich hatte nicht das Gefühl, dass etwas daran besonders war. Ich finde immer noch nicht, dass es als Daily Driver taugt. In diesem Sinne ist Zed in kurzer Zeit mein Lieblingseditor geworden, und ich bin dafür in letzter Zeit jeden Tag dankbar. Über den hinzugekommenen Debugger freue ich mich ebenfalls sehr
Die Erklärung „aus meiner früheren Firma“ bei der PHP-Unterstützung ist eigentlich unnötig
Es ist auch ein interessanter Blickwinkel, das als „VSCode-Klon“ zu bewerten. Eine unterhaltsame Deutung des beliebtesten Editors der Menschheitsgeschichte
Ich bin beeindruckt davon, wie Zed sich immer mehr zu einer ausgereiften, leichtgewichtigen IDE mit vielen Funktionen entwickelt. Meiner Meinung nach sind DAP und LSP die besten Innovationen, die Programmiertools in den letzten zehn Jahren erlebt haben
Anfangs war ich an Zed interessiert, aber als „AI“ integriert wurde, verlor ich das Interesse. Es ist einfach zu viel „AI“, und ich bin inzwischen müde davon. Ich werde wohl weiter Neovim benutzen, bis etwas Besseres kommt, und ich denke, solche Veränderungen werden erst nach dem Platzen der „AI-Blase“ eintreten
Zed ist der erste Editor, bei dem ich überhaupt Lust hatte, AI-Funktionen auszuprobieren. Insgesamt hat er für mich ein sehr solides Fundament, und AI fühlt sich dort eher wie gewöhnliche Autovervollständigung in anderen Editoren an. Es wirkt nach dem Motto: „Du willst keinen AI-Editor, du willst einen guten, schnellen Editor — den haben wir gebaut, und wir haben auch AI-Funktionen hinzugefügt.“ Bei den Konkurrenten fühlt es sich eher an wie: „AI ist das Hauptprodukt, und der Editor ist nur Beilage.“ Bei Zed liegt der Schwerpunkt anders
Als ich nach Neovim geschaut habe, war ich überrascht, dass es sogar von zwei AI-Produkten gesponsert wird. Das ist zwar nicht dasselbe wie direkte AI-Integration, aber es wird zunehmend schwierig, dem ganz auszuweichen
Ich schalte einfach alle AI-bezogenen Optionen aus und benutze es so. Es ist ein ziemlich guter Editor. Für Merge-Konflikte muss ich zwar immer noch zu VSCode wechseln, aber insgesamt bin ich zufrieden
Mich würde interessieren, wie aufdringlich die AI-Funktionen von Zed in der Praxis sind und ob man sie in den Einstellungen deaktivieren kann
Beim normalen Arbeiten mit Zed stören die AI-Funktionen überhaupt nicht. Gelegentlich sind sie nützlich, aber ich verwende sie nicht oft
Seit die Linux-Unterstützung da ist, schaue ich jedes Mal nach, ob inzwischen auch normale Displays (LoDPI) unterstützt werden. Leider ist das immer noch nicht der Fall
Das ist wirklich frustrierend. Text-Rendering ist die Grundlage eines Code-Editors, aber beim Zed-Team scheint es niemanden zu geben, der normale (non-retina) Bildschirme verwendet. Passender GitHub-Issue-Link
Das ist zwar nur ein Workaround, aber wenn man BetterDisplay (kostenloses Tool) installiert und den LoDPI-Bildschirm auf HiDPI umstellt, wird das Text-Rendering brauchbar
Ich benutze es täglich auf einem 1920x1200-Laptopbildschirm unter Linux und habe überhaupt keine Probleme
Es gibt keine Windows-Unterstützung, und wenn normale Bildschirme auch unter Linux nicht unterstützt werden, fragt man sich schon, ob das nicht faktisch ein Mac-zentriertes Unternehmen ist
Ich würde bei meinem aktuellen Python-Projekt mit Pyright gern von Cursor zu Zed wechseln, aber der Akkuverbrauch ist so hoch, dass ich das nicht rechtfertigen kann. Das Issue existiert bereits auf GitHub, und ich finde es sehr schade, dass das Team ihm keine höhere Priorität gibt
Für mich ist Zed ein echtes Beispiel für richtige Produktentwicklung. Es ist nicht einfach nur noch eine neu verpackte Chrome-Engine, und genau deshalb ist es eine so erfreuliche Alternative
Ehrlich gesagt war ich überrascht, dass es auch langsame Stellen gibt. Beim Wechseln von Dateien in der Tab-Liste gibt es Verzögerungen, und auch die Reaktion beim Tippen ist langsamer als in Emacs (mit aktiviertem
lsp-mode) oder sogar im Webbrowser. Außerdem verbraucht es rund 60 MiB mehr Speicher als Emacs. Dafür startet es wirklich schnell. Für einen Editor mit dem schlichten Slogan „schneller Editor“ ist es überraschend, dass er sogar langsamer ist als Emacs Lisp + C-Kern. Als ich mir die Plugin-Architektur angesehen habe, wirkte es so, als würden Plugins zu WASM kompiliert und in einer VM laufen. Ich frage mich, ob das die Ursache istIch frage mich, wie Zed langsamer als Emacs sein kann. Meiner Erfahrung nach ist Zed fast ohne jede Latenz schnell. Bearbeitung, LSP und Dateiwechsel reagieren sofort. Emacs habe ich dagegen oft gerade wegen Latenzproblemen wieder aufgegeben, besonders in Remote-Entwicklungsumgebungen
Zur Frage, ob Plugins wegen WASM in einer VM laufen und deshalb langsam sind: Die Plugins, die ich gesehen habe, starten meist nur Server und stehen nicht in direktem Zusammenhang mit der Reaktion beim Tippen. Ich würde eher auf die GPU als Ursache tippen. Bei GPU-Compositing entstehen leicht Verzögerungen, und das kann sich mit dem Rendering auf OS-Ebene überschneiden. Ich erinnere mich auch daran, dass Emacs Tricks verwendet hat, um die Event-Loop zu umgehen und die UI direkt zu aktualisieren, was Kompatibilitätsprobleme verursachte
Für Emacs gibt es das Paket
dape, einen gut entworfenen DAP-basierten Debugger. Passender Link Es ist ohne Abhängigkeiten konzipiert und könnte künftig vielleicht sogar in das Standard-Emacs aufgenommen werdenEs könnte auch ein Problem in der Rendering-Pipeline sein. Welches Betriebssystem verwendest du?
Was ich mir vom Zed-Team wünsche, ist eine ordentliche Sprachenerkennung für C und C++. Praktisch jeder Editor macht denselben Fehler und behandelt C wie C++ (C ist nicht C++, und man sollte das nicht verwechseln). Selbst wenn man in
compile_commands.jsonden C-Standard angibt, kommt es oft vor, dass Code mit C++-Syntaxfehlern trotzdem als C++ erkannt wird. Wenn allein die Sprachenerkennung korrekt wäre, wäre es ein sehr guter Editor