Microsoft Edit

 (github.com/microsoft)
3 Punkte von GN⁺ 2025-06-26 | 1 Kommentare | Auf WhatsApp teilen
  • Microsoft Edit ist ein Editor für einfache Bearbeitungsanforderungen, der dem klassischen MS-DOS Editor Respekt zollt und zugleich eine moderne Oberfläche sowie Eingabesteuerung ähnlich wie VS Code bietet
  • Ziel ist es, einen leicht zugänglichen Editor bereitzustellen, den auch Nutzer ohne viel Terminal-Erfahrung einfach verwenden können
  • Unter Windows lässt er sich über WinGet, unter macOS über Homebrew und unter Linux per Installationsskript installieren, wenn die Distribution keine Binärdatei bereitstellt oder man selbst bauen möchte
  • Er wird in Rust gebaut; die Konfiguration mit nightly Rust wird empfohlen, da sie die Binärgröße deutlich reduziert und die Performance leicht verbessert
  • Paketmanagern wird wegen möglicher Namenskollisionen bei ausführbaren Dateien der Name msedit statt edit empfohlen; die ICU-Bibliothekskonfiguration beeinflusst die Suchen/Ersetzen-Funktion

Zweck und Charakter von Microsoft Edit

  • Edit ist ein einfacher Editor mit dem Ziel „simple editor for simple needs“
  • Er zollt dem klassischen MS-DOS Editor Respekt, bietet aber eine moderne Oberfläche und eine Eingabesteuerung ähnlich wie VS Code
  • Er soll ein zugänglicher Editor sein, den auch Nutzer ohne viel Terminal-Erfahrung einfach verwenden können

Installation

  • Binärdateien können von der Releases page heruntergeladen werden

  • Windows

    • Die neueste Version kann mit WinGet installiert werden
    winget install Microsoft.Edit

  • Linux

    • Wenn die Distribution keine Binärdatei bereitstellt oder man selbst bauen möchte, kann das Installationsskript verwendet werden
    • Voraussetzungen sind Rust, ein C-Compiler, ICU, curl oder wget sowie tar
    • Die Standardinstallation installiert msedit nach ~/.local/bin
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh
    • Mit zusätzlichen Flags baut --dev direkt aus dem main-Branch, und --system installiert nach /usr/local/bin
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh -s -- --dev --system

  • macOS

    • Die neueste Version kann mit Homebrew installiert werden
    brew install msedit

Build-Verfahren

  • Für den Build sind eine Rust-Installation und ein Klon des Repositorys erforderlich
  • Bei Verwendung von nightly Rust erfolgt der Release-Build mit folgendem Befehl 
    cargo build --release --config .cargo/release.toml
  • Bei Verwendung von stable Rust wird empfohlen, die Umgebungsvariable RUSTC_BOOTSTRAP=1 zu setzen und den Anweisungen für den nightly-Build zu folgen
    • Dieser Ansatz reduziert die Binärgröße deutlich und verbessert die Performance leicht
  • Für einen Build mit stable Rust ohne zusätzliche Konfiguration wird folgender Befehl verwendet 
    cargo build --release

Optionen für die Build-Konfiguration

  • Beim Build kann die Konfiguration über Umgebungsvariablen angepasst werden
  • EDIT_CFG_ICU* bezieht sich auf die Konfiguration der ICU-Bibliotheksnamen; Linux-Paketmanagern wird empfohlen, diese Option zu prüfen
  • EDIT_CFG_LANGUAGES gibt die Liste der in den Build aufzunehmenden Sprachen kommasepariert an

Hinweise für Paketmanager

  • Der Standardname der ausführbaren Datei ist edit, der alternative Name ist msedit
  • Da der Name edit mit bestehenden Befehlen kollidieren kann, werden für Paket und ausführbare Datei der Name msedit empfohlen
  • Namen wie ms-edit sollten vermieden werden
  • Wenn möglich, wird empfohlen, einen Alias edit zuzuweisen

ICU-bezogene Konfiguration

  • Dieses Projekt hängt optional von der ICU-Bibliothek für die Suchen- und Ersetzen-Funktion ab
  • Standardmäßig werden die plattformspezifischen ICU-Bibliotheksnamen gesucht
    • Windows: icuuc.dll, icuin.dll
    • macOS: libicucore.dylib
    • Linux und andere: libicuuc.so, libicui18n.so
  • Wenn die SONAMEs der Installationsumgebung abweichen, müssen beim Build Umgebungsvariablen gesetzt werden
    • EDIT_CFG_ICUUC_SONAME: z. B. libicuuc.so.76
    • EDIT_CFG_ICUI18N_SONAME: z. B. libicui18n.so.76
  • Es wird angenommen, dass ICU-Symbole standardmäßig ohne _-Präfix und ohne Versionssuffix exportiert werden, etwa in der Form u_errorName
  • In Umgebungen mit anderen Symbolformen können zusätzliche Umgebungsvariablen verwendet werden
    • EDIT_CFG_ICU_CPP_EXPORTS=true: sucht nach C++-Symbolen wie _u_errorName; unter macOS standardmäßig aktiviert
    • EDIT_CFG_ICU_RENAMING_VERSION=76: sucht nach Symbolen wie u_errorName_76
  • Wenn EDIT_CFG_ICU_RENAMING_AUTO_DETECT=true gesetzt ist, versucht die ausführbare Datei zur Laufzeit, den Wert der renaming version zu erkennen
    • Da dieses Verfahren von ICU nicht offiziell unterstützt wird, wird empfohlen, sich nicht darauf zu verlassen
    • Unter UNIX ist es mit Ausnahme von macOS standardmäßig aktiviert, wenn es keine andere Option gibt
  • Tests der Build-Konfiguration werden mit cargo test und dem Flag --ignored ausgeführt 
    cargo test -- --ignored

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-26
Meinungen auf Hacker News

  • Das Interesse war so groß, dass dieser Beitrag dreimal in einer Woche auftauchte

    1. Der Autor selbst – https://news.ycombinator.com/item?id=44034961
    2. Ubuntu Publication – https://news.ycombinator.com/item?id=44306892
      und nun dieser Beitrag

  • Früher habe ich für die Zielgruppe dieses Editors micro empfohlen; jetzt frage ich mich, ob ich das ändern sollte

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

    • Sieht nicht so aus, als müsste man wechseln
      edit unterstützte zumindest beim direkten Ausprobieren nicht einmal standardmäßig Syntax-Highlighting
    • Als ich zuletzt nachgesehen habe, hätte man micro allein der Binärgröße nach eher macro nennen müssen
    • Es gibt auch dte. Das ist ein sehr leichter Editor, der genau auf denselben Punkt zielt, aber mehr Funktionen wie Unicode-Unterstützung und CUA-Keybindings bietet
      Ich nutze ihn als Terminal-Editor statt nano
      [1]: https://craigbarnes.gitlab.io/dte/
    • Micro ist ein hervorragender Editor als Ersatz für etwas wie nano. Als Ersatz für edit scheint er mir allerdings weniger geeignet; edit ist sehr grundlegend, während micro über Lua ziemlich erweiterbar ist
      Auch mit großen Dateien kommt er recht gut zurecht
    • Unter Windows lässt er sich ebenfalls einfach mit "winget install zyedidia.micro" installieren. Er erinnert an 8-Bit- und 16-Bit-Editoren aus einer ähnlichen Ära

  • Ich frage mich wirklich, wie ein solches Projekt in einer Organisation von der Größe Microsofts genehmigt wird. Ist das ein Nebenprojekt einiger Entwickler oder Teil einer Produkt-Roadmap?
    Wie haben sie die Führung davon überzeugt, Zeit dafür aufzuwenden?

    • Der Beschreibung nach brauchte man einen Kommandozeilen-Texteditor, der in Windows-Core-Server-Installationen funktioniert
      Windows enthält schon seit einiger Zeit einen SSH Server, sodass man es vollständig nur per SSH verwalten kann; dafür brauchte es einen modeless Editor, den auch Windows-Administratoren ohne vi-Erfahrung nutzen können
    • Ein Texteditor ist ein geradezu naheliegendes Ziel für Copilot-Integration
    • Jede Gruppe muss irgendetwas tun und entwickelt Ideen. Manchmal entsteht das aus einer Führungsrichtung wie „Nutzt Copilot“, manchmal wachsen Ideen aus Veranstaltungen wie hackerdayz weiter
      In Forschungsorganisationen beginnen technische Leute mit etwas Freiraum damit, oder es erhält nach gründlicher Analyse und mehreren Halbjahreszyklen Finanzierung
      Wenn man sich die Zahl der Beitragenden hier ansieht, war dieses Projekt vermutlich eher eine strategische Investition. Es ist nicht über Nacht entstanden

  • Das ursprüngliche edit.com aus DOS 6.22 und später 7.0, also zur Win95-Zeit, war meine erste IDE. Ich hatte mit qbasic angefangen und war an eine ähnliche oder identische Oberfläche gewöhnt; auch als ich mit djgpp C/C++ lernte, nutzte ich weiter edit.com
    Meine „Projektdatei“ war e.bat mit edit file1.cpp file2.cpp file3.cpp, und ich nutzte es, weil es eine ziemlich ordentliche Mehrdatei-Unterstützung gab, bei der man mit Alt-1,2,3 einfach wechseln konnte. Auch heute remappe ich Editor-Keybindings noch so, dass Alt/Cmd-1,2,3 zwischen Dateien wechseln, und versuche, mein „aktives Set“ auf ein paar Dateien am Anfang klein zu halten
    Es gab kein Syntax-Highlighting und das Einrückungsverhalten war auch nicht besonders gut, also war es kein großartiger Code-Editor. Deshalb nutzte ich früh in meiner Karriere eine Einrückung mit zwei Leerzeichen, die sich leicht von Hand tippen ließ und nicht wie Tabs wirkte. Trotzdem fühlte es sich stark so an, als sei man direkt am Code
    Ich wusste, dass viele andere Editoren wie qedit nutzten, aber aus irgendeinem Grund passten sie nicht zu mir, und Unix-artige Editoren fühlten sich unter DOS unbeholfen an
    Nach kurzem Ausprobieren scheint er zwar mehrere Buffer zu unterstützen, aber der Wechsel zwischen Buffern scheint nicht mit denselben Keybindings zu funktionieren

    • So etwas sollte man besser als Issue einreichen. Solche Dinge haben früh eine Chance, berücksichtigt zu werden
      Und es war nicht nur ähnlich, sondern buchstäblich identisch. EDIT.COM startete lediglich QBASIC mit einem speziellen Flag, und man konnte QBASIC mit diesem Flag auch direkt ausführen. Wie unter https://news.ycombinator.com/item?id=44037509 erwähnt, habe ich das aus Spaß tatsächlich gemacht
    • Syntax-Highlighting gab es nicht, aber mangels eines besseren Ausdrucks gab es so etwas wie Syntax-Großschreibung
      Wenn man eine ganze Zeile in Kleinbuchstaben eingab und Enter drückte, wurden reservierte Wörter automatisch in Großbuchstaben umgewandelt. Nicht spektakulär, aber hilfreich
    • Nach der Zeit von copy con war edit wirklich ein Retter

  • Mir gefällt vieles daran. Allein dass die Abhängigkeitsliste leer ist, hat mich schon überzeugt
    Es funktioniert sehr gut. Kaum zu glauben, dass sie für dieses Projekt eine komplette TUI inklusive Dateibrowser und Dialogen gebaut haben. Ich würde sie gern auch in meinen Projekten nutzen und frage mich, wie einfach das wäre. Falls jemand aus dem Projekt hier ist, würde mich auch interessieren, warum sie nicht Ratatui verwendet haben
    Auch die Codequalität ist erstklassig, und ich kann nur sagen: Bravo!

    • Abgesehen von einigen Entwicklungsabhängigkeiten, die Tests erleichtern, gibt es buchstäblich keine Abhängigkeiten
      Für ein Tool, das als Standardwerkzeug für Administratoren auf einem Betriebssystem wie Windows ausgeliefert wird, ist das eine nachvollziehbare Entscheidung. Mehr Hintergrund zum Thema „selbst bauen“ findet man in den Antworten von lhecker
      [1]: https://news.ycombinator.com/threads?id=lhecker

  • Vor etwa einem Monat habe ich gehört, dass Microsoft eine eigene Linux-Distribution hat, damit sich Windows-Nutzer vertrauter fühlen. Soweit ich mich erinnere, war das eine ziemlich schlichte GNOME-Konfiguration, also nichts Besonderes.
    Ich finde es überraschend, dass Microsoft die Gelegenheit nicht genutzt hat, eine eigene Linux-Distribution zu bauen, mit PowerShell statt bash, mit Edit neben Optionen wie vim und nano, und mit .NET sowie Visual Studio Code in der Entwicklerinstallation.
    Man hätte das auch zur Standardinstallation für WSL machen können. Im Kampf gegen typische Distributionen wie Ubuntu oder Debian hätte sie wohl nicht gewonnen, aber da es viele Windows-Nutzer gibt, hätte sie einen gewissen Anteil erreichen und zu einer gängigen Option werden können.
    Microsoft kann den Linux-Kernel nicht kontrollieren, aber den Userspace schon. Man kann sich vorstellen, was passiert wäre, wenn sich ein Trend etabliert hätte, bei dem die eigenen Anwendungen standardmäßig in beliebten Distributionen installiert sind.
    Microsoft Edit lässt sich ebenso wie PowerShell auch unter Linux nutzen. Hätte Microsoft vor etwa zehn Jahren die Karten gut ausgespielt, könnte ihre Distribution heute vielleicht in den Top 5 liegen, weil viele Windows-Nutzer sie über WSL verwenden.
    Großkonzerne können ihre Spuren in persönliche Bereiche hineindrücken. Jetzt muss nur noch Co-Pilot in Microsoft Edit standardmäßig aktiviert werden.

    • Ich halte es für ziemlich wahrscheinlich, dass Microsoft mit der Zeit zu Linux wechseln wird. Zumindest bei Windows Server und Embedded Windows, und später könnte sich auch der Windows-Desktop schrittweise verändern oder in Optionen wie Windows Legacy und Windows „Linux Workstation“ aufteilen.
      Denkbar wäre eine Art „Super“-WINE auf dem Linux-Kernel, mit einem eng integrierten klassischen Windows in einer virtuellen Maschine als Fallback für bestimmte Programme.
      Das Problem ist allerdings, dass der NT-Kernel in vielen Aspekten des Designs besser ist als der Linux-Kernel. Zum Beispiel kann sich der NT-Kernel erholen, selbst wenn ein GPU-Treiber komplett abstürzt; Linux dürfte mit so einer Situation ziemlich zu kämpfen haben. Bei anderen Treibern ist es ähnlich.
      Aber Windows wird für Microsoft zunehmend eher zur Last als zum Vermögenswert, besonders im Serverbereich. Die wichtigsten Umsatzquellen sind Azure und Office 365, die weiterhin zweistellig wachsen, während das Wachstum bei Windows-Lizenzen stagniert.
      Zumindest Versionen wie ein Linux-basiertes Windows Server und eine Linux-basierte Windows Workstation werden meiner Ansicht nach kommen.
    • WSL existiert, weil Entwickler in Unternehmen eine Möglichkeit brauchten, Linux auszuführen.
      IT-Support und technischer Support kennen sich meist nicht gut mit Linux aus und wollen es auch nicht unterstützen. WSL löst dieses Problem.
      Die meisten Entwickler wollen gar nicht Linux selbst verwenden. Viele Entwickler wissen nicht einmal richtig, wie man ein Terminal benutzt, und verlassen sich auf GUI-Tools.
    • Wenn es überraschend ist, dass Microsoft keine eigene Linux-Distribution gebaut hat: Der letzte Versuch lief nicht besonders gut. Er hieß Xenix.
    • Ich denke, Markenbekanntheit hilft. Entwickler wollen keine Distribution installieren, von der sie noch nie gehört haben, aber Ubuntu installieren sie gern.
      Wenn WSL Ubuntu unterstützt, kann es diese Bekanntheit nutzen.
    • Es sieht so aus, als würdest du Microsofts primäre Linux-Distribution Azure Linux (früher CBL-Mariner) mit Linux-Desktop-Environment-Skins verwechseln, die wie Windows aussehen und die Leute schon seit Langem bauen.
      Azure Linux ist ein von Microsoft unterstütztes Betriebssystem für Container, VMs, Server usw.

  • Das wirkt einfach wie ein Projekt, das jemand „machen wollte, um es auszuprobieren“. Ich verstehe das, weil ich viele solche Dinge gemacht habe, um zu begreifen, was da passiert.
    Aber Turbo Vision in FPC neu zu schreiben und für mehrere Targets zu kompilieren, gibt es schon seit 20 Jahren. Turbo Vision ist wahrscheinlich die beste Textmodus-Windowing-Bibliothek, die es gibt.
    Interessant wird es, wenn man den gesamten Textbildschirm auf ein solches Array abbilden kann:
    var
    Screen: Array[1..80,1..25] Of Byte Absolute $B800; // or something like that as i recall
    Turbo Vision brachte verschiebbare modale und nichtmodale Fenster. Im Grunde wurde dieses Array in einer Schleife immer wieder neu geschrieben, und das war ziemlich flott. Mit dieser Bibliothek habe ich eine Menge Geld verdient.

    • Für alle, die neugierig sind: Es gibt einen modernen C++-Port von Turbo Vision, der auch Unicode unterstützt:
      https://github.com/magiblot/tvision
    • Das ist kein Projekt, das jemand „machen wollte, um es auszuprobieren“. Man brauchte einen kleinen TUI-Editor, der in Windows enthalten ist und auch über SSH funktioniert.
      https://news.ycombinator.com/item?id=44034961
    • Genau genommen ist es array[1..25, 1..80] of Word absolute $B800:0000.
      Die Arrays von TP waren zeilenweise angeordnet, und jedes Zeichen wurde durch zwei Bytes dargestellt: eines für das Zeichen selbst, das andere für die Attribute (Vorder-/Hintergrundfarbe und Blinken).
      Besser wäre also array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000.
      Bei monochromen Textdisplays wie Hercules (Modus 7) musste man $B800 durch $B000 ersetzen.
    • Ich bin neugierig, wie du mit Turbo Vision Geld verdient hast. Wenn es dir nichts ausmacht, würde ich mich freuen, wenn du das erzählst.
    • Jedes Mal, wenn ich ein neues modernes TUI-Framework sehe, ist die Enttäuschung dieselbe: „Ach, das ist nicht so gut wie Turbo Vision.“

  • Ich warte jetzt auf EDLIN mit Unicode-Unterstützung.
    Ich erinnere mich, dass man in Batch-Dateien Tastendrücke über die Standardeingabe hineinpipe konnte, um bestimmte Bearbeitungsvorgänge zu skripten. Es fühlte sich an, als würde es einen Teil der Funktionen von sed oder awk ersetzen.
    Ich habe es nicht ausprobiert, aber mit vi dürfte das wahrscheinlich auch gehen. Ob das nun eine völlig verfluchte Vorgehensweise ist oder nicht, ist eine andere Frage.

    • Was du suchst, ist vermutlich ed. Je nach Fall zusammen mit -s.

  • Interessant. Ehrlich gesagt weiß ich nicht genau, für wen das gedacht ist, aber es sieht spannend aus.

    • Es ist für Leute, die im Windows Terminal Dateien bearbeiten wollen. Der alte edit-Befehl wird unter Windows seit 2006 nicht mehr unterstützt, daher gab es seitdem keinen von Microsoft bereitgestellten Editor für die Kommandozeile.
      Beeindruckend, wie schnell dieser Editor ist. https://github.com/microsoft/edit/pull/408

      Wenn man eine auf die Suche nach Zeilenumbrüchen spezialisierte SIMD-Routine schreibt, lässt sich das [auf bis zu 125 GB/s] steigern

    • Steht direkt im README:

      Ziel ist es, einen zugänglichen Editor bereitzustellen, der auch für Nutzer leicht zu bedienen ist, die mit dem Terminal kaum vertraut sind

    • Ein deutlich größerer Fortschritt als Notepad
    • Wenn es LSP-Unterstützung oder eine auf ripgrep basierende Suche gibt bzw. geben wird, könnte ich damit gern vim ersetzen.
      Im Moment nutze ich Helix, aber eine gute TUI gefällt mir.
    • Das ist für Leute wie mich gedacht, die vi nicht mögen und im Terminal nach etwas Vernünftigerem als Ersatz für nano suchen.

  • 1993 habe ich gern mit edit Binärdateien geöffnet und mich daran erfreut, Herzsymbole zu sehen.

    • Diese Erfahrung, die Visualisierung von DOS defrag und das direkte Hex-Editieren von Savegames sind so ziemlich der Grund, warum ich heute Entwickler bin.