Microsoft Edit

 (github.com/microsoft)
3 ポイント 投稿者 GN⁺ 2025-06-26 | 1件のコメント | WhatsAppで共有
  • Microsoft Edit は、シンプルな編集ニーズのためのエディタで、classic MS-DOS Editor への敬意を示しつつ、VS Code に似たモダンなインターフェースと入力操作を提供する
  • 目標は、ターミナルに慣れていないユーザーでも簡単に使える アクセシビリティの高いエディタ を提供すること
  • Windows では WinGet、macOS では Homebrew、Linux ではディストリビューションのバイナリがない場合や自分でビルドしたい場合にインストールスクリプトで導入できる
  • Rust で構築され、nightly Rust の設定はバイナリサイズを大幅に削減し、性能をわずかに改善する方法として推奨されている
  • パッケージ管理者は実行ファイル名の衝突の可能性から edit ではなく msedit の名称が推奨され、検索/置換機能には ICU ライブラリ設定が影響する

Microsoft Edit の目的と性格

  • Edit は「simple editor for simple needs」を目標とするシンプルなエディタ
  • classic MS-DOS Editor への敬意を示しつつ、モダンなインターフェースと VS Code に似た入力操作を提供する
  • ターミナルに慣れていないユーザーでも簡単に使える アクセシブルなエディタ を志向している

インストール方法

  • バイナリは Releases page からダウンロードできる

  • Windows

    • 最新バージョンは WinGet でインストール可能
    winget install Microsoft.Edit

  • Linux

    • ディストリビューションがバイナリを提供していない場合や、自分でビルドする場合はインストールスクリプトを利用できる
    • 必要条件は Rust、C コンパイラ、ICU、curl または wget、tar
    • デフォルトのインストールでは msedit を ~/.local/bin に配置する
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh
    • 追加フラグとして --dev は main ブランチから直接ビルドし、--system は /usr/local/bin にインストールする
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh -s -- --dev --system

  • macOS

    • 最新バージョンは Homebrew でインストール可能
    brew install msedit

ビルド方法

  • ビルドには Rust のインストールとリポジトリのクローンが必要
  • nightly Rust を使う場合は、次のコマンドで release ビルドする 
    cargo build --release --config .cargo/release.toml
  • stable Rust を使う場合は、RUSTC_BOOTSTRAP=1 環境変数を設定して nightly ビルド手順に従う方法が推奨される
    • この方法はバイナリサイズを大幅に削減し、性能をわずかに改善する
  • 追加設定なしで stable Rust でビルドする場合は、次のコマンドを使用する 
    cargo build --release

ビルド構成オプション

  • ビルド時は環境変数で構成を調整できる
  • EDIT_CFG_ICU* は ICU ライブラリ名 の設定に関係し、Linux のパッケージ管理者にはこのオプションの確認が推奨される
  • EDIT_CFG_LANGUAGES はビルドに含める言語の一覧をカンマ区切りで指定する

パッケージ管理者向けの注意事項

  • 標準の実行ファイル名は edit、代替名は msedit
  • 既存コマンドと edit の名前が衝突する可能性があるため、パッケージ名と実行ファイル名には msedit を推奨する
  • ms-edit のような名前は避けるべき
  • 可能であれば edit エイリアスを割り当てる方法が推奨される

ICU 関連設定

  • このプロジェクトは検索/置換機能のために ICU ライブラリ に任意で依存する
  • デフォルトではプラットフォームごとの ICU ライブラリ名を探す
    • Windows: icuuc.dll, icuin.dll
    • macOS: libicucore.dylib
    • Linux およびその他: libicuuc.so, libicui18n.so
  • インストール環境の SONAME が異なる場合は、ビルド時に環境変数を設定する必要がある
    • EDIT_CFG_ICUUC_SONAME: 例 libicuuc.so.76
    • EDIT_CFG_ICUI18N_SONAME: 例 libicui18n.so.76
  • ICU シンボルはデフォルトで _ 接頭辞やバージョンサフィックスなしの u_errorName のような形式で export されていると想定している
  • 異なるシンボル形式を使う環境では追加の環境変数を利用できる
    • EDIT_CFG_ICU_CPP_EXPORTS=true: _u_errorName のような C++ シンボルを探し、macOS ではデフォルトで有効
    • EDIT_CFG_ICU_RENAMING_VERSION=76: u_errorName_76 のようなシンボルを探す
  • EDIT_CFG_ICU_RENAMING_AUTO_DETECT=true を設定すると、実行ファイルはランタイムに renaming version の値を検出しようと試みる
    • この方法は ICU が公式にはサポートしていないため、依存しないことが推奨される
    • UNIX では macOS を除き、ほかの選択肢がない場合にデフォルトで有効になる
  • ビルド設定のテストは cargo test に --ignored フラグを付けて実行する 
    cargo test -- --ignored

関連記事

1件のコメント

 
GN⁺ 2025-06-26
Hacker News の意見

  • この記事は1週間に3回も上がるほど関心が大きかった

    1. 著者本人 - https://news.ycombinator.com/item?id=44034961
    2. Ubuntu Publication - https://news.ycombinator.com/item?id=44306892 そして今回の記事

  • このエディタの対象ユーザー層には以前は micro を勧めていたが、そろそろ変えるべきか気になる

    1: https://micro-editor.github.io/

    • 変える必要はなさそう edit は、少なくともすぐ試した時点では構文ハイライトも標準対応していなかった
    • 最後に確認したとき、micro はバイナリサイズだけ見ると macro と呼ぶべきほどだった
    • dte もある。同じところを的確に狙いつつ、Unicode 対応や CUA キーバインドなど、より多くの機能を備えた非常に軽量なエディタ nano の代わりにターミナルエディタとして使っている [1]: https://craigbarnes.gitlab.io/dte/
    • Micro は nano のようなものを置き換えるには優れたエディタ。ただし edit の代替としてはあまり良くなさそうで、edit はかなり基本的なのに対し、micro は Lua でかなり拡張可能 大きなファイルもかなりうまく扱える
    • Windows でも "winget install zyedidia.micro" だけでインストール可能。同時代の8ビット・16ビットエディタを思い出す

  • Microsoft 規模の組織で、こういうプロジェクトがどう承認されるのか本当に気になる。何人かの開発者のサイドプロジェクトなのか、それとも製品ロードマップの一部なのか知りたい リーダー層にここへ時間を使おうとどう説得したのだろうか？

    • 説明どおりなら、Windows Core サーバーインストールで動作するコマンドラインテキストエディタが必要だった Windows に SSH Server が含まれてからかなり経っており、SSH だけでも完全に管理できるため、vi の経験がない Windows 管理者でも使えるモードレスエディタが必要だったということ
    • テキストエディタは Copilot 統合の対象としてあまりにも自然
    • 各グループは何かをしなければならず、アイデアを出すことになる。ある時は「Copilot を使え」のようなリーダーシップの方針から来るし、ある時は hackerdayz のようなイベントのアイデアが拡張される 研究組織で技術者が余裕を持って始める場合もあれば、深い分析と何度もの半期を経て資金を得る場合もある ここのコントリビューター数を見ると、このプロジェクトはおそらく戦略的投資だった可能性が高い。一晩で出てきたものではない

  • DOS 6.22 と、その後の 7.0、つまり Win95 頃の元の edit.com は自分にとって最初の IDE だった。qbasic から始めて、似た、あるいは同じインターフェースに慣れており、djgpp で C/C++ を学ぶときもずっと edit.com を使っていた 自分の「プロジェクトファイル」は edit file1.cpp file2.cpp file3.cpp が入った e.bat で、Alt-1,2,3 で簡単に切り替えられるなかなか良い複数ファイル対応があったので使っていた。今でもエディタのキーバインドを Alt/Cmd-1,2,3 でファイル切り替えできるように再マップし、「アクティブセット」を先頭の数個のファイルに小さく保とうとしている 構文ハイライトもなく、インデントの挙動もあまり良くなかったので、優れたコードエディタではなかった。そのためキャリア初期には、手で打ちやすく、タブっぽくないスペース2つのインデントを使っていた。それでもコードに直接触れている感覚は強かった 他の人たちが qedit のようなエディタをよく使っているのは知っていたが、不思議としっくり来ず、Unix 風のエディタも DOS ではぎこちなかった 少し試したところ、複数バッファをサポートしているようではあるが、同じキーバインドでバッファ切り替えはできないようだ

    • そういうものは issue として上げるのが良い。こうした点は初期に入れば反映される可能性がある そして単に似ていたのではなく、文字どおり同じだった。EDIT.COM は特殊なフラグで QBASIC を起動していただけで、QBASIC をそのフラグ付きで直接実行することもできた。https://news.ycombinator.com/item?id=44037509 で言ったように、面白半分で実際にそうしてみた
    • 構文ハイライトはなかったが、他に良い言い方がないので言うと、構文の大文字化はあった 1行をすべて小文字で入力して Enter を押すと、予約語を自動で大文字に変えてくれた。大したものではなかったが助かった
    • copy con の時代の後に出てきた edit は本当に救世主だった

  • 気に入った点が多い。まず依存関係の一覧が空だなんて、それだけでもう納得した とてもよく動く。ファイルブラウザとダイアログまで備えた TUI を、このために丸ごと作ったというのが信じられない。自分のプロジェクトでも使いたいが、どれくらい簡単なのか気になる。プロジェクト関係者がここにいるなら、なぜ Ratatui を使わなかったのかも気になる コード品質も最高レベルで、ひと言だけ言える: Bravo!

    • テストを楽にするいくつかの開発依存を除けば、文字どおり依存関係がない Windows のような OS で管理者が使う基本ツールとして配布するものなら、合理的な選択だ。「自作する」ことに関する背景は lhecker の回答を見るとさらに分かる [1]: https://news.ycombinator.com/threads?id=lhecker

  • 1か月ほど前、MicrosoftがWindowsユーザーにより親しみやすく感じてもらうために独自のLinuxディストリビューションを持っている、という話を聞いた。記憶では、かなりシンプルなGNOME構成で、特別なものではなかった
    Microsoftがbashの代わりにPowerShellを入れ、vimやnanoのような選択肢と一緒にEditを入れ、開発者向けインストールには.NETとVisual Studio Codeを含める、Microsoft専用Linuxディストリビューションを作る機会を使わなかったのは意外だ
    これをデフォルトのWSLインストールにすることもできたはずだ。UbuntuやDebianのような典型的なディストリビューションとの争いに勝つことはなかっただろうが、Windowsユーザーは多いので一定のシェアを得て、よくある選択肢になれたかもしれない
    MicrosoftはLinuxカーネルを支配することはできないが、ユーザー空間は掌握できる。自社アプリケーションが人気ディストリビューションに標準インストールされる流れを作っていたらどうなっていたか、想像してみる価値はある
    Microsoft EditもPowerShellなどと同じくLinuxで使える。10年ほど前にカードをうまく切っていれば、多くのWindowsユーザーがWSLで使うおかげで、彼らのディストリビューションは今ごろ上位5位以内に入っていたかもしれない
    巨大企業は個人の空間に自分たちの痕跡を押し込める。あとはMicrosoft EditでCo-Pilotがデフォルトでオンになるだけだ

    • 時間が経てば、MicrosoftがLinuxへ移行していく可能性は高いと思う。少なくともWindows Serverと組み込みWindowsの方面ではそうで、その後Windowsデスクトップも段階的に変わるか、Windows LegacyとWindows “Linux Workstation”のような選択肢に分かれるかもしれない
      Linuxカーネルの上に一種の「スーパー」WINEを載せ、特定のプログラムには仮想マシン内で密接に統合された従来のWindowsをフォールバックとして提供する、といった形かもしれない
      ただし問題は、NTカーネルには設計面でLinuxカーネルより優れている部分が多いことだ。たとえばNTカーネルはGPUドライバが完全に死んでも復旧できるが、Linuxはそうした状況にはかなり苦労しそうだ。他のドライバも同様だ
      しかしWindowsはMicrosoftにとって、だんだん資産というより負債になりつつあり、特にサーバー領域ではそうだ。主要な収益源はAzureとOffice 365で、いまだに2桁成長を続けている一方、Windowsライセンスの成長は停滞している
      少なくともLinuxベースのWindows ServerやLinuxベースのWindows Workstationのようなバージョンは出てくると思う
    • WSLが存在する理由は、企業の開発者たちにLinuxを実行する方法が必要だったからだ
      ITサポートやテクニカルサポートの担当者は、たいていLinuxをよく知らず、サポートしたがらない。WSLはこの問題を解決する
      ほとんどの開発者はLinuxそのものを使いたいわけではない。多くの開発者はターミナルの使い方もまともに知らず、GUIツールに依存している
    • Microsoftが専用Linuxディストリビューションを作らなかったのが意外だというなら、最後の試みはあまりうまくいかなかった。名前はXenixだった
    • 知名度は役に立つと思う。開発者は聞いたこともないディストリビューションはインストールしたがらないが、Ubuntuならインストールしたがる
      WSLがUbuntuをサポートすれば、その知名度を活用できる
    • Microsoftの第一のLinuxディストリビューションであるAzure Linux（旧CBL-Mariner）と、人々が昔から作ってきたWindows風に見えるLinuxデスクトップ環境スキンを混同しているようだ
      Azure Linuxは、コンテナ、VM、サーバーなどで使うためのMicrosoftサポートのOSだ

  • これは単に「やってみたかったから」作ったプロジェクトに見える。自分も何が起きているのか理解するためにそういうことをたくさんやってきたので、気持ちは分かる
    だがTurbo VisionをFPCで書き直して複数ターゲット向けにコンパイルする取り組みは、20年前からあった。Turbo Visionはおそらく、存在する中で最高のテキストモード・ウィンドウイングライブラリだ
    面白い部分は、テキスト画面全体をこういう配列にマッピングできるところから始まる:
    var
    Screen: Array[1..80,1..25] Of Byte Absolute $B800; // or something like that as i recall
    Turbo Visionがもたらしたのは、移動可能なモーダル/非モーダルウィンドウだった。基本的にはその配列をループ内でずっと書き直す構造で、かなりきびきび動いた。そのライブラリで大いに稼いだ

    • 興味のある人向けに、Unicodeもサポートする現代的なC++版Turbo Visionの移植がある:
      https://github.com/magiblot/tvision
    • これは「やってみたかったから」作ったプロジェクトではない。Windowsに含まれ、SSH越しでも動作する小さなTUIエディタが必要だったのだ
      https://news.ycombinator.com/item?id=44034961
    • 正確には array[1..25, 1..80] of Word absolute $B800:0000 だ
      TPの配列は行優先順で配置され、各文字は2バイトで表現された。1つは文字そのもの、もう1つは属性（前景/背景色と点滅）だった
      なので、より良く書くなら array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000 となる
      Herculesのようなモノクロのテキストディスプレイ（モード7）では、$B800を$B000に変えればよい
    • Turbo Visionでどうやって稼いだのか気になる。よければ共有してほしい
    • 新しい現代的なTUIフレームワークを見るたびに、失望はいつも同じだ。「ああ、これはTurbo Visionほど良くないな」

  • 今はUnicode対応のEDLINを待っている
    バッチファイルで標準入力からキー入力をパイプして、何らかの編集作業をスクリプト化できたのを覚えている。sedやawkの一部機能の代わりのような感じだった
    試したことはないが、viでも可能そうだ。それが非常に呪われたやり方かどうかは別として

    • 探しているのはたぶんedだと思う。場合によっては-sと一緒に使えばよい

  • 面白い。正直、誰に使わせるために作ったものなのかはよく分からないけど、面白そうではある

    • Windows Terminal でファイルを編集したい人向けのもの。昔の edit コマンドは 2006 年以降 Windows でサポートされていないので、それ以来コマンドラインで使える Microsoft 提供のエディタはなかった
      このエディタがどれほど高速なのかは印象的。https://github.com/microsoft/edit/pull/408

      改行検索に特化した SIMD ルーチンを書けば、[125GB/s まで]引き上げられる

    • README にそのまま書いてある:

      目標は、ターミナルにほとんど慣れていないユーザーでも簡単に使える、アクセシビリティの高いエディタを提供することだ

    • Notepad よりはるかに大きな改善
    • LSP 対応や ripgrep ベースの検索がある、または追加されるなら、喜んで vim の代わりに使える
      今は Helix を使っているが、良い TUI は好き
    • vi が嫌いで、ターミナル上で nano の代わりになる、もっとまともなものを探している自分のような人向けのもの

  • 1993 年には edit でバイナリファイルを開いて、ハート形が見えるのを楽しんでいた

    • あの経験、DOS defrag の可視化、そしてセーブファイルを自分でヘックス編集していたことが、今自分が開発者になった理由のほとんどだ