爆速AIコードエディター Zed

画面どれくらいの大きさ？27インチだと1440pでピクセル結構見えるけどな。150パーセント拡大した4k（実質1440p）の方が全然綺麗だよ。もしかして、もっと高解像度使ったことない？なら、何が良いのか知らないのかもね。

あのさ、1440pモニターだとテキストがボケボケなんだって好きなだけ言い張れば？でもさ、みんなが問題だって言ってるのは、テキストが”それ以上に”ボケてるってことなんだから。

Zedのウィンドウ、横と縦に1ピクセルずつ縮めてみて。そのissueページにリサイズでフォントのピントが合ったり外れたりする動画があって、それでわかったんだけど、ウィンドウの幅と高さを2で割って、そこでフォントレンダリングを開始してるっぽいんだ。2で割って0.5になるとボケて見えるんだよ。ウィンドウを1ピクセル広くすれば0.5にならずに整数になる。試してみて。これで困ってる人、結構解決すると思うよ。

俺はLinux（Ubuntu）使ってるけど、今まで入れた他のどのアプリでもこのボケたフォントの問題は起きたことないな。

俺もだよ… 1440pで32インチが一番良いかな。今もっと良くするなら1600p相当くらいかな。

最近4kディスプレイなんて数百ドルで買えるじゃん。全然金持ちってわけじゃないと思うけどね。

MacOSってさ、〜110dpiか〜220dpiくらいのモニターだと綺麗に見えるんだよね．それ以外のやつだとボケボケになっちゃうんだよな〜．

うん、それはね、Linuxが整数じゃないスケーリングに対応してるからだよ．Appleは頑固だからやらないんだ．

高DPIモニターでやっちゃいけないアンチエイリアシングに見えるね．

それってさ、”2010年代初頭”には全然そうじゃなかったし、5年前でさえディスプレイの他の部分でめっちゃ妥協しないとダメだったんだよ．

俺のMacOSのMBP 16”だと全然問題ないよ．多分デフォルトの解像度設定だと思うな．君の環境（プラットフォーム＋解像度）はどんな感じ？”

大胆な勘だけど、MacOSには昔（今も？）デフォルトでフォントを太字っぽく見せる機能があった気がするんだ．だから一部サイトで文字が細くて読めないことがあるんだけど、これも同じ問題かも？設定は”use font smoothing when available”って名前だったよ．

＞投票も多いし賛成してるコメントも多いのに、何も言われてないみたい
なんか必要な作業は元の方（アップストリーム）でやらなきゃいけないっぽいね．

MacOSならどんなモニターでもネイティブ解像度なら綺麗に見えるはずだよ．ネイティブ解像度の非整数倍率でピクセルフォント使うとどのOSでもひどくなるんだ．俺は色んなディスプレイでMacOS使ってるけど、Zedでベクターフォントなら全部OK．自分で作ったピクセルフォントはダメだったけどね．それはフォントのせいであってMacOSのせいじゃないんだ．

関係あるか分かんないんだけど、ZedをWindowsでソースからビルドして試してみたんだ（他のOSでは試してないよ）．そしたらね、残念ながら見た目が良くないんだ．なんか”くっきりしてない”っていうか、どう表現したらいいか分からないんだけど．

数ヶ月前までZed使ってたんだけど、AIパネル全体が編集できちゃうのがマジで嫌でさ、たまに内容消しちゃってたんだよね。それでCursorに乗り換えたんだけど、今度はそのエディターとアンドゥのスタックが”信用”できなくて、コード失くしたことがあるんだ。特にAIが編集したやつをレビュー中に、さらに自分で編集しようとしたときとか。アンドゥとかリドゥの追跡が難しすぎて。履歴がツリービューで見れたら良いのにって思う。チェックポイント復元とかリドゥが線形すぎて俺の原始的な脳にはキツイわ。ツリーベースのAI搭載IDEが欲しいって思うのは間違ってるかな？なんで誰も作らないんだろ？

＞AIパネル全体が編集できちゃうのがマジで嫌でさ、たまに内容消しちゃってたんだよね。＜
新しいエージェントパネルでそこは直ったらしいよ。他のAIサイドバーみたいな感じになったんだって。俺も（ちょっと）それで困ってたからな。新しいUIはまだ荒削りだけど、この変更は好きだよ。

面白いね。俺は逆にチャットインターフェースが編集可能な形式なのが結構好きなんだ。だって、ちょっとした修正はその場でできるし（わざわざモデルに話しかけ直す必要なく）、何回かやり取りしてゴチャゴチャになったチャットを整理できるからね（最初からやり直さなくて済む）。これのおかげでコンテキストウィンドウが小さくなって、モデル、特にローカルモデルには混乱しにくくなるんだ。それに、編集可能な形式の方が俺には理にかなってるし、LLMアシスタントとのやり取りが自然でシンプルに感じるんだよ。

そうそう！バッファ全体を編集できるのは超重要な機能だよ。だって、失敗した試みとかゴミが残ってると、モデルはバカになっていく（そしてコストも高くなる）からね。モデルのデータセットにちゃんと含まれてるマーケティング系のWebサイトみたいなものを作ってるならサクサク進むだろうけど、もっとニッチなものを作ってるなら、コンテキストを調整できるのがめちゃくちゃ重要になるんだ。場合によっては、これがAIアシスタンスを全然使えるかどうかの違いになるんだから（そうしないと失敗率が100%になっちゃう）。

＞俺は逆にチャットインターフェースが編集可能な形式なのが結構好きなんだ。だって、ちょっとした修正はその場でできるし＜
マジで同意。これがZed（とローカルで動かすLLM）のキラー機能だったんだよ。生成されたコードで最初に間違いを見つけたら、その後のトークン全部消す。んで、間違いを直してモデルを再実行する。これでコード生成が俺の経験ではめちゃくちゃ改善されたんだ。クラウドベースのLLMがアシスタントの出力を修正させてくれるのかは正直よくわかんないな（安全機構を簡単に回避できちゃうから、たぶん無理だと思うけど）。

唯一の問題として思いつくのは、プロンプトキャッシュが使えなくなることかな。これはAPI呼び出しのコストを上げちゃうかもしれない。でも、そもそもこういう文脈でプロンプトキャッシュが使われるのかはよく知らないんだ。それ以外だと、単に「履歴」をjsonファイルで送るだけだし、LLMチャットに別に難しいことなんてないんだよね。API使うなら、好きなものをオートコンプリートに送ればいいだけだよ。

＞クラウドベースのLLMがアシスタントの出力を修正させてくれるのかは正直よくわかんないな＜
基本的にはできるよ。リクエストごとに、これまでのアシスタントの出力も含めて完全なコンテキストをJSONで送るんだ。それは好きなように変更できるよ。

うん、でも今インラインアシストでテキストスレッドをコンテキストに使えないんだよね。だからコード適用する方法がないんだ。

ああそれは残念。スレッド自体はコンテキストに追加できるんだけど、そこでスラッシュコマンドが使えないんだよね。だからコンテキストに何か足すにはマウスでボタン押すしかなくて。せめてスラッシュコマンドが使えればよかったな。追記：あれ、テキストスレッドもちゃんと含まれるっぽい。

エージェントスレッドはコンテキストに足せるけど、テキストスレッドをコンテキストに足すのは今は動かないんだ。

あれ、俺の環境だとちゃんと動くみたいだよ。アクティブなテキストスレッドがあって、ファイル中のインラインプロンプトに自動で追加されたんだ。インラインテキストボックスの下に箱が出てた。最初はクリックが必要だったかもしれないけど、次からはデフォルトで含まれてるよ。

え、そんなんあったの？俺手動でコピペしてたよ、あれ面倒でミスりやすかったから新しいエージェントパネルの方が好きなんだ。あー失敗したかな。

うん、どこをいつ編集するか自分でコントロールできてよかったんだよね。コンテキストをちゃんと管理して、エディタで範囲を選んで”新しいコードを取り込む”みたいなのが理想だった。インラインアシストで毎回”新しいコード使って”って打ってたのバカみたいだね。”新しいコードを取り込む”ホットキーあったら最高だったのに。放置して30パーセント間違ってる巨大な差分見るの嫌なんだ。特に今、30分とか固まることあるからね。

私は逆の立場かな、新しいパネル大嫌い。スペース効率悪いし、スラッシュコマンドなくなったし、チャットどうやってクリアするのか分からないし。

VimとかEmacsにはundo-treeってのがあるよ（確かプラグインで）。結構な開発者が使ってる機能。Zedでこの機能欲しいならここで投票・情報見てみてね： https://github.com/zed-industries/zed/issues/17455 VSCodeのはここ： https://github.com/microsoft/vscode/issues/20889

cline使ってるんだけど、そこのスナップショットとか巻き戻しとかコンテキスト削除（順番バラバラでもできる）機能がマジで良い感じ。特にデカいプロジェクトとかLLM使うと変更が大きくなるときに輝くね。他のAIツールでイライラしてるならマジおすすめ。俺はこれでめっちゃ満足してるよ。gitみたいな履歴ツリーはないと思うけど、AIワークフローにはそんな必要ないかなって思う。だってリベースとかマージの競合解決をAIに任せるのは…今はヤバそうだもんね。

omg。”AIパネル全体が編集可能なエリア”は俺にとってマジで最高なキラー機能だよ！
完全にコントロールできるし、自分のvimキー使えるし、モデルも自由に切り替えられて人生最高。前回のアップデートで気に入らないのは、アシスタントのマルチタブが消えたこと。前は複数の会話をサクッと切り替えながら進められたのに、今は一つずつしかできないんだ :( assistant2はあんまり試してない、今のセットアップがすごく使いやすいからね。

心配しないで、俺が新しいIDE作ってるからさ。Zedみたいに惜しいけど、既存のIDEはまだ紙にコード書いてるみたいに line と column ベースなんだ。俺のは embedded tree structure がメインインターフェースで、入力中も安定した状態を保てるんだよ。これがプログラミングツールの未来だと思うね。

アンドゥ
リドゥの履歴を tree で表現するのと、コード構造を tree で表現するのは、全然違うことだろ。
質問と全然関係ないこと誰も気にしてないのがちょっとビックリだけど…
まあでも、この手のAIツールスレッドはいつもお互い話が噛み合ってなくて、でもすごい興奮してる人ばっかりだから、まあこれもアリか。

確かに全然違うものになり得るし、俺が知ってる今のシステムは全部無関係だけど、俺のシステムではそれは全く同じものなんだよ。
それが可能なのは、IDEの状態の source of truth が immutable concrete syntax tree だから。
btree amortization が組み込まれてるから、コストを悪化させずに immutable にできるんだ。
だから基本的には、古い tree のノードのほとんどを再利用して、変更を加えて新しい tree を常に構築できるんだよ。
バージョン履歴は、これらの tree reference のスタックになるだけさ。

これすごい興味ある！
馬車を改良しようとしてるだけで、そこから離れられるって気づいてないってとこ、マジで同意だよ。
あなたが作ってるもの、どうやったら追えるかな？
チャットとかできる？
GitHubは見つけたけど、もっと良い連絡方法あったら教えてね。

BABLR Discord が一番いい場所かな、もちろんメールでも大丈夫だよ！
https：
discord.gg
NfMNyYN6cX （あと、チャットも全然OKさ！）

一方、俺は Helix editor を半年ごとにチェックしてるよ。
作者たちが Copilot サポートを考え始めることに対して、どれだけ敵対的じゃなくなったかを見るためにね。
https：
github.com
helix-editor
helix
discussions
4037

なんでオープンソースのエディタが、特定の商用製品のAPIをコアでサポートしなきゃいけないんだ？
なんで Copilot だけで、他の製品はダメなんだ？
サードパーティのプラグインにするか、たくさんの製品をサポートする標準を待つのが、俺にはすごく合理的だと思うけどな。

Helix の discussion で誰かが言ってたみたいにさ、問題は Copilot とか特定の LLM じゃなくて、インライン提案を使えるようにする汎用インターフェースなんだよ。
LSP とか Extensions が使えるようにね。そしたら LLM を選ばなくて済むだろ？
まあ、Helix の maintainers が興味ないことに時間かけたくないってのも分かるけどね。

俺のコメントでも言ってる通り、彼らは気にしてるのかもしれないけど、ベストプラクティスがまだ定まってないうちに、ああだこうだと試行錯誤する時間がないだけかもしれないんだ。

特定の Copilot とかにロックされるって話じゃないんだ。
Helix の開発者たちは、急激に変わるものをコアに入れたくない、実験的な LSP 機能を使いたくないって考えてるんだよ（ Zed が AI統合を作り直したみたいにね）。そんな混乱に対応する時間がないんだ。
プラグインシステムができれば好きなのを入れられるし、いつかコアに入るかもしれないね。
[1] https：
microsoft.github.io
language-server-protocol
specifi…

Zedを使い始めたのは、速さとAIツール統合が理由だよ。Neovimは設定が面倒で遅い。ZedはHelix並みに速くて、AI機能（インラインアシスタント、チャット、変更レビュー）がよくできてるんだ。Helixの新しいプラグインシステム（PR #8675）にも期待してる。でも、俺はエディターよりターミナル（Helix）派だから、HelixでAIが使えるようになるのが理想だな。

作者たち、全然敵対的じゃないみたいだね。自分たちが気にしない機能に労力かけるのは嫌だって姿勢だけど、AI推しのユーザーが実現するのは歓迎してるんだと。なぜか後者のグループはそれができてないみたいだけど。

これ、俺がちょっと前にHelixから離れた理由そのものだわ。Copilotがないのと、プラグイン開発の無限のbikesheddingね。

bikesheddingはもうとっくに終わったよ。今は実装作業に取りかかってるんだ。ここにリンクがあるよ。https://github.com/helix-editor/helix/pull/8675

Helixはプラグインシステムを開発中で、これでCopilot（とか他のプロダクト）が使えるようになるはずだよ。あと、これまでのHelixのやり方だと、何でもLSPで作るから、Copilot LSPを作るんだろうね（多分もうあると思うけど）。

なんか変わってなきゃ、Helixで試したAIバックエンドの言語サーバーは全部、補完に関して同じ制限があるんだ。サジェストが表示されるのは、一番遅い言語サーバーが応答するかタイムアウトするまでなんだよね。待たされる時間は一番遅いサーバーが決めるんだ。この問題を認識してる唯一のプロジェクトはこれだな。https://github.com/SilasMarvin/lsp-ai これは補完からコードアクション経由のチャットインタラクションに方向転換したらしい。

AI統合の理想的なUXにはLSPじゃ全然足りない気がするんだよね。AI補完にはLSPでいいだろうけど、俺たちがまだよく知らないカスタムUXが必要だと思う。例えばZedが提供してるのは便利そうだし、Claude Codeがやってるのもすごく好きだわ。LSPの仕様をよく知らないから、こういう複雑なインタラクションができるかは分からないけど、LSPの範囲からは超えてる気がするな、俺的には。

俺はHelix大好きだし、これ（AI）には全然興味ないな。何百ものプラグインでかろうじて動いてるエディターより、頑丈なエディターが好きだわ。

これ、俺にもマジで当てはまるわ！Helixは綺麗だし、動きも最高。エディターにAIが統合されてなくても全然幸せだし、Helixは余計な機能なしで俺が欲しいものそのものなんだ！

これ、エディターをIDEにしたいっていう、いつもの人たちの範囲の話っぽいな。そして他のほとんどのことみたいに、エディターはAI統合の貧弱なポイントなんだよ。シェルとかプロセス間通信が統合のゴールドスタンダードで、そこから一番いい統合が出てきてる。エディターを置き換えようとするんじゃなくて、連携するようなもの。Aiderがこれまでのところ最高の例だと思うけど、他にもあれば教えてほしいな。