Zed est désormais disponible sur Windows

 (zed.dev)
5 points par GN⁺ 2025-10-16 | 1 commentaires | Partager sur WhatsApp
  • L’éditeur de code Zed est désormais officiellement disponible sur Windows
  • Le rendu s’appuie sur DirectX 11, avec DirectWrite pour le rendu du texte, afin d’offrir une expérience visuelle propre à Windows
  • Intégration directe avec Windows Subsystem for Linux (WSL) et prise en charge des connexions distantes via SSH pour renforcer les environnements de développement à distance
    • Depuis un terminal WSL, la commande zed permet d’ouvrir directement un dossier
    • Depuis Zed, il est aussi possible d’ajouter la distribution WSL souhaitée via File > Open Remote ou en sélectionnant project: open remote dans la palette de commandes
    • Une option Connect New Server est proposée pour se connecter à un serveur Linux distant
    • En environnement WSL ou SSH, les opérations d’E/S de fichiers passent par le processus serveur distant léger de Zed (wsl.exe/ssh.exe)
    • Les principales fonctionnalités, comme l’édition de fichiers, l’intégration git, le terminal, les tâches, les language servers et le débogueur, fonctionnent toutes aussi dans les environnements distants
  • Extensions et intégration WebAssembly
    • Les extensions pour Windows peuvent être utilisées immédiatement, sans configuration supplémentaire
    • Lors du développement de nouvelles extensions, aucun traitement spécifique à Windows n’est nécessaire
    • Les extensions Zed reposent sur les WebAssembly Components et peuvent accéder au système de fichiers dans un bac à sable via l’interface WASI
    • Zed gère automatiquement la conversion des chemins de fichiers, ce qui permet de développer sans se soucier des différences entre les chemins Windows et Unix
  • Fonctionnalités IA et autres nouveautés
    • Toutes les fonctionnalités IA de Zed, dont les prédictions d’édition basées sur l’IA et les agents du moteur ACP (Agent Client Protocol), sont entièrement prises en charge sur Windows ainsi que dans les environnements distants (WSL/SSH)
    • Utilisation directe de Claude Code via ACP
    • Essai gratuit de 14 jours de Zed Pro ou utilisation possible avec une clé API personnelle
  • Comme sur Mac et Linux, la version Windows bénéficie elle aussi de mises à jour hebdomadaires. Plusieurs ingénieurs de Zed utilisent Windows comme environnement de développement principal, et une équipe dédiée à Windows est maintenue en permanence

À lire aussi

1 commentaires

 
GN⁺ 2025-10-16
Avis Hacker News
  • Je voudrais signaler que les raccourcis clavier de base de Windows ne fonctionnent pas. Par exemple, ALT+F n’ouvre pas le menu Fichier, et ALT+SPACEBAR n’affiche pas non plus le menu contextuel système (agrandir, réduire, fermer, etc.). Avec le backend de rendu DirectX, l’application semble se comporter davantage comme un jeu vidéo que comme un processus Win32 natif. Il est aussi surprenant de voir qu’après installation, le dossier dépasse 400 Mo. Quand on pense que VSCode tourne autour de 380 Mo, je veux bien croire que ce ne soit pas une app Electron, mais je me demande bien ce qu’ils ont mis là-dedans. Je pensais qu’une app Rust était censée être légère, mais la taille installée donne presque l’impression d’un gonflement binaire/dépendances au niveau de Java
    • Un binaire Hello World en Rust est plus gros que Git. C’est plus petit que Java ou Electron, certes, mais on ne peut pas vraiment dire que ce soit petit
    • PSPad fait 40 Mo et reste un vieux logiciel toujours maintenu. Notepad++ fait 17 Mo. Qu’un projet Rust moderne, compilé, de très haut niveau prenne 400 Mo, ça me paraît absurde
    • Une installation de plus de 400 Mo risque d’en rebuter beaucoup. Il faut expliquer rapidement pourquoi cette taille est nécessaire
    • Même si ce n’est pas Electron, on a l’impression qu’il embarque d’office la moitié d’Electron, à savoir Node.js. La plupart des LSP sont basés sur .js, et les extensions sont en WASM. VSCode met les extensions dans un répertoire de configuration séparé, alors que Zed les met toutes dans le répertoire d’installation
    • À noter qu’il est tout à fait possible d’avoir simultanément un contexte graphique et une barre de menus Win32 dans une même fenêtre
  • Je me demande si Zed a implémenté le rendu de police subpixel. Je me souviens d’un ancien moteur de rendu d’interface conçu pour les écrans HiDPI des Mac, ce qui faisait souffrir les utilisateurs Linux (et Windows) sur écrans LoDPI avec des polices floues
    • Je ne sais pas pour le rendu subpixel, mais le rendu des polices sous Linux s’est nettement amélioré après un patch récent lien connexe
    • Ça m’intéresse aussi. Il me semble que Zed utilise CoreText sur Mac et DirectWrite sur Windows. CoreText ne gère-t-il pas déjà tout ça ?
    • La build Windows utilise DirectX 11 pour le rendu et DirectWrite pour le texte, ce qui lui donne un vrai feeling Windows. Le rendu de polices DirectWrite utilise le rendu subpixel de Windows. Sur mon écran, ça m’a paru correct (mieux que Linux). On dirait qu’ils ont bien anticipé ce point à la conception
    • J’utilise un moniteur externe 1440p sur macOS, et les polices étaient vraiment atroces. Ça passe sur l’écran Retina du laptop, mais sur le moniteur externe c’était tellement flou que ça me donnait mal à la tête
    • J’ai aussi testé sur un écran 1440p avec différentes polices, et c’est moyen. Mais je pense que le problème ne vient pas de Zed : le rendu de polices de Windows n’est pas terrible à la base. VSCode est pareil. Si on veut un rendu vraiment de qualité, j’ai l’impression qu’il faut au moins un écran 4K
  • J’ai utilisé Zed comme éditeur principal pendant plusieurs mois, puis je suis récemment revenu à VSCode. Il y a deux raisons : l’une est de ma faute, et pour l’autre je ne sais pas exactement où se situe le problème. 1. En codant tard dans la nuit, j’ai renommé un fichier avant de le commit, puis j’ai supprimé par erreur la nouvelle version, ce qui m’a fait perdre plusieurs heures de travail. Dans le menu contextuel de Zed, Delete et Trash sont juste l’un à côté de l’autre, et Delete supprime immédiatement sans passer par la corbeille. Ctrl+Z n’est pas encore implémenté non plus, donc sans sauvegarde, impossible de récupérer quoi que ce soit (et ce n’était pas encore dans le contrôle de version). 2. Dans un workspace Rust, les erreurs et avertissements d’une crate particulière n’apparaissaient pas du tout dans l’éditeur. J’ai essayé de modifier divers réglages sans succès, puis j’ai lancé VSCode, et ça a fonctionné sans configuration particulière
    • Ça me rappelle l’époque du Touch Bar sur macOS. Dans le menu de gestion des commits, Cancel était juste à côté de Force Push
    • L’absence de Ctrl+Z dans Zed est un manque tellement important que c’en est difficile à croire
    • Je me demande comment on est censé utiliser un éditeur à qui il manque ce genre de fonctions de base. Je me demande quels sont ses avantages
  • Zed a vraiment une allure incroyable, et en pratique le feeling est exceptionnel. Je l’ai essayé un peu sous Linux, et il est difficile d’expliquer cette sensation si on ne l’a pas vécue soi-même. Il est facile de sous-estimer ce qu’un éditeur accéléré par GPU a de différent, mais dès qu’on l’essaie, on tombe forcément sous le charme. La seule raison pour laquelle je ne peux pas migrer totalement vers Zed, c’est l’absence actuelle de prise en charge de DevContainer. J’ai énormément investi dans la configuration de mes devcontainers, donc abandonner ça pour réinstaller en local tous mes outils, bibliothèques et réglages me semblerait être un énorme retour en arrière. Beaucoup de gens attendent cette fonctionnalité, donc j’espère qu’elle arrivera un jour issue connexe
    • Je serais curieux d’en savoir plus sur tes DevContainer personnalisés
    • J’aimerais comprendre en quoi DevContainer aide. Je documenterais bien mon environnement en détail, mais je me demande quels avantages il apporte au-delà de ça
    • Compatible avec devpods
  • Le fait que l’éditeur utilise moins de mémoire et de CPU que l’onglet de navigateur de la web app sur laquelle je travaillais est vraiment rafraîchissant. J’en suis très satisfait jusqu’ici
    • il vaut mieux vérifier, car zed lance aussi node pour exécuter les lsp
    • Vu que le binaire fait autour de 0,5 Go, je n’ai pas spécialement l’impression que ce soit léger comme un navigateur
  • J’ai essayé d’utiliser Zed au quotidien, mais l’expérience TypeScript m’a déçu. L’éditeur lui-même est rapide, mais des actions LSP comme jump to declaration étaient bien plus lentes sur notre base de code que dans VSCode / Cursor
    • Je recommande de vérifier s’il prend en charge typescript-go comme LSP. Il a été ajouté récemment dans IDEA, je l’utilise depuis quelques mois, et c’est vraiment fantastique
    • Même expérience, même conclusion. Zed était rapide pour l’édition, mais les fonctions avancées étaient lentes, donc au final il me paraissait globalement plus lent que VSCode
    • Il me semble que les deux utilisent tsserver en interne, donc je ne comprends pas pourquoi c’est plus lent
    • Electron compile NodeJS avec la compression de pointeurs v8, ce qui peut réduire l’usage mémoire jusqu’à 50 % et améliorer les performances
  • C’est correct, mais je suis déjà passé à Linux, et Zed fonctionne très bien dans cet environnement
[Window Title]
Critical

[Main Instruction]
Unsupported GPU

[Content]
Zed uses DirectX for rendering and requires a compatible GPU.

Currently you are using a software emulated GPU (Microsoft Basic Render Driver) which
will result in awful performance.

For troubleshooting see: https://zed.dev/docs/windows
Set ZED_ALLOW_EMULATED_GPU=1 env var to permanently override.

[Skip] [Troubleshoot and Quit]

Malheureusement, j’ai eu ce problème

  • En réalité, ce n’est pas vraiment un problème de Zed mais de ton système. De nos jours, c’est rare de trouver un environnement où DirectX ne fonctionne pas ; tu fais tourner Windows dans une VM par hasard ?
  • Je me demande bien ce qu’un éditeur de texte peut faire en rendu logiciel pour arriver à des « performances atroces »
  • Zed est vraiment génial. Il fait tout ce que je veux. On trouve facilement ce dont on a besoin, et c’est vraiment rapide. En mode ACP, on peut même forker le terminal CLI depuis l’IDE. Ça permet d’utiliser à moindre coût des agents CLI très puissants et très intelligents comme Cerebras ou Qwen code 480b
  • J’attends depuis longtemps, et il n’y a toujours que des binaires x86_64. J’aime vraiment mon Surface Pro ARM, donc j’aimerais beaucoup que Zed fonctionne sur ce matériel. Si l’équipe Zed lit ce commentaire, j’espère qu’elle y réfléchira
    • Je compile moi-même les sources pour le faire tourner sur Windows aarch64. La compilation est assez lente sur un Surface Pro 16 Go, mais sinon ça fonctionne très bien. J’attends aussi un binaire officiel
    • Pour une raison que j’ignore, quand on compile zed avec msvc sur Windows, ça paraît extrêmement lent par rapport à Linux. Une issue connexe a même été ouverte à ce sujet