ハクソク

世界を動かす技術を、日本語で。

Editがオープンソースになりました

371日前原文(devblogs.microsoft.com)

概要

  • Edit はWindows用の新しいコマンドラインテキストエディターであることを紹介。
  • Edit はオープンソースであり、GitHubから入手・ビルド可能であることを強調。
  • Windows Insider Program でプレビュー提供後、Windows 11に標準搭載される予定。
  • 軽量性・複数ファイル対応・検索置換等の基本機能 を網羅。
  • 初心者にも扱いやすいモデルレス設計 が特徴であることを説明。

Edit：Windows向け新コマンドラインテキストエディター

Editの概要とインストール方法

  • Edit はWindows向けの新しいコマンドラインテキストエディターであることを強調。
  • オープンソース としてGitHubで公開されているため、誰でもソースコードをビルド・最新版をインストール可能であることを説明。
  • 近日中に Windows Insider Program でプレビュー提供し、その後 Windows 11 に標準搭載する計画を示すこと。
  • コマンドラインでeditまたはedit <ファイル名>を実行することで、直接ファイル編集が可能であることを案内。
  • コンテキストスイッチを減らし、CLI上で効率的に作業できることを提案。

Editの主な特徴

  • 軽量性 ：Editは約250kBと非常に小さく、Windows 11イメージへの組み込み時も負担が少ないことを強調。
  • マウスモード対応 ：TUI（Text User Interface）であり、すべてのメニューオプションに キーバインディング が割り当てられていることを確認。
  • 複数ファイルの同時編集 ：複数ファイルを開き、 Ctrl+P や右下のファイルリストクリックで切り替え可能であることを案内。
  • 検索と置換 ： Ctrl+R またはTUIメニューから「Edit > Replace」を選択し、検索・置換ができることを説明。
    • 大文字小文字の区別 や 正規表現 にも対応していることを補足。
  • ワードラップ ： Alt+Z または「View > Word Wrap」でワードラップ機能を有効化できることを案内。

Edit開発の背景と目的

  • 64ビット版Windows にはデフォルトのCLIエディターが存在しなかったことを背景として説明。
  • 32ビット版Windowsには MS-DOS Editor が標準搭載されていたが、64ビット版では同等のCLIエディターがなかったことを確認。
  • modal（モード切替）型エディター （例：Vim）は初心者にとって操作が難しく、「How do I exit vim?」というミームが生まれる原因であることを指摘。
  • 新規ユーザーでも直感的に扱える モデルレスエディター を目指したことを説明。
  • Windowsに適した 軽量かつ扱いやすいエディター が必要だったため、Editを開発した経緯を述べること。

今後の展開とフィードバック

  • Edit は今後数ヶ月以内にWindows Insider Program向けに順次展開されることを案内。
  • オープンソース なので、GitHubリポジトリからビルド・インストールが可能であることを再度強調。
  • フィードバックや質問は Edit公式リポジトリ で受け付けていることを案内。
  • 公式情報や詳細は GitHubのEditリポジトリ を確認すること。
  • 新しいCLIテキストエディター導入による 作業効率向上 を期待すること。

Hackerたちの意見

SSHで使えるデフォルトのテキストエディタがやっとできたのは嬉しいね。SSH越しにWindowsサーバーを管理するのはちょっと面倒だから。nanoをパッケージ化すればよかったのに、まあ仕方ないか。

└

ターミナルで使えるテキストエディタができたから、2025年はWindowsがサーバーの年になるって呼んでるよ。/s

└

またはkilo[1] [0]: https://github.com/antirez/kilo/

└

なるほど、そういうことか。最初は、なんでWindowsが内蔵のテキストモードエディタを欲しがるのか全然わからなくて混乱してたんだ。SSHでWindowsマシンにアクセスする人がいるなら…RDPじゃダメなの？って疑問もあるけど、実際にそういうことしてる人がいるなら、内蔵エディタを追加するのは理解できるね。

└

そう言おうと思ってた、私はnanoをローカルでもSSH越しでもよく使ってるよ（インストールされてるマシンにはほとんど全部使えるし）。これいい感じだし、昔ながらのコンソールUIが大好きなんだ。EDIT.COMやNC.EXEを懐かしく思い出すし、今でもmcを使ってSSHFSに接続してるよ。昔はEDIT.COMで編集してた.BATファイルをメンテナンスしてて、それがEDLIN.COMに投げてた（大体MS版のedみたいなもの）。あの頃は…あまり良くない昔だったな。最近は、Windows版のnanoやbusyboxがあって、フルLinuxインストールなしでもパワーツールが使えるようになったね。

└

私は本当に時代遅れだな。WindowsシステムにSSHでアクセスできるなんて知らなかったよ。

└

LSP、tree-sitter、DAPサポートを追加すれば、素晴らしいテキストモードIDEになるかもしれないね。高速な構文ハイライトのためにtree-sitterの文法を追加する可能性についてのオープンな問題がすでにあるけど、コードベースが膨れ上がらないようにオプショナルなプラグインシステムが必要だって言ってるね（例えば、Helixエディタ内のtree-sitter文法は何百メガバイトも占めてて、ここでは明らかに受け入れられない）。

└

心から同意します。Nanoは本当に素晴らしいです。戦闘テスト済みで、基本的なテキストエディタに必要な機能以上のものをすでに持っています。実際、Nanoはあまりにも「基本すぎる」と見なされがちですが、実際には基本的なエディタにはないいくつかの高度な機能（例えば、キーボードマクロ）があるんです。Nanoは基本というよりシンプルだと言いたいですね :) 数ヶ月前にここで話し合おうとしたんですが、あまり盛り上がりませんでした: https://news.ycombinator.com/item?id=41289773

└

すごくシンプルなプログラムだから、Windowsとよく統合されたプロプライエタリなプログラムを作った方がいいよ。WSLを使えばnanoも使えるしね。

└

YEditをそのまま出せばよかったのに、オープンソースだしね：http://www.malsmith.net/edit/ でもMSにはNIH症候群があるんだよね。

└

他のエディタを実際に見てくれたのには感心したよ、そんなこと期待してなかったから。WSLのことを除けば、Windowsは他に何かサードパーティのユーティリティを配布してるの？

昔、ms-dosのEDIT.COMを64ビットWindowsに移植しなかった理由って何だったんだろう。32ビット版にはまだEDLIN.COMが残ってるけどね。

└

NTVDM（仮想DOSマシン）の64ビット版がキャンセルされたんだよね。これがDOSアプリからのINT 21hシステムコールを処理してるのに。それがないと、正直移植するものはあまりなくて、新しいNTネイティブのCLIアプリを作る方が楽なんだ。

└

DOS時代のコードベースは、現代の文脈では本当にひどいよね。結局、最初から書き直さなきゃいけないだろうし。FreePascalに含まれてるTUI IDEは、まさにこの理由でビットロッティングしてる。

いつも同じところをぐるぐる回ってるのが面白いよね。edit.cmdは俺が初めて使ったプログラムの一つだよ。今はRustで書き直されてWindows 10+用のプログラムになったんだって？でも、30年前と見た目も動きも全く同じだね！

└

あなたが言ってるのはedit.comのことだと思うよ。私もこの投稿を見たときにそれを考えたから。 https://en.m.wikipedia.org/wiki/MS-DOS_Editor

Rustで書かれてるだけじゃなくて、基本的にサードパーティのクレートへの依存を避けてるみたい（必須のwindows-sys/libcを除いて）。バイナリサイズを最適化してるんだろうね。これを実現するために、Rustエコシステムのかなりの部分を再実装してるみたい（独自のTUIライブラリ、独自のユニコード処理、独自のアリーナ実装、...）。

└

ウィンドウズのクレートは、OSベンダーが公開してるから、技術的にはファーストパーティーって言えるね。

└

これはバイナリサイズの最適化だけのためではないと思います。もしサードパーティの依存関係を避けるリソースがあるなら、サードパーティのサプライチェーンに対する信頼性を構築する負担を排除できます。それが、私の職場で時々サードパーティのパッケージを使う代わりに再実装する理由の一つです：依存関係からのリスクと、それを信頼できると確立するために必要な努力が、時には（常にではありませんが）社内で置き換えるよりも大きいからです。

Rust版のQBasic Gorillasが待ちきれない！

└

これは私の生産性に対するサービス拒否攻撃だね :) 爆発半径を「戦術核バナナ」に編集してた頃を懐かしく思い出すよ。

ちょっと指摘したいんだけど、これはテキストユーザー指向（TUI）かスクリーンエディタで、CLIエディタじゃないよ。CLIエディタはed(1)とかex(1)、MS-DOS系のEDLINだね。

みんな、これ作ったよ！気に入ってくれるといいな、もし気に入らなかったら、ぜひイシューを開いてね: https://github.com/microsoft/edit いくつかの質問や、私が個人的に興味深いと思う部分に答えると、カスタムTUIライブラリはC ABIの周りにプラグインモデルを書くために作ったんだ。見つけた既存のTUIフレームワークは、人気があってもプレーンCにうまくマッピングできないことが多かった。他のは単に大きすぎた。アリーナアロケータは、Rustで木を構築するのがかなり面倒だから存在している。bumpaloは使っていないけど、「スクラッチアリーナ」にかなり惹かれたから（https://nullprogram.com/blog/2023/09/27/）そんなアロケータを書くのは本当に難しくないんだ。Rustを選んだ理由については、実際にC、C++、Zig、Rustでプロトタイプを書いたよ！この4つの中では、個人的にZigが一番好きで、その次がC、Rust、C++の順だった。ZigはまだMicrosoftで内部サポートされていないから（信頼の連鎖など）、Cで書き続けたけど、しばらくするとZigの好きな機能が欠けていることにかなりイライラしてきた。だから、数日でRustに移植したんだ。内部サポートされているし、そんなに悪くもない。Rustがあまり好きじゃなかった理由は、アロケータのサポートがかなり弱いことと、木を構築するのが難しいことだった。安定したRustでリンクリスト用のカーソルがないのも正直言ってイライラした。でも、全体的には楽しんでいたと言えるよ。nano、kilo、micro、yoriなどは様々な理由で選ばなかった。私たちが求めていたのは、小さなバイナリで、追加のバイナリサイズの正当化なしにすべてのWindowsのバリエーションと一緒に出荷できることだった。十分なUnicodeサポートも必要だったし、SSHとのシームレスな統合を可能にするためにVT出力を中心に構築されているべきだった。最後に、Windowsへのファーストクラスのサポートも非常に重要だった。リストされたエディタの中では、microが一番使いたかったけど…単に大きすぎるんだ。自分たちのエディタを作ることを提案したけど、計画の約2倍の時間がかかったけど、それでも約4ヶ月（昨年のプロトタイピングにはもう少し）で済んだ。GuinansEyebrowsが言ったように、このプロジェクトにはかなりの「NIH」があるけど、週末はすべてこれに費やしたし、クリスマスも全部これに使ったのは、単に楽しんでいたからだよ。だから、新しいことを学びながら自分でほとんどのことを書くのを楽しんでみてはどうかな？これに取り組むことでたくさんのことを学んだし、今後のプロジェクトでも使えるよ。質問があれば教えてね！

└

Zigが一番好きだなんて、とても興味深いです。これを作ってくれてありがとう！

└
  1. ZigのどこがRustより好きなの？ 2. Zig/Cのメモリが正しく解放されることをどうやって確認したの？ 3. Rustのどこが嫌いなの？
└

ナイトリーフィーチャーの使用について聞きたいな。使い方を掘り下げる時間がなかったけど、それには驚いたよ！

└

Zigの独特さは本物だね。Zigが勝ってほしいけど、ちょっと変すぎて、一貫した方向に進んでない感じがする。Rustに戻るのも分かるよ。

└

チェーンオブトラストの問題についてもう少し詳しく教えてもらえる？Rustもその問題を抱えてないの？それともmrustcを使ってrustcをブートストラップしてるの？

└

最近のマイクロソフトのレイオフでこれがなくならなかったのは本当に嬉しい！

└

GitHub Copilotや他のLLMベースのコード生成ツールを使ってコードを書いたのかな？もしそうじゃないなら、出荷のプレッシャーの中でゼロからこれだけのコードを書くのはすごいね、感心するよ。

└

ZigはまだMicrosoftで内部サポートされていないから（信頼の連鎖とか）、Zigに特有の何かがあってこうなってるの？それともただの内部政治の問題？

└

このプロジェクトを引き受けてくれてありがとう、WTを素晴らしいアプリにしてくれて！リポジトリでも感謝の気持ちを伝えたけど、同僚に「言語戦争を煽るな」とすぐに黙らされた、へへ。アーキテクチャや実装の選択には感心してるよ、特にギャップバッファとカーソルの動き。テキストエディタをミニマムな概念でマキシマムな機能性を持たせる方法について、独自に同じような結論に達したみたいだね。他の人たちがZigについて聞いてたけど、Cでやったことについてもっと聞きたいな。Cから始めたの？Cを続けなかった理由は何？もしCを続けてたら、振り返ってみて一番イライラしたことは何だった？Cで明らかに良かったことは？再度振り返ってみて、Cを続けていれば一番良かった部分は何だった？君がC文化に慣れてるのも見たし（クリス・ウェロンのブログ）、君が言及したZigの利点はクリスの洞察を使ってCで優雅に解決できたんじゃないかと思ったよ。そんな専門的なアドバイスがある中で、どうして他を探してそれを好んだのかすごく興味がある。Cの話も楽しみにしてるよ。プロジェクト頑張ってね、リポジトリで会おう！

└

Gitの履歴をチェックしたけど、Zigバージョンが含まれてるか見たら、最初のリビジョンはRustみたいだね…Zigバージョンでは僕のzigwin32プロジェクトを使ったの？それとも別の何かを使ったの？それと、ZigのビルドシステムとRustのビルドシステム、どっちが良かった？

MS-DOSのTUIアプリ、例えばeditやqbasicエディタ、xtree-goldが本当に恋しいです。Linuxターミナルベースのものは、比較するとちょっと違和感があるように感じます。ターミナルでのマウスやキーボードのサポート（シフトエンターサポートとか）も良くないのかな？人それぞれの美学があるのかな？よくわからないけど…次の目的地はVS-EDITだといいな :) （これにLSPsを使って）

└

その理由で間違いないね。DOSの世界で[Shift]+[Ins]を認識するような簡単なことをポータブルにやるのは驚くほど難しいんだ。ターミナルのパラダイムは、いくつかの面でコンソールのパラダイムとは全然違うからね。Tektronixターミナルが実際に目の前にあった時代のTUIは、今のパソコンの世界のものとはまったく違ってた。皮肉なことに、昔のTektronixやDEC VTのユーザーが未来に来たら、今のLinuxベースのOSの世界にすごく馴染むだろうね。とはいえ、Windows Terminalの人たちは、ECMA-48やITU T-416、DEC VT、XTermのようなマイナーなものをWindows Terminalに取り入れるためにかなり頑張ってるから、[Control]+[Home]の認識や逆ビデオがちゃんと動くようにするために変なことを全部書く準備ができてるTUIアプリケーションの作成者には、実際にそれが手に入るんだ。

└

DOSはTUIアプリの黄金時代だったね。なぜなら、その究極のAPIはシンプルでパワフルだったから：テキストモードでの直接的なビデオメモリアクセス。だから、画面上の各文字が2バイトに対応する線形のメモリの塊を得られるんだ。1つはグリフ用、もう1つは前景/背景色用（それぞれ4ビット）。入力にはBIOSのヘルパー割り込みがあったけど、スキャンコードを直接読み取るのも簡単だったし（PCで標準化されてたし）。だから、どんなキーやキーコンボも好きなように扱えるし、オートスクロールみたいな変なケースもなく、どこにでも文字を置けるんだ。

魔法の終了コマンドを覚えるのは比較的簡単だけど、これが新しいプログラマーや古いプログラマーにとってつまずきの石になるのは偶然じゃないよね。もっと簡単なのは、ひどいデフォルト設定を変更して、メニューを追加することで、これを新しいエディタを書くのにかかる時間のほんの一部で解決できることだよ。> 私たちは、Windows用のモデルレスエディタが欲しいと決めたんだ（新しいユーザーが異なる操作モードを覚えたり、切り替えたりする必要があるモーダルエディタとは違って）。新しいユーザーは、常にバックグラウンドでモードの力を使って挿入モードで全てを行えるんだ。また、切り替え方を覚える必要もなくて、重要だと思うなら、メニューやステータスバーにそのキーのバインドを表示できるから、スクリーンショットを見ると十分なスペースがあるよ。そんな薄っぺらい理由で強力で拡張性のあるものを使うチャンスを無駄にしてるね。

└

新しいユーザーは間違ったキーを押して間違ったモードに入っちゃって、「モード」って何かもわからなくて困っちゃうことがあるよね。基本的な軽量テキストエディタにモードがある必要はないと思う。パワーユーザーが欲しいなら、必要に応じてVimをインストールすればいいし。

新しいMicrosoft Editはいいね。EDIT.COMほど良くはないけど、ちゃんと仕事をこなしてる。いくつか気になる点があって、単語数がカウントできない（これはすごく便利だと思う）し、シェルに逃げる方法がない（これがあれば軽いスクリプト作業にもっと使いやすくなる）。あまり気にしないけど、Windows Terminalで選択したターミナルフォントをハイジャックするのが嫌だし、LinuxターミナルでEscを押してメニューを閉じられないのも嫌だし、すべての機能に直接ショートカットでアクセスできないのも不満だね。例えば、編集中のファイルを変更するには、View > Focus Statusbarを選んで、左矢印を押して、編集されたファイルのリストを選ぶためにEnterを押して、切り替えたいファイルを選んで、再度Enterを押さなきゃいけない。これにショートカットがないのはなぜだろう、一般的な使い方なのに。サイドプロジェクトとしては全体的にとても良いよ。これらの問題が解決されれば、十分なエディタになるだろうね。そうなれば、欠けているのは自動化や拡張性のための埋め込みLispインタープリタだけだね。:) 追記：テレメトリーはないよね？

└

なんでEDIT.COMほど良くないの？