- 2,000人以上の開発者が要望していたデバッグ機能が、ついにZedに実装された
- デバッガは速度、親しみやすさ、設定の柔軟性を中心に設計されている
- Rust、C/C++、JavaScript、Go、Pythonなどの主要言語と、Debug Adapter Protocol (DAP) ベースの拡張をサポート
- 直感的なLOCATORSシステムにより、追加設定なしでほとんどのプロジェクトを簡単にデバッグできる
- UIとデータレイヤーを分離したアーキテクチャにより、共同デバッグと拡張性に優れた基盤が整えられている
Zedデバッガのリリース
- 2,000人以上の開発者からの要望を受け、Zedエディタに公式のデバッグ機能が導入された。これはZed 1.0に向けた非常に重要な前進
主な目標
- 速度: すばやい環境切り替えと効率的なデバッグ体験を提供
- 親しみやすさ: Zedのデザイン言語と調和し、一般的なデバッガの流れで期待される機能をすべてサポート
- 設定の柔軟性: UI、キーバインド、デバッグ設定などをユーザーが自由にカスタマイズ可能
言語と拡張サポート
- Rust、C/C++、JavaScript、Go、Pythonなどの主要言語を標準でサポート
- Debug Adapter Protocol (DAP) を実装したすべてのデバッグアダプタと連携可能
- 拡張システムにより、より多様な言語やデバッグ機能を簡単に追加できる
簡単なデバッグ設定
- LOCATORSという新しいシステムを導入し、ビルド設定をデバッグ設定に変換する
- 一度
tasks.jsonでビルドタスクを作成したら、debug.jsonで参照するか、Zedの自動設定機能を利用できる
- Zedが内蔵の実行可能ファイル、またはLanguage Serverの実行可能ファイルから自動的にlocatorsを実行する
- 多くの場合、追加のデバッグ設定なしですぐに利用できる
- 現在はCargo、Python、JavaScript、Go向けのlocatorサポートを提供中（さらに多くの言語を予定）
デバッグセッションの機能
- Zed内でスレッド、変数、ブレークポイント、コールスタックなどのプログラム状態を簡単に確認できる
- デバッガパネルは完全にカスタマイズ可能で、タブのドラッグ・並べ替えや、パネルの自由な移動ができる
- キーボード中心のデバッグにも対応しており、マウスなしでコード移動、ブレークポイントの切り替え、セッション移動が可能
拡張性の高いアーキテクチャ
- さまざまな言語のデバッグ、共同作業環境、拡張サポート、効率的なデータキャッシュと管理を可能にするため、2層アーキテクチャを設計
- データレイヤー: デバッグアダプタと直接通信し、セッション状態の維持、応答のキャッシュ、古いデータの無効化管理を担当
- UIレイヤー: 必要なデータだけを要求し、インターフェースのレンダリングに注力
- この分離により、共同作業（マルチプレイヤー）デバッグ機能の実装が容易になり、ネットワーク帯域の節約効果も高い
拡張APIとDAPの適用
- 70種類を超える多様なDAP実装が存在するため、すべてを標準サポートする代わりに、Zedの拡張APIを拡張してデバッガ統合を可能にしている
- スキーマの直接定義、アダプタのダウンロードと実行ロジックの実装、デバッグ設定のデフォルト値の注入、locatorとの自動連携などによりDAPサポートを拡張できる
- LSP（言語サーバープロトコル）の拡張方式と同様に、開発者は自分専用のデバッグアダプタをZedへ簡単に統合できる
インライン変数値のサポート
- インライン変数値表示機能はDAPではなくLSPに属するため、DAPとLSPの両方が連携している場合にのみ、従来方式で提供できる
- 正規表現などの単純なマッチングは、スコープやコメントなどの問題で精度が低い
- Tree-sitterを活用し、実行中コードのスコープ内にある変数の識別を高精度で行う
- LSP連携がなくても、
.scmファイルを通じて言語ごとのサポートが可能
- リリース時点ではPython、Rust、Goをサポートし、今後さらに多くの言語を追加予定
- ZedはTree-sitterの創始者たちが作ったエディタ
今後の計画
- 新しいビュー: ウォッチリスト、メモリビュー、逆アセンブリビュー、スタックトレースなどの高度な機能を追加予定
- 自動設定: より多くの言語とビルドシステムに対する自動設定サポートの拡大を目指す
- ブラッシュアップと拡張: DiscordやGitHubなどを通じてフィードバックを受け取り、積極的に改善していく方針
付録
- ZedはmacOS、Linuxで利用できる
- 開発者を募集中（興味があれば公式サイトを参照）
2件のコメント
JavaでZedを使っている方っているんでしょうか…？（笑）
Hacker News の意見
デバッガーの開発が進んでいるのを見て、本当にうれしく思う。これはまさに、私が完全に zed へ移行できない主な理由だった機能だ。ただし、「ついに来た」と言うにはまだ足りない部分がある。ウォッチウィンドウ、スタックトレースビューの不在、そしてデータブレークポイントへの言及がない点が惜しく、そのためベータ段階だと見ている。いずれこれらの機能が追加されることは分かっているが、現時点で提供されているものでは私のデバッグセッションの 97% をこなすには十分ではない。同時に複数のデバッグセッションを扱うサポートや、マルチスレッドデバッグの計画についても、発表でもっと明確に触れてほしかった。特に RemedyBG のように特定のスレッドを「freeze」したり、1 つだけを「solo」で動かしたりといった、マルチスレッドデバッグのクールなアイデアも気になる
Laserbeam さんこんにちは。私はデバッガーを開発し、その記事を書いた開発者です。基本的なスタックトレースビューはすでにサポートしています。まもなくマルチバッファシステム内でのスタックトレースビューが導入される予定で、現在でもデバッグセッション中に “show stack trace” アクションでマルチバッファにコールスタックを展開し、各フレームを見ることができます。ただ、Zed の基準でいう高い品質にはまだ達していないため、積極的には打ち出していません。ウォッチ変数／式機能の PR も数日以内にマージされる予定です。機能自体は完成していますが、リリース直前に十分テストされていない機能を入れるのは慎重になりました。データブレークポイントは重要な優先事項ですが、しばらくは自動設定の方に集中する予定なので、正確な時期は案内しづらいです。複数セッションとマルチスレッドデバッグも同時にサポートしており、改善の余地はあるものの基本的な対応はできています
ブログ記事では高度なビューが開発中だと言及されています。今回の初回リリースと発表は、基盤を固めることに重点が置かれています。今後、ウォッチリスト、メモリビュー、逆アセンブリビュー、スタックトレースビューのような高度なビューが追加される予定です [関連リンク]
私のデバッグセッションはいつも通常のブレークポイントとステッピングだけで進む。だから私にとっては十分なレベルだ
私も同意するが、Zed チームの開発速度を見ると、こうした機能はすぐ追いついてきそうな気がする
デバッガーはまだ使っていないが、私の場合は Git 機能に似た気持ちを感じる。Zed には基本的な Git 機能はあるが、これまでの自分のワークフロー全体を置き換えるにはまだ足りない。Git 側の開発にも引き続き力を入れてほしい
Zed は本当に良いエディタだ。最近 neovim から zed に移行しつつあるが、満足度は高い。あらゆる動作が非常に速く、vim バインディングもうまく統合されている。エージェントモードも便利だ。VSCode と比べると拡張エコシステムはまだ弱いが、自分に必要な作業の多くは十分カバーできている。デバッガーはこれまで大きな欠落だったので、追加されて本当にうれしい
vim バインディングがどれくらい本物の vim っぽいのか気になる。たいていの vim エミュレーターはそこそこ似ているが、逆に中途半端すぎてキー入力をよく間違え、その方がいら立つことが多い。いっそ vim 感がまったくないエディタの方が、指がずっと「外れる」ことに対する苛立ちは少ないという経験がある
Rust コードの自動補完は Zed でどうなのか気になる。Windsurf や Cursor のように “tab-tab-tab” ですべてが自然に補完される魔法のような環境があるなら本当にうれしい。特に TypeScript やスクリプト言語では、この方式の補完はほとんどリファクタリング自動化と言っていいほどよく動く。IntelliJ/RustRover は JetBrains モデルや Co-pilot を使っても、Cursor や Windsurf のレベルには届かなかった。Rust 自体の特性によるものだと思う。1) Rust でもそのような自然な補完が可能になったのか、そして Zed でできるのか気になる。2) Zed と Cursor、Windsurf を比べたとき、また RustRover や JetBrains の Rust AST の扱い方と比べたとき、どんな感じなのか知りたい
Zed は Lapce、Helix、Neovim がこれまで実現できなかったことを実現している感じがする。2021〜2022 年ごろに Helix を使っていたときは、バグや統合不足のせいで結局あきらめたし、特に以前の会社で使っていた PHP のサポートがほとんどなかった。Neovim がいちばん快適ではあったが、有名なコミュニティプラグインには尖ったスタイルのものが多く、代替プラグインは遅すぎた。安定した環境を整えるために、あまりにも多くの選択肢を検討しなければならず大変だった。Lapce はただの「VSCode のコピー」のように見えて、何が特別なのか分からなかった。今でもデイリードライバーにするには至っていないと思う。そういう点で Zed は短期間で最高のエディタになり、最近は毎日ありがたく感じている。デバッガー追加も本当にうれしい
PHP サポートに「以前の会社だったので」という説明は特に要らない
「VSCode のコピー」と評価するのも興味深い見方だ。人類史上もっとも人気のあるエディタに対する面白い解釈だ
Zed がますます完成度の高い、軽量で多機能な IDE に進化していく様子には感心している。私にとって DAP と LSP は、この 10 年のプログラミングツールに起きた最高の革新だ
最初は Zed に興味があったが、「AI」が統合され始めてから興味を失った立場だ。「AI」が多すぎてうんざりしている。もっとましなものが出るまでは Neovim を使い続けるつもりで、こうした変化は「AI バブル」がはじけた後にしか来ない気がする
Zed は、私が初めて AI 機能を使ってみたいと思わせたエディタだ。全体として基本がしっかりしていると感じたし、AI っぽさも他のエディタにおける自動補完程度にとどまっている。「あなたが欲しいのは AI ではなく、良くて速いエディタだ。私たちはそれを作り、AI 機能も入れた」という姿勢が感じられる。競合は「私たちは AI がメインで、エディタはおまけ」という印象だが、Zed は重心が違う
neovim を調べたら 2 つの AI 製品から支援まで受けていて驚いた。直接 AI を統合しているわけではないが、もう完全に避けるのもだんだん難しくなっている
私はただ AI 関連のオプションをすべてオフにして使っている。かなり良いエディタだ。マージコンフリクトの解決だけはいまだに VSCode を開かなければならないが、満足している
Zed の AI 機能が実際どれくらい intrusive なのか、設定で無効化できるのか気になる
普段 Zed を使っていて AI 機能が気になることはまったくない。たまに便利に使うことはあるが、頻繁には使っていない
Linux サポートが出てから毎回、通常のディスプレイ（LoDPI）対応が入ったか確認している。いまだに未対応なのが残念だ
本当にいら立たしい状況だ。テキストレンダリングはコードエディタの基本なのに、Zed チームには通常の（non-retina）スクリーンを使う人がいないように思える。関連 GitHub issue リンク
その場しのぎではあるが、BetterDisplay（無料ツール）を入れて LoDPI 画面を HiDPI に切り替えると、テキストレンダリングはまともになる
Linux の 1920x1200 のノートPC画面で毎日使っているが、まったくおかしくない
Windows サポートもなく、Linux でも通常スクリーン非対応なら、実質的に Mac 中心の会社なのではないかと思ってしまう
今 Python プロジェクトで Pyright を使う際、Cursor の代わりに Zed へ移りたいのだが、バッテリー消費が高すぎて正当化できないレベルだ。この問題はすでに GitHub に上がっているのに、チームが優先度を上げていないのが非常に残念だ
Zed は本物の製品開発の例だと思う。また別の Chromium ベースの再包装ではないので、本当にうれしい選択肢だ
正直、遅い部分があって驚いた。タブ一覧からファイルを切り替えるときに遅延があり、タイピングの反応も Emacs（lsp-mode 有効）や Web ブラウザより遅い。メモリも Emacs より 60MiB ほど多く使う。その代わり起動速度は本当に速い。単なる「速いエディタ」というスローガンとは裏腹に、Emacs Lisp + C コアよりも遅い状況だ。プラグイン構造を見ると WASM にコンパイルされて VM 上で動く形式のようだが、それが原因なのだろうか
どうして emacs より zed の方が遅くなったのか気になる。私の経験では zed はほとんど遅延がないほど速い。編集、lsp、ファイル切り替えのすべてが即応だ。むしろ emacs は遅延の問題で結局あきらめたことが多い（特にリモート開発環境で）
プラグインが WASM で VM 上を走るから遅いのではないかという質問については、私が見たプラグインはサーバー起動のようなことしかしないので、タイピング反応とは直接関係ない。むしろ GPU 使用が原因かもしれない。GPU コンポジットでは遅延が生じやすく、すでに OS 側のレンダリングとも重なりうる。emacs もイベントループを飛ばして UI を直接更新するトリックを使い、互換性問題が生じた記憶がある
emacs には dape パッケージという、よく設計された DAP ベースのデバッガーがある。関連リンク 依存関係なしで設計されており、将来的には標準の emacs に含まれる可能性がある
レンダリングパイプラインの問題かもしれない。使っている OS が気になる
zed チームにお願いしたいのは、きちんとした C と C++ の言語判定をしてほしいという点だ。すべてのエディタが C を C++ のように扱うという同じ間違いを繰り返している（C は C++ とは違い、混同すべきではない）。compile_commands.json で C 標準を指定していても、C++ 構文エラーになるコードなのに C++ として認識されることが多い。言語判定さえまともなら非常に良いエディタだ