ZedがWindowsで登場！Rustなのにまさかの大容量で騒然！？

Zedに完全に移行できない理由の一つは、開いているファイルの外部からの変更を自動で更新してくれないことだね。他のエディタは対応してるのに、Zedはそうじゃない。毎回ファイルを閉じたり開いたりするのは嫌だし、そのうち忘れて作業を失うだろうな。
https://github.com/zed-industries/zed/issues/15791

他のエディタって、君の経験だとどうやってる？VSCodeもほとんど同じで、保存時に手動マージエディタが出るけど、変更はライブで表示されないはずだよ。何かコンテナとか仮想ファイルシステムを使ってるのかな？

他のエディタは、ディスク上のファイル変更をポップアップで教えてくれて、リロードするか上書きするか尋ねてくれるんだ（geanyがそうだよ）。エディタウィンドウにマウスを合わせるだけで即座にね。Zedは最初の変更は表示するけど、それ以降は拾ってくれないのが不思議。Zedのインストーラー使ってるし、最新版、コンテナも仮想ファイルシステムもなし、パーティションはext4だよ。

しばらく使ってみたけど、まあまあかな。タイピングの遅延は気にならないから、個人的には魅力が見出せないね。VS Codeで得られないものもないし、物足りない感じ。もし本当にパフォーマンスを気にするならNeovimを使うよ。

Neovimは意外と重いと感じるな。もちろん拡張機能を色々入れた後だけどね。特にパフォーマンスが良いとは思わないな。Zedの方がずっとキビキビ動くよ。

C++とTypescriptを書いてるんだけど、WindowsでZedを試したけど、そこまで速いとは感じなかったな（少しは速いかも）。それより悪いのはC++の自動補完。Zedは現代C++をあまり理解してない感じがしたし、補完も壊れてた。乗り換えるほどの優位性は今のところ感じないよ。

君のカスタムDevContainerについて、もう少し詳しく教えてくれるかな？

VSCodeのDev Containersって良いよね。Fedora Silverblueの「Toolbox」で同じことできるか気になるな。会社ではみんな同じ環境で開発できるからDev Containerはマジ便利！

Dev Containerって実際、何がいいの？自分の環境設定を全部記録するのは分かるんだけど、それだけじゃないよね？

OPじゃないけど、うちのチームではDev Containerが超便利だよ。みんな同じ環境、同じシステム依存で、開発マシンはDockerだけでOK。コンテナ内でコード動かしたり、シェル使ったり、本番に近い環境で作業できる。プロジェクトごとの依存関係の衝突も防げるしね。

Dev ContainerでClaude Codeを、ツール全部入りのサンドボックスで動かしてるよ。おかげで、ある程度安全にYOLOモードを実行できるんだ。

それって結構無駄じゃない？複雑なDockerfileなんか使わずに、ベースシステムから「ツールやサービス全部」をマウントすればいいんだよ。詳しくはこの記事を読んでみて: https://blog.gpkb.org/posts/ai-agent-sandbox/

なんで、手間がかかって、安全じゃなくて、クロスプラットフォームでもないようなことをする必要があるの？

それって手間も少ないし、安全性も同じくらいだよ。まあ、君がそうしたいならそうすればいいけどね。

古いPHPアプリを触ることがあって、5.4みたいな超古いバージョンじゃないと動かないやつがあるんだ。今のシステムじゃインストールもオンボーディングも大変で、詳細なセットアップドキュメントを毎回書いて時間かかるし。だったら、そのドキュメントをビルド指示として書いて、結果をシステムから隔離すれば良いんじゃない？

これって同じ話してる？君の話は、開発中のソフトを動かすDocker/Compose環境っぽいけど、Dev Containerって、静的解析ツールやLanguage Serverとか、エディタ関係をコンテナで動かすことだよ。

うちのチームでは、Dev Containerのおかげで開発者のオンボーディングが爆速で、ホスト設定は一切いらないんだ。超複雑なリポジトリで、珍しいシステム依存が山ほどあるんだけど、マルチアーキテクチャのベースイメージ作って、その上にDev Containerを構築してる。フックで環境設定も一貫してバージョン管理できるし、もう手放せないね。

複雑なツールチェーン、特にコンパイルが必要なものと一緒に使うとき、これめっちゃ便利だよ。ファイルシステムのクリーンアップは、コンテナを削除して新しいのを立ち上げるだけで超簡単だし。WindowsでOCaml使うときとかマジ助かるね。

オープンソースプロジェクトに超いいよ。小さい修正ならローカルにツールチェーン入れる必要ないし。GoのPOCで使ったけど、誰もGo入れてなかったから助かったんだ。Goは簡単だけど、一回きりのPOCでインストールしてって頼めないもんね。Ruby on MacOSみたいにOSとケンカするツールチェーンもあるし。

質問の仕方が悪かったかな。「普通のDocker Composeと比べて何が良いの？」って聞けばよかった。みんなDocker Composeでできることばっか言ってるけど、俺なんか見落としてる？

俺はdev containerの中でZedを動かしてるよ。でもbubblewrapを使ったカスタムのだけどね。

サブピクセルフォントレンダリングって、もう実装されたの？Linuxだとそれが問題だったよね。MacのHiDPIディスプレイ用にUI作ったせいで、LinuxやWindowsのLoDPIユーザーにはフォントがぼやけて見えてたの覚えてるよ。

サブピクセルフォントレンダリングはわかんないけど、Linuxのフォントレンダリングは先週のパッチでめちゃくちゃ改善されたみたいだよ。
https://github.com/zed-industries/zed/issues/7992#issuecomme…

その進展は嬉しいね。もしサブピクセルRGBアンチエイリアシングが実装されたら、代替としてマジで考える価値あるよ。Zedのテキストレンダリングがずっと酷かったのに、みんな褒めてるのが不思議だったんだ。

でも正直、高解像度モニターが普通になった今、サブピクセルテキストレンダリングってそこまで重要かな？LoDPIはもう例外だし。

たまには大都市とか高給取りの仕事から離れて、現実を見た方がいいよ。世界のほとんどの人にとって、高DPIモニターなんて例外中の例外なんだから。

西洋でなくてもこれは関係あるよ。俺がよく行くFortune 500企業のソフトウェア開発オフィスと、そこそこの規模の大学のオフィスや共用スペース（教室、コンピュータ室など）では、モニターの80％以上が1080pだよ。

それでも視界が悪いから、今年初めに45インチ3440x1440モニターにアップグレードしたんだ。125%で見てるから、サブピクセルフォントは読みやすさにすごく役立つよ、ネイティブピクセルはよく見えないけどね。高DPIじゃないけど、大きくてズームされてる感じ。良い点としては、4:3モニター2枚を並べたような感じで、画面半分でアプリを並べるのは最高。悪い点はRDPセッションが最悪ってこと。スケーリング対応RDPアプリを探さないと。

俺の知ってるほとんどの人は1920x1080のLCDを使ってるよ。PCゲーマーの半分以上がその解像度みたいだね。例えばこれを見て：https://store.steampowered.com/hwsurvey

俺のゲーミングPCも1080pディスプレイに繋いでるよ、正直ゲームならそれで十分だからね。でも、高DPIディスプレイと比べるとClearTypeがあってもなくてもアプリのテキスト品質はかなり悪いから、その設定で文句は言わないけどね😉

うん、Fedoraで試してみたんだけど、ひどいテキストレンダリングのせいで、俺にとっては即削除だったよ。

なんでここでサブピクセルRGBアンチエイリアシングが必要なの？コードのためにゲームエンジンを動かしてるってこと？

フォントのサブピクセルアンチエイリアシングは数十年前からかなり標準的な機能だよ。それが無いと、特定のディスプレイでテキストがぼやけて見えることがあるね。＞ゲームエンジンでコードを動かしてるのかって？Zedは文字通りそれをやってるよ。ビデオゲームみたいにグラフィックライブラリを使ってUIをレンダリングしてるんだ。

「GPUアクセラレート」とか「ゲームエンジンみたい」って表現を見るのは面白いよね、文字通り全てのアプリケーションが同じAPIで同じようにレンダリングされてるのにさ。

最後に確認した限りでは、WPFアプリを作るのにGLコンテキストは作成しないよ。

その”after”画像はまだサブピクセルじゃなくてグレースケールAAでレンダリングされてるね。でも彼らが変更したおかげで、少なくとも読みやすくはなったよ。

Windows版のZedはレンダリングにDirectX 11、テキストにDirectWriteを使ってて、Windowsらしい見た目に合わせてるんだって。DirectWriteのフォントレンダリングはWindowsのサブピクセルレンダリングを使ってるみたい。俺のモニターではLinux版より良く見えるし、開発者はこの問題をちゃんと予期して設計したみたいだよ！

macOSで試したら、1440pの外部モニターだとフォントがマジでひどかったわ。ノートPCの“Retina”ディスプレイでは問題ないけど、他のモニターだとぼやけすぎて数時間で頭痛がしたよ。

これ、ちょっと混乱するんだけど。ZedってWindowsでDirectWriteを使ってるみたいに、macOSではCoreTextを使うんじゃないの？macOSのCoreTextがこの問題を全部解決してくれないとダメでしょ？

適当な推測だけど、サブピクセルレンダリングってレンダリングパイプラインとの連携も必要だよね。グリフの表示位置に合わせて分数オフセットをラスタライゼーションエンジンに渡す仕組みとか、グリフアトラスがRGBAテクスチャであることとか、ラスタライザーがテクスチャフォーマットを知ってること、とかが必要なんじゃないかな。

分数オフセットって、本当に必要なの？

いろんな表現方法があるけど、“サブ”って付いてるんだから、どこかの段階で分数ピクセルを扱わないといけないってことだよね、きっと。:-)

グリフの位置を分数にする必要はないよ。サブピクセルレンダリング自体は、特定のディスプレイのサブピクセル（赤、緑、青、その並び順とか）の配置に関する知識を利用するだけだからね。

eguiみたいな作りなら、フォントアトラスにレンダリングしてるのかもしれない。そうなると、サブピクセルAAが複雑になる可能性もあるんじゃないかな。

俺、数ヶ月前にZed使うのやめちゃったんだけど、先週からLinux版のフォントレンダリングがFull HDでもHiDPIディスプレイでもすげー良く見えるようになってるじゃん！

Zedをインストールして1440pモニターでフォントを試したけど、まあまあかな。Windowsのフォントレンダリングがひどいのが原因だと思う。Zed特有の問題じゃなくて、VSCodeも同じ感じ。最近は4k以上のディスプレイじゃないと高品質なフォントレンダリングは無理みたいだね。

＞ Windowsのひどいフォントレンダリング
半分の人はWindowsのフォントレンダリングを気に入ってるってことを知っておいてほしいな。

なるほどね。OS全体を非難するんじゃなくて、最近のフォントがWindows向けに適切にヒント処理されてないって言えばよかったかも。

数ヶ月Zedを使ってたけど、VSCodeに戻ったよ。2つの理由がある。1つは俺のミスだけど、Zedの右クリックメニューにある”Delete”と”Trash”が並んでて、”Delete”はゴミ箱を通さずCtrl+Zも効かないのが問題。大事なファイルを間違って消しちゃった。もう1つは、Rustの特定のクレートでエラーや警告がZedに表示されなくて、VSCodeだと問題なく動いたこと。

＞ Deleteはゴミ箱を通さず、ZedはまだCtrl+Zを実装していない
ZedのUIが良いとは言わないけど、文字通り”skip the undo-ability of this option”機能に対してCtrl+Zを実装していないと言うのは、ちょっと誤解を招く言い方じゃないかな。

君の言いたいことはわかるし、正しいと思うよ。でも、’Trash’ボタンが確認ボックスの後ろになくて、取り消せないなら、それはかなりひどいデザイン選択だね。

今Zedをダウンロードしたんだけど、”Trash”も”Delete”も確認ボックスの後ろにあったよ。”Trash”は（Windowsの）ゴミ箱に送られるし、”Delete”はちゃんと削除される。ゴミ箱には元に戻す機能はないけど、普通のゴミ箱やリサイクルビンから復元できるよ。

うん、今Windowsビルドを試したら、確かに（TrashとDeleteの両方で）確認ボックスの後ろにあったよ。今朝OPのコメントを読んでた時には、そんな印象は受けなかったんだけどね。

OPだよ。長年VSCodeを使ってたから癖になってた。”Delete”は両方とも右クリックメニューの最後にあって、似た確認ダイアログが出るんだ。VSCodeの”Delete”はファイルをゴミ箱に移してCtrl+Zで元に戻せるけど、Zedの”Delete”はゴミ箱をスキップしてCtrl+Zも効かない。確認ボックスのことは言うべきだったけど、無意識にクリックしすぎてて、Zedの挙動が違うことに気づかなかったよ。

うん、確認ボックスがあるから問題は少しマシになったけど、コンテキストメニューに”Trash”と”Delete”が並んでるってのは、個人的にはまだ問題だと思うな。