- La fonction de débogage, demandée par plus de 2 000 développeurs, est enfin intégrée à Zed
- Le débogueur a été conçu autour de la vitesse, de la familiarité et de la configurabilité
- Prise en charge des langages populaires comme Rust, C/C++, JavaScript, Go et Python, ainsi que des extensions basées sur le Debug Adapter Protocol (DAP)
- Grâce au système intuitif de LOCATORS, il est possible de déboguer facilement la plupart des projets sans configuration supplémentaire
- L’architecture séparant l’interface utilisateur et la couche de données offre une excellente base pour le débogage collaboratif et l’extensibilité
Lancement du débogueur de Zed
- À la demande de plus de 2 000 développeurs, une fonction officielle de débogage a été ajoutée à l’éditeur Zed. Il s’agit d’une avancée majeure sur la route vers Zed 1.0
Objectifs principaux
- Vitesse : offrir des changements de contexte rapides et une expérience de débogage efficace
- Familiarité : s’intégrer au langage de design de Zed tout en prenant en charge toutes les fonctions attendues d’un flux de débogage classique
- Configurabilité : permettre aux utilisateurs de personnaliser librement l’interface, les raccourcis clavier et les paramètres de débogage
Prise en charge des langages et des extensions
- Les principaux langages comme Rust, C/C++, JavaScript, Go et Python sont pris en charge nativement
- Compatible avec tous les adaptateurs de débogage qui implémentent le Debug Adapter Protocol (DAP)
- Le système d’extensions permet d’ajouter facilement davantage de langages et de fonctionnalités de débogage
Configuration simplifiée du débogage
- Un nouveau système appelé LOCATORS transforme les configurations de build en configurations de débogage
- Après avoir défini une tâche de build dans
tasks.json, il est possible de la référencer dans debug.json ou d’utiliser la configuration automatique de Zed
- Zed exécute automatiquement les locators à partir des exécutables intégrés ou fournis par le Language Server
- Dans la plupart des cas, aucune configuration de débogage séparée n’est nécessaire
- La prise en charge des locators est actuellement disponible pour Cargo, Python, JavaScript et Go, avec d’autres langages à venir
Fonctionnalités des sessions de débogage
- Dans Zed, il est facile d’inspecter l’état du programme, notamment les threads, variables, points d’arrêt et pile d’appels
- Le panneau du débogueur est entièrement personnalisable : il est possible de faire glisser et réorganiser les onglets, ou de déplacer librement les panneaux
- Le débogage orienté clavier est également pris en charge, permettant de naviguer dans le code, d’activer ou désactiver des points d’arrêt et de passer d’une session à l’autre sans souris
Une architecture hautement extensible
- Une architecture à deux couches a été conçue pour permettre le débogage de nombreux langages, les environnements collaboratifs, la prise en charge des extensions ainsi qu’une mise en cache et une gestion efficaces des données
- Couche de données : communique directement avec l’adaptateur de débogage, maintient l’état des sessions, met en cache les réponses et gère l’invalidation des données obsolètes
- Couche UI : demande uniquement les données nécessaires et se concentre sur le rendu de l’interface
- Cette séparation facilite l’implémentation du débogage collaboratif (multijoueur) et permet aussi d’économiser de la bande passante réseau
API d’extension et application du DAP
- Comme il existe plus de 70 implémentations différentes du DAP, plutôt que de tout prendre en charge nativement, Zed a étendu son API d’extension pour permettre l’intégration de débogueurs
- Il est possible d’étendre la prise en charge du DAP en définissant directement des schémas, en implémentant la logique de téléchargement et d’exécution des adaptateurs, en injectant des valeurs par défaut dans les configurations de débogage, ou encore via l’intégration automatique avec les locators
- À l’image du mode d’extension du LSP (Language Server Protocol), les développeurs peuvent intégrer facilement leurs propres adaptateurs de débogage dans Zed
Prise en charge des valeurs de variables inline
- L’affichage inline des valeurs de variables relève du LSP et non du DAP ; il ne peut donc être fourni de la manière classique que lorsque DAP et LSP sont tous deux liés
- Les correspondances simples, comme avec des expressions régulières, manquent de précision en raison de problèmes liés aux scopes ou aux commentaires
- Grâce à Tree-sitter, l’identification des variables dans le scope du code en cours d’exécution devient bien plus précise
- Une prise en charge par langage est possible via des fichiers
.scm, sans intégration LSP séparée
- Au lancement, Python, Rust et Go sont pris en charge, avec davantage de langages prévus par la suite
- Zed est l’éditeur créé par les inventeurs de Tree-sitter
Feuille de route
- Nouvelles vues : ajout prévu de fonctionnalités avancées comme une watch list, une vue mémoire, une vue de désassemblage et des stack traces
- Configuration automatique : objectif d’élargir la prise en charge automatique à davantage de langages et de systèmes de build
- Affinage et extension : l’équipe recueille des retours via Discord, GitHub et d’autres canaux, avec une volonté affirmée d’amélioration continue
Annexe
- Zed est disponible sur macOS et Linux
- L’entreprise recrute des développeurs (voir le site officiel pour plus d’informations)
2 commentaires
Y a-t-il des gens qui utilisent Zed avec Java...? haha
Avis sur Hacker News
Je suis vraiment ravi de voir qu’un travail est en cours sur le débogueur. C’est précisément la fonctionnalité principale qui m’empêchait de passer complètement à Zed. Cela dit, ce n’est pas encore tout à fait « là ». L’absence d’une fenêtre de surveillance, d’une vue de pile d’appels et de toute mention des points d’arrêt sur données me fait le considérer comme une bêta. Je sais que ces fonctionnalités finiront par arriver, mais dans l’état actuel, ce qui est proposé ne suffit pas pour couvrir 97 % de mes sessions de débogage. J’aurais aussi aimé que l’annonce mentionne plus clairement la prise en charge de plusieurs sessions de débogage simultanées et les plans pour le débogage multithread. Je suis notamment curieux de voir des idées intéressantes pour le débogage multithread, comme chez RemedyBG avec la possibilité de « geler » un thread donné ou d’en faire tourner un seul en mode « solo »
Bonjour Laserbeam, j’ai développé le débogueur et je suis l’auteur du billet. Une vue de pile d’appels basique est déjà prise en charge. Une vue de pile d’appels dans le système multibuffer arrivera bientôt, et même aujourd’hui, pendant une session de débogage, l’action « show stack trace » permet déjà de développer la pile d’appels dans un multibuffer pour voir chaque frame. Cela dit, cela n’atteint pas encore le niveau de qualité élevé que nous visons chez Zed, donc nous n’en avons pas vraiment fait la promotion publiquement. La PR pour les variables/expressions surveillées devrait aussi être fusionnée dans quelques jours. La fonctionnalité est terminée, mais nous hésitions à inclure juste avant la sortie quelque chose qui n’avait pas été suffisamment testé. Les points d’arrêt sur données sont une priorité importante, mais nous prévoyons de nous concentrer un moment sur la configuration automatique, donc difficile de donner un calendrier précis. Les sessions multiples et le débogage multithread sont également pris en charge en parallèle ; il reste des points à améliorer, mais le support de base est bien là
Le billet de blog mentionne qu’une vue avancée est en cours de développement. Cette première sortie et cette annonce se concentrent surtout sur la mise en place des bases. À l’avenir, des vues avancées comme la liste de surveillance, la vue mémoire, la vue désassemblage et la vue de pile d’appels seront ajoutées [lien connexe]
Mes sessions de débogage se limitent toujours à des points d’arrêt classiques et au pas à pas. Donc, pour moi, c’est déjà largement suffisant
Je suis d’accord aussi, et vu la vitesse à laquelle l’équipe Zed développe, j’ai l’impression que ces fonctionnalités vont suivre rapidement
Je n’ai pas encore essayé le débogueur, mais j’ai un ressenti similaire avec les fonctionnalités Git. Zed propose les bases pour Git, mais ce n’est pas encore suffisant pour remplacer l’ensemble de mon workflow actuel. J’espère qu’ils continueront aussi à se concentrer sur le développement côté Git
Zed est vraiment un très bon éditeur. Je suis récemment passé de neovim à zed et j’en suis très satisfait. Tout est extrêmement rapide et les raccourcis vim sont bien intégrés. Le mode agent est aussi pratique. L’écosystème d’extensions est encore moins riche que celui de VSCode, mais il couvre déjà largement beaucoup de choses dont j’ai besoin. Le débogueur était jusqu’ici un gros manque, donc je suis vraiment content de le voir arriver
Je me demande à quel point les raccourcis vim donnent vraiment la sensation de vim. La plupart des émulateurs vim sont assez proches, mais justement trop ambigus, donc on se trompe souvent dans les touches, ce qui est encore plus frustrant. J’ai déjà eu l’impression qu’un éditeur qui n’a pas du tout une sensation vim est en fait moins agaçant, parce que mes doigts n’ont pas constamment l’impression de « se tromper »
Je me demande ce que vaut l’autocomplétion Rust dans Zed. S’il existe un environnement presque magique où tout s’autocomplète naturellement à coups de « tab-tab-tab » comme dans Windsurf ou Cursor, ce serait formidable. Surtout en TypeScript ou dans les langages de script, ce type d’autocomplétion fonctionne presque comme de l’automatisation de refactoring. IntelliJ/RustRover, même avec les modèles JetBrains ou Co-pilot, n’ont pas atteint le niveau de Cursor ou Windsurf. Je pense que c’est lié à la nature même de Rust. 1) Je me demande si ce type d’autocomplétion fluide est désormais possible en Rust, et si Zed le permet. 2) Je me demande aussi à quoi cela ressemble dans Zed par rapport à Cursor et Windsurf, ainsi qu’à RustRover et à la manière dont JetBrains gère l’AST Rust
J’ai l’impression que Zed accomplit ce que Lapce, Helix et Neovim n’ont jamais réussi à faire. Quand j’utilisais Helix vers 2021~2022, j’ai fini par abandonner à cause des bugs et du manque d’intégration, et il n’y avait pratiquement aucun support pour PHP, que j’utilisais dans mon ancienne entreprise. Neovim était ce qui me convenait le mieux, mais parmi les plugins communautaires connus, beaucoup imposaient des choix très rigides, tandis que les alternatives étaient bien trop lentes. C’était épuisant de devoir réfléchir à trop d’options pour obtenir quelque chose de stable. Lapce me donnait simplement l’impression d’un « clone de VSCode », sans que je voie vraiment ce qu’il avait de spécial. Je n’ai toujours pas l’impression qu’il soit prêt pour un usage quotidien. Dans ce contexte, Zed est devenu en peu de temps le meilleur éditeur, et j’en suis reconnaissant chaque jour en ce moment. L’ajout du débogueur est aussi une excellente nouvelle
La précision sur le support PHP avec « dans mon ancienne entreprise » n’était pas vraiment nécessaire
C’est aussi intéressant de le qualifier de « clone de VSCode ». Une interprétation amusante de l’éditeur le plus populaire de l’histoire de l’humanité
Je suis impressionné de voir Zed évoluer progressivement vers un IDE léger, complet et riche en fonctionnalités. À mon avis, DAP et LSP sont les meilleures innovations arrivées dans les outils de programmation au cours des dix dernières années
Au départ, Zed m’intéressait, mais j’ai perdu cet intérêt quand l’intégration de l’« IA » a commencé. J’en ai assez de voir de l’« IA » partout. Je compte continuer à utiliser Neovim jusqu’à ce que quelque chose de mieux apparaisse, et j’ai l’impression que ce changement n’arrivera qu’après l’éclatement de la « bulle IA »
Zed est le premier éditeur qui m’a réellement donné envie d’essayer des fonctions IA. J’ai trouvé les fondamentaux globalement solides, et la présence de l’IA se limite à quelque chose du niveau de l’autocomplétion qu’on voit dans d’autres éditeurs. J’ai l’impression qu’ils disent : « ce que vous voulez, ce n’est pas de l’IA, mais un bon éditeur rapide ; nous l’avons construit, et nous avons aussi ajouté des fonctions IA ». Chez les concurrents, on a plutôt l’impression que « l’IA est le produit principal, l’éditeur n’est qu’un accompagnement » ; chez Zed, le centre de gravité est différent
En regardant neovim, j’ai été surpris de voir qu’il est même sponsorisé par deux produits d’IA. Ce n’est pas au niveau d’une intégration directe de l’IA, mais il devient de plus en plus difficile de l’éviter complètement
Moi, je désactive simplement toutes les options liées à l’IA. C’est un éditeur tout à fait correct. Je dois encore passer par VSCode pour résoudre les conflits de fusion, mais j’en suis satisfait
Je me demande à quel point les fonctionnalités IA de Zed sont réellement intrusives, et si elles peuvent être désactivées dans les réglages
Quand j’utilise Zed au quotidien, les fonctions IA ne me dérangent pas du tout. Il m’arrive de les trouver utiles, mais je ne les utilise pas souvent
Depuis l’arrivée du support Linux, je vérifie à chaque fois si le support des écrans standard (LoDPI) a été ajouté. C’est toujours dommage que ce ne soit pas encore le cas
C’est vraiment frustrant. Le rendu du texte est la base pour un éditeur de code, et on dirait que personne dans l’équipe Zed n’utilise d’écran standard (non-Retina). Lien vers l’issue GitHub connexe
C’est un bricolage temporaire, mais si vous installez BetterDisplay (outil gratuit) et passez l’écran LoDPI en HiDPI, le rendu du texte devient correct
Je l’utilise tous les jours sur un écran de portable Linux en 1920x1200 et je n’ai aucun problème
S’il n’y a pas de support Windows, et qu’en plus les écrans standard ne sont pas pris en charge sous Linux, on peut se demander si ce n’est pas, au fond, une entreprise centrée sur Mac
Je voudrais actuellement passer de Cursor à Zed sur un projet Python avec Pyright, mais la consommation de batterie est tellement élevée que je ne peux pas le justifier. Le problème existe déjà sur GitHub, et je trouve vraiment dommage que l’équipe ne lui donne pas une priorité plus élevée
Je pense que Zed est un vrai exemple de développement produit. C’est vraiment appréciable d’avoir une autre option qui ne soit pas simplement un énième reconditionnement du moteur de Chrome
Honnêtement, j’ai été surpris par certaines lenteurs. Il y a un délai quand je change de fichier depuis la liste des onglets, et la frappe est moins réactive que dans Emacs (avec lsp-mode activé) ou même dans un navigateur web. Il utilise aussi environ 60 MiB de mémoire de plus qu’Emacs. En revanche, le démarrage est vraiment très rapide. Contrairement au slogan de « l’éditeur rapide », j’obtiens en pratique quelque chose de plus lent qu’Emacs Lisp + un cœur en C. En regardant l’architecture des plugins, on dirait qu’ils sont compilés en WASM et tournent dans une VM. Je me demande si cela en est la cause
Je me demande comment Zed a pu devenir plus lent qu’emacs dans votre cas. D’après mon expérience, zed est si rapide qu’il semble presque sans latence. Édition, lsp, changement de fichiers, tout est instantané. À l’inverse, j’ai souvent fini par abandonner emacs à cause des problèmes de latence, surtout en environnement de développement distant
À propos de la question de savoir si les plugins sont lents parce qu’ils tournent en WASM dans une VM : les plugins que j’ai vus se contentent surtout de lancer des serveurs, donc cela n’a pas de lien direct avec la réactivité à la frappe. Je penserais plutôt au GPU. Avec la composition GPU, il est facile d’introduire de la latence, et cela peut aussi se superposer au rendu déjà géré par l’OS. Je me souviens aussi qu’emacs utilisait des astuces pour rafraîchir directement l’UI en contournant la boucle d’événements, ce qui avait entraîné des problèmes de compatibilité
emacs dispose d’un paquet appelé dape, un débogueur basé sur DAP bien conçu. Lien connexe Il est conçu sans dépendances et pourrait à terme être intégré à emacs de base
Cela peut aussi être un problème lié au pipeline de rendu. Je me demande quel système d’exploitation vous utilisez
Ce que j’aimerais demander à l’équipe Zed, c’est une véritable détection des langages C et C++. Tous les éditeurs répètent l’erreur de traiter le C comme du C++ (le C n’est pas du C++, et il ne faut pas les confondre) ; même quand on indique le standard C dans
compile_commands.json, il arrive souvent qu’un code contenant des erreurs de syntaxe C++ soit tout de même interprété comme du C++. Si seulement la détection de langage était correcte, ce serait un très bon éditeur