- Microsoft Edit は、クラシックな MS-DOS Editor へのオマージュを込めた シンプルなテキストエディタ
- VS Code に似た モダンなインターフェース と入力コントロールを提供
- 開発目標は、ターミナルに不慣れなユーザーでも使いやすい編集環境 を提供すること
- Search and Replace 機能のために、ICU ライブラリへのオプション依存を持つ
- パッケージ管理者向けの明確な実行ファイル命名と環境変数オプション の案内を含む
オープンソースプロジェクト概要
- Microsoft Edit は、簡単な作業向けのクラシックエディタ風テキストエディタ
- MS-DOS Editor を現代的に再解釈 したことが特徴で、VS Code スタイルの親しみやすい UI と入力方式を採用
- 特に、ターミナル利用経験が少ないユーザーでも簡単に使えるシンプルさ を重視して設計されている
特徴と機能
- 複雑さを最小限に抑えつつ、基本的なテキスト編集作業を手軽に実行 できる
- インターフェースは親しみやすさを提供し、アクセシビリティと使いやすさ を重視
- ICU (International Components for Unicode) ライブラリ にオプションで依存し、Search and Replace 機能をサポート
パッケージマネージャーおよびパッケージング担当者向けの注意事項
パッケージ命名
- デフォルトの実行ファイル名は "edit"、代替名は "msedit"
- 既存のシステムコマンド "edit" との競合を避けるため、"msedit" などの代替命名を推奨
- "ms-edit" のような名前は避けることを推奨
ICU ライブラリ命名 (SONAME)
- Search and Replace 機能のために ICU ライブラリを使用可能
- 各 OS でデフォルトで探すライブラリは以下の通り
- Windows:
icuuc.dll
- macOS:
libicuuc.dylib
- UNIX およびその他:
libicuuc.so
- システム環境によりライブラリ名 (SONAME) が異なる場合は、各種環境変数 (
EDIT_CFG_ICUUC_SONAME, EDIT_CFG_ICUI18N_SONAME など) で設定可能
- ICU export symbol の命名規則 が異なる場合に備えた追加の環境変数も提供
その他
- ICU リネーミングの自動検出、C++ シンボル対応などの追加オプションがある
- これらの設定検証には
cargo test -- --ignored コマンドでテスト可能
結論
- シンプルさとアクセシビリティを重視しつつ、柔軟な環境構成が可能な オープンソースエディタ
- 開発者、オープンソース貢献者、パッケージ管理者 に明確なガイドラインと高い互換性を提供
1件のコメント
Hacker Newsの反応
これは単に「自分が作りたかったから」作ったプロジェクトという話だが、自分もそういう形で何かを作りながら内部の仕組みを理解した経験をたくさんしてきた記憶がある。ただ、Turbo VisionをFPCで書き直し、複数のターゲット向けにコンパイルできる版は、もう20年くらい前から存在している。Turbo Visionは最高のテキストモード・ウィンドウライブラリだと思う。本当の面白さは、画面全体のテキスト表示を配列にマッピングするところから始まる。 var Screen: Array[1..80,1..25] Of Byte Absolute $B800 たしかこんな感じだった。Turbo Visionが本当に革新的だったのは、移動可能なモーダル／非モーダルウィンドウだった点だ。つまり結局はその配列をループしながら絶えず書き戻していたわけだ。かなり速かった。自分もそのライブラリでかなりの収益を上げた記憶がある
興味のある人向けに、最近のC++版Turbo Visionと、Unicode対応までしている移植版がある https://github.com/magiblot/tvision
TPの配列はrow-majorだった。文字1つは2バイト（文字+属性）で構成されていた。だから
array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000みたいな便利さまであった。モノクロのテキストディスプレイなら$B800を$B000に変えればよかった。たとえばHerculesのような環境だVSCodeでああいうインターフェースがターミナルで、しかもリモートでも使えたら本当にいいと思う
どうやってそのライブラリでお金を稼いだのか気になる。秘訣を教えてほしい
最近出てくるTUIフレームワークを見るたびにいつも思うのは、「Turbo Visionに及ばないな」という物足りなさだ
一方で、AI Copilotのような不要な肥大化をNotepadに無理やり押し込んでいる。もともとのNotepadの本質は、余計な機能なしに『ひとつのこと』をきちんとやることだった記憶がある
新しいEditもこうした判断から自由ではない。Satya時代のMSはFOSSを好んでいるふりをしていたが、Gates/Balmer時代のほうがずっとWindows開発者に親切だった記憶がある。今はWeb/デスクトップのフレームワークが入り混じり、社内ですらあまり使われていない。昔のVSウィザードやプラグインの代わりに、CLIツールでExcelファイルをダンプするような感じだ。世代をまたいだWindows開発文化や、管理層のノウハウ不足がよく表れている
Raymond Chenが、Notepadは意外と多くのテストに使われていると言っていたことがある。シンプルな機能だが、実験用としてよく使われるという話だ https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795
Windows 11の新しいPaintでスクリーンショットを貼り付けてみたが、最小化した状態でもCPUを5%使い続け、メモリも250MBほど占有していた。RAMはまだしも、CPUをここまで浪費するのはどうかと思う。昔は誇りや品質管理というものがあった記憶がある
ISPで断続的な障害（IPv4/MTUの問題）が起きていたとき、Notepadでは保存すらできなかった。強制終了しないとダメだった。そのときはWireguardで一時的な迂回設定をしていたところだった
モダン版notepadを削除すると、スタートメニューで昔のnotepadを検索しても出てこない
1か月ほど前、MSがWindowsユーザーにより親しみやすいLinuxディストリビューションを出したという話を聞いた記憶がある。記憶では単純なGNOME環境で、特別な点はなかった。むしろMSが独自のLinuxディストリビューションを作るなら、bashをpowershellに、Editをvim/nanoなどの代わりにし、.NETやVisual Studio Codeも標準の開発ツールとして含められたはずだ。MSがこれをWSLのデフォルトディストリビューションとして活用していたなら、戦争に勝てなくても、ユーザーシェアは伸ばせたかもしれない。MSはカーネルまで支配できなくても、ユーザー空間（userland）の支配は可能だ。多くのWindowsユーザーに、標準インストールのアプリとしてMSのツールを自然に使わせることができる。今やMicrosoft EditもLinuxで使える。Powershellのように、ほかのアプリも同様だ。もし10年前にこうした戦略を取っていたら、今日のWSLでMSのディストリビューションが上位5位に入っていたかもしれないと想像する。大企業（M$）が個人のPCにまで影響力を伸ばせるという点では少し不快でもある。結局のところ、このMicrosoft EditにもCo-Pilotが標準搭載される日を想像してしまう
いずれMSは、少なくともWindows Serverや組み込みWindowsのような一部領域からLinux側へ徐々に移行していくと思う。長期的にはWindowsデスクトップも段階的に変わり、『Windows Legacy』と『Windows Linux Workstation』のような選択肢が出てくるのではないか。Linuxカーネル + 調整済みのWINE + 一部レガシー向けの統合VM、という形に進化すると予想している。問題は、NTカーネルには設計上Linuxより優れている点が多いことだ（たとえばGPUドライバ全体がクラッシュした後でも復旧できるなど）。しかしWindows自体は、ますます資産より負担になりつつある。実際、MSの成長エンジンはAzure & Office 365であり、Windowsライセンスはほぼ横ばいだ。少なくともLinuxベースのWindowsサーバーとワークステーションは期待できる
Azure Linux（旧CBL-Mariner）は、コンテナ、VM、サーバー用途向けに作られたMS公式Linuxディストリビューションだ。単なるWindowsユーザー向けスキンやデスクトップ環境とは区別する必要がある
MSが昔作ったLinuxディストリビューションの名前として「Xenix」があったが、あまり成績は良くなかった記憶がある
WSLが生まれた背景には、大企業内の開発者がLinux環境を必要とする度合いが高かったことがある。ITサポート側はLinuxに詳しくなく、わざわざサポートしたがらない。WSLはこうした問題を解決する。実際、多くの開発者はLinuxを使いたいわけではなく、ターミナルにも不慣れなことが多い。GUIツールに依存している
MSがWindowsユーザーの感覚を満たすために、独自の秘密ディストリビューションを維持しているというのはやや非現実的だ
この話題は、1週間のあいだに3回も投稿されるほど注目されている
もともとの
edit.com（DOS 6.22から、その後7.0/Windows 95でも）は、自分にとって最初のIDEだった。始まりはqbasicで、edit.comとほぼ同じプログラムだった。C/C++をdjgppで学んでいたときも、ずっとedit.comを使っていた。自分の「プロジェクトファイル」はe.batで、edit file1.cpp file2.cpp...のように複数ファイルを一度に開けた。他のエディタは複数ファイルの切り替えが不便だったが、alt-1,2,3...ですぐ切り替えられるのが気に入っていた。今でもエディタのショートカットを変えるときは、このスタイルを必ず残す。もちろんコードエディタとしてはあまり優秀ではなかった。シンタックスハイライトもなく、インデント支援も弱かった（だから最初はインデントを2スペースにしていて、手でやるのも楽だった）。それでも、書いたコードへの即時フィードバックと慣れ親しんだ感覚は最高だった。qeditのようなエディタもあったが自分の好みではなく、Unix系エディタはDOSではいまひとつだと思っていた。今回の新しいeditorはマルチバッファ対応ではあるが、自分が慣れているキーバインド方式は採用していないようだissueとして提起するといいと思う。こういうフィードバックは初期に伝えると実際に反映されることが多い。それに本当に、単に似たレベルというだけではなく、
edit.comはqbasicにフラグを1つ追加して起動したのとまったく同じだった。実際、自分でqbasicにそのフラグを付けて使っていた https://news.ycombinator.com/item?id=44037509シンタックスハイライトはなかったが、構文の大文字化（たとえば予約語を自動で大文字に変換する機能）はあった。たとえば1行をすべて小文字で入力しても、Enterを押すと予約語が自動で大文字になった。大したことではないが、かなり便利だった
copy conの時代と比べれば、editは本当に救世主だったさまざまな面で気に入った点が多い。まず、依存関係のないクリーンなリストがいい。完全に惚れた。TUI全体をこのエディタのために自前で作ったというのが信じられない。ダイアログもファイルブラウザもある。自分のプロジェクトにも取り入れてみたい。もし関係者がいるなら、なぜRatatuiを使わなかったのか気になる。コード品質がとにかく素晴らしい。一言で言えば、Bravo!
昔はmicro[1]を、こういうテキストエディタを探している人によく勧めていた。これからは何を勧めるべきか悩む
https://micro-editor.github.io/
自分は、勧めるものを変える必要はないと思う。editは（少なくとも自分が試した限りでは）シンタックスハイライトすら対応していない
最後に確認したとき、microはmicroというよりmacroと呼ぶべきなくらいバイナリサイズが大きかった
dte[1]という選択肢もある。Unicode対応、CUAキーバインドなど、とてもシンプルでありながら強力だ。nanoの代替となるターミナルエディタとして満足している https://craigbarnes.gitlab.io/dte/
Windowsでは
winget install zyedidia.microだけでインストールできる。昔の8ビット/16ビット時代のエディタっぽさがあるMSのような大きな組織で、こうしたプロジェクトがどうやって承認されるのか本当に気になる。単なる開発者のサイドプロジェクトなのか、製品ロードマップの一部なのか、それともリーダーシップを説得するプロセスがあったのか知りたい
テキストエディタはcopilot統合の攻撃目標として非常に適している
説明の理由から分かるように、コマンドラインで動くエディタが必要だった（Windows Core Serverのインストール向け）。SSHで接続して使う必要もあったし（Windowsには数年前からSSHサーバーが標準搭載されている）、vi経験のないWindows管理者向けに、モード切り替えのないエディタが求められていた。こうした要件が今回のプロジェクトにつながった
各チームが何らかのノルマを埋めるためにアイデアを出したり、ときにはリーダーの指示で（copilot利用など）、あるいはハッカソンのようなイベントから始まって拡大したりすることもある。研究組織で技術者が手を空けているとこういうものが出てくることもあるし、長い分析の末にようやく予算が付くこともある。コミッター数を見ても、かなり戦略的な投資だったように思える。一夜にして急ごしらえで出てきたプロジェクトではない
昔のEDLINがUnicode対応で出てきてくれたらいいのにと思う。EDLINは、バッチファイルからキー入力をパイプで流し込む形で特定の作業を自動化できた。sedやawkの一部代替のようなものだった。viも似たアーキテクチャだと思うが、それがどれだけ異常かはまた別の話だ
edだ。-sオプションを付ければスクリプトにぴったりだ関連議論（271ポイント、185コメント） https://news.ycombinator.com/item?id=44031529