- Microsoft Edit ist ein einfacher Texteditor, der dem klassischen MS-DOS Editor Tribut zollt
- Er bietet eine moderne Benutzeroberfläche und Eingabesteuerung ähnlich wie VS Code
- Das Entwicklungsziel ist es, eine Bearbeitungsumgebung bereitzustellen, die auch für Nutzer ohne Terminal-Erfahrung zugänglich ist
- Für die Funktion Search and Replace besteht eine optionale Abhängigkeit von der ICU-Bibliothek
- Enthält Hinweise zu klarer Benennung von ausführbaren Dateien und Umgebungsvariablen für Paketmanager
Überblick über das Open-Source-Projekt
- Microsoft Edit ist ein Texteditor im Stil klassischer Editoren für einfache Aufgaben
- Kennzeichnend ist eine moderne Neuinterpretation des MS-DOS Editors, kombiniert mit einer vertrauten UI und Eingabemethodik im VS Code-Stil
- Das Design legt besonderen Wert auf Einfachheit, damit auch Nutzer mit wenig Terminal-Erfahrung den Editor leicht verwenden können
Merkmale und Funktionen
- Mit minimaler Komplexität lassen sich grundlegende Textbearbeitungsaufgaben einfach erledigen
- Die Oberfläche wirkt vertraut und legt Wert auf Barrierefreiheit und Benutzerfreundlichkeit
- Über eine optionale Abhängigkeit von der ICU-Bibliothek (International Components for Unicode) wird die Funktion Search and Replace unterstützt
Hinweise für Paketmanager und Maintainer
Paketbenennung
- Der Standardname der ausführbaren Datei ist "edit", ein alternativer Name ist "msedit"
- Wegen möglicher Konflikte mit dem bestehenden Systembefehl "edit" wird eine alternative Benennung wie "msedit" empfohlen
- Von Namen wie "ms-edit" wird abgeraten
Benennung der ICU-Bibliothek (SONAME)
- Für die Funktion Search and Replace kann die ICU-Bibliothek verwendet werden
- Je nach Betriebssystem werden standardmäßig die folgenden Bibliotheken gesucht
- Windows:
icuuc.dll
- macOS:
libicuuc.dylib
- UNIX und andere:
libicuuc.so
- Falls sich der Bibliotheksname (SONAME) je nach Systemumgebung unterscheidet, kann er über verschiedene Umgebungsvariablen (
EDIT_CFG_ICUUC_SONAME, EDIT_CFG_ICUI18N_SONAME usw.) festgelegt werden
- Es werden zusätzliche Umgebungsvariablen für Fälle bereitgestellt, in denen sich die Namenskonventionen der ICU-Export-Symbole unterscheiden
Sonstiges
- Es gibt weitere Optionen wie automatische Erkennung von ICU-Umbenennungen und Unterstützung für C++-Symbole
- Zur Überprüfung dieser Einstellungen kann der Befehl
cargo test -- --ignored verwendet werden
Fazit
- Ein Open-Source-Editor, der Einfachheit und Zugänglichkeit betont und zugleich eine flexible Konfiguration der Umgebung ermöglicht
- Bietet Entwicklern, Open-Source-Mitwirkenden und Paketmanagern klare Richtlinien und hohe Kompatibilität
1 Kommentare
Hacker-News-Kommentare
Im Grunde ist es die Geschichte eines Projekts, das einfach nur aus „ich wollte das machen“ entstanden ist, und ich erinnere mich auch daran, wie ich viel über interne Funktionsweisen gelernt habe, indem ich auf diese Art Dinge gebaut habe. Aber eine mit FPC neu geschriebene Version von Turbo Vision, die für mehrere Ziele kompilieren kann, gibt es schon seit etwa 20 Jahren. Ich halte Turbo Vision für die beste Textmodus-Fensterbibliothek. Der eigentliche Spaß begann dabei, den gesamten Textbildschirm auf ein Array abzubilden. var Screen: Array[1..80,1..25] Of Byte Absolute $B800 So ähnlich war das, soweit ich mich erinnere. Das wirklich Revolutionäre an Turbo Vision waren verschiebbare (nicht-)modale Fenster. Am Ende lief es also darauf hinaus, dieses Array in einer Schleife ständig neu zu schreiben. Es war ziemlich schnell. Ich erinnere mich auch daran, mit dieser Bibliothek ganz gut Geld verdient zu haben.
Für Neugierige gibt es eine aktuelle C++-Version von Turbo Vision sowie einen Port mit Unicode-Unterstützung https://github.com/magiblot/tvision
TP-Arrays waren row-major organisiert. Ein Zeichen bestand aus 2 Byte (Zeichen + Attribut). Deshalb gab es sogar so etwas Bequemes wie
array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000. Bei monochromen Textdisplays musste man$B800nur auf$B000ändern. Zum Beispiel in Umgebungen wie Hercules.So eine Oberfläche in VSCode im Terminal zu haben, sogar remote, wäre wirklich großartig.
Mich würde interessieren, wie du mit dieser Bibliothek Geld verdient hast. Ein paar Geheimtipps wären nett.
Jedes Mal, wenn ich neue TUI-Frameworks sehe, denke ich immer nur: „Nicht mal so gut wie Turbo Vision“.
Andererseits wird unnötiger Ballast wie AI Copilot mit Gewalt in Notepad gestopft. Ich hatte Notepad immer als etwas in Erinnerung, dessen Kern darin bestand, ohne jeden Schnickschnack genau eine Sache richtig zu machen.
Auch das neue Edit ist von solchen Entscheidungen nicht frei. Unter Satya tut MS zwar so, als würde es FOSS mögen, aber in der Gates/Balmer-Ära war man meiner Erinnerung nach deutlich freundlicher zu Windows-Entwicklern. Heute ist alles ein Durcheinander aus Web- und Desktop-Frameworks, die intern nicht einmal besonders stark genutzt werden. Statt der alten VS-Wizards oder Plugins gibt es CLI-Tools, mit denen man dann Excel-Dateien dumpt. Das zeigt ziemlich deutlich, dass generationsübergreifend bei Windows-Entwicklungskultur und Management-Know-how etwas fehlt.
Raymond Chen hat einmal gesagt, dass Notepad überraschend oft für Tests verwendet wird. Es ist simpel, wird aber häufig für Experimente genutzt. https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795
Ich habe in Windows 11 im neuen Paint mal einen Screenshot eingefügt, und selbst minimiert hat es dauerhaft 5 % CPU gezogen und etwa 250 MB Speicher belegt. RAM ist das eine, aber so CPU zu verschwenden, finde ich schon grenzwertig. Früher gab es noch so etwas wie Stolz oder Qualitätskontrolle, habe ich den Eindruck.
Als mein ISP sporadische Ausfälle hatte (IPv4/MTU-Probleme), konnte ich in Notepad nicht einmal speichern. Es ging nur, wenn ich es zwangsweise beendet habe. Damals war ich gerade dabei, provisorisch einen Workaround über Wireguard einzurichten.
Wenn man das moderne Notepad deinstalliert, taucht selbst das alte Notepad bei der Suche im Startmenü nicht auf.
Ich meine, vor etwa einem Monat gehört zu haben, dass MS eine Linux-Distribution herausgebracht hat, die für Windows-Nutzer vertrauter sein soll. Soweit ich mich erinnere, war das einfach nur eine GNOME-Umgebung ohne besondere Merkmale. Stattdessen hätte MS auch eine eigene Linux-Distribution bauen können, in der bash durch powershell, Edit durch vim/nano usw. ersetzt wird, und .NET oder Visual Studio Code gleich als Standard-Entwicklungswerkzeuge enthalten sind … Wenn MS das als Standard-Distribution für WSL genutzt hätte, hätte man den Krieg vielleicht nicht gewonnen, aber den Nutzeranteil steigern können. Auch wenn MS den Kernel nicht kontrolliert, könnte es den Userland-Bereich dominieren. Viele Windows-Nutzer würden dann zwangsläufig ganz natürlich die vorinstallierten Tools von MS verwenden. Jetzt ist auch Microsoft Edit unter Linux verfügbar. Dasselbe gilt für andere Apps wie Powershell. Hätte man diese Strategie vor 10 Jahren verfolgt, könnte eine MS-Distribution heute vielleicht zu den Top 5 unter WSL gehören. Dass große Unternehmen (M$) ihren Einfluss bis auf meinen privaten PC ausdehnen können, fühlt sich ein wenig unangenehm an. Ich stelle mir am Ende nur vor, wie dieses Microsoft Edit irgendwann standardmäßig mit Co-Pilot ausgeliefert wird.
Ich denke, dass MS irgendwann zumindest in einigen Bereichen wie Windows Server oder Embedded Windows schrittweise in Richtung Linux gehen wird. Langfristig könnte sich sogar der Windows-Desktop allmählich verändern, sodass es Optionen wie „Windows Legacy“ vs. „Windows Linux Workstation“ gibt. Ich erwarte eine Entwicklung hin zu Linux-Kernel + getuntem Wine (WINE) + integrierter VM für bestimmte Legacy-Fälle. Das Problem ist, dass der NT-Kernel Linux in manchen Designelementen überlegen ist, etwa bei der Wiederherstellung nach vollständigen GPU-Treiberabstürzen. Aber Windows selbst wird zunehmend eher zur Last als zum Vermögenswert. Die eigentlichen Wachstumstreiber von MS sind Azure und Office 365, während Windows-Lizenzen praktisch stagnieren. Zumindest Linux-basierte Windows-Server und Workstations erscheinen denkbar.
Azure Linux (früher CBL-Mariner) ist die offizielle Linux-Distribution von MS für Container, VMs und Server. Das sollte man von einer bloßen Desktop-Umgebung oder einem Skin für normale Windows-Nutzer unterscheiden.
Es gab früher schon einmal eine Linux-/Unix-artige Distribution von MS namens „Xenix“, aber soweit ich weiß, war sie nicht besonders erfolgreich.
Der Hintergrund für WSL war, dass Entwickler in großen Unternehmen zunehmend Linux-Umgebungen brauchten. Der IT-Support kannte sich mit Linux oft nicht aus und wollte es auch nicht unbedingt unterstützen. WSL hat dieses Problem gelöst. Tatsächlich wollen viele Entwickler gar nicht wirklich Linux benutzen und sind auch mit dem Terminal nicht besonders vertraut. Sie verlassen sich auf GUI-Tools.
Dass MS insgeheim eine eigene Distribution pflegt, nur um das emotionale Bedürfnis von Windows-Nutzern zu bedienen, wirkt eher unrealistisch.
Diese Nachricht ist so heiß diskutiert, dass sie innerhalb einer Woche schon dreimal eingereicht wurde.
Ursprünglich war
edit.com(ab DOS 6.22, später 7.0/Windows 95) meine erste IDE. Angefangen habe ich mit qbasic, und das war fast das gleiche Programm wieedit.com. Als ich C/C++ mit djgpp lernte, habe ich weiteredit.combenutzt. Meine „Projektdatei“ ware.bat, mit der ich mehrere Dateien auf einmal öffnen konnte, etwaedit file1.cpp file2.cpp.... Andere Editoren waren beim Wechseln zwischen mehreren Dateien umständlich, aber hier gefiel mir, dass man mit alt-1,2,3... direkt umschalten konnte. Ich behalte diesen Stil bis heute bei, wenn ich Editor-Shortcuts ändere. Als Code-Editor war es zwar eher schwach. Kein Syntax-Highlighting und nur mäßige Unterstützung für Einrückungen, deshalb habe ich anfangs mit zwei Leerzeichen eingerückt, weil sich das manuell leichter machte. Trotzdem waren das unmittelbare Feedback auf geschriebenen Code und die Vertrautheit unschlagbar. Editoren wie qedit gab es auch, aber die waren nicht mein Fall, und Unix-artige Editoren fand ich unter DOS nicht besonders gut. Der neue Editor unterstützt zwar mehrere Buffer, aber offenbar nicht das Keybinding-Schema, an das ich gewöhnt bin.Das wäre ein guter Kandidat für ein Issue. Solches Feedback wird am Anfang oft tatsächlich berücksichtigt. Und es war wirklich nicht nur ähnlich, sondern
edit.comwar im Grunde qbasic mit einem zusätzlichen Flag beim Start. Ich habe qbasic selbst direkt mit diesem Flag verwendet. https://news.ycombinator.com/item?id=44037509Es gab zwar kein Syntax-Highlighting, aber eine Art automatische Großschreibung der Syntax, also etwa von reservierten Wörtern. Wenn man zum Beispiel eine ganze Zeile in Kleinbuchstaben eingab und Enter drückte, wurden die Schlüsselwörter automatisch großgeschrieben. Nichts Weltbewegendes, aber ziemlich praktisch.
Verglichen mit den Zeiten von
copy conwareditein echter Lebensretter.Es gibt vieles daran, das mir gefällt. Zunächst einmal: eine saubere Liste ohne Abhängigkeiten! Ich bin völlig begeistert. Ich kann kaum glauben, dass die komplette TUI nur für diesen einen Editor selbst gebaut wurde. Es gibt sogar Dialoge und einen Dateibrowser. Ich würde das gern auch in meinem eigenen Projekt einsetzen. Falls jemand vom Team hier ist: Mich würde interessieren, warum nicht Ratatui verwendet wurde. Die Codequalität ist wirklich herausragend. Mit einem Wort: Bravo!
Früher habe ich Leuten, die so einen Texteditor suchten, micro[1] empfohlen. Jetzt frage ich mich, was ich stattdessen empfehlen soll.
https://micro-editor.github.io/
Ich finde nicht, dass du deine Empfehlung ändern musst.
editunterstützt jedenfalls, soweit ich es ausprobiert habe, nicht einmal Syntax-Highlighting.Als ich zuletzt nachgesehen habe, war die Binärdatei so groß, dass man eher macro statt micro sagen müsste.
Es gibt auch dte[1] als Option. Sehr simpel, aber leistungsfähig, mit Unicode-Unterstützung, CUA-Keybindings usw. Ich bin damit als Ersatz für nano im Terminal sehr zufrieden. https://craigbarnes.gitlab.io/dte/
Unter Windows kann man es einfach mit
winget install zyedidia.microinstallieren. Es fühlt sich an wie ein Editor aus der alten 8-Bit-/16-Bit-Zeit.Mich würde wirklich interessieren, wie in einer großen Organisation wie MS so ein Projekt genehmigt wird. Ob das einfach ein Side-Project eines Entwicklers war, Teil einer Produkt-Roadmap oder ob es einen Prozess gab, die Führungsebene davon zu überzeugen.
Ein Texteditor ist ein sehr geeignetes Angriffsziel für Copilot-Integration.
Wie aus der Begründung hervorgeht, brauchte man einen Editor, der auf der Kommandozeile läuft (für Windows Core Server Installationen), auch über SSH nutzbar ist (seit einigen Jahren ist ein SSH-Server standardmäßig in Windows enthalten), und einen nicht-modalen Editor für Windows-Administratoren ohne vi-Erfahrung. Diese Anforderungen haben letztlich zu diesem Projekt geführt.
Teams müssen oft irgendwelche Kontingente erfüllen und bringen deshalb Ideen ein; manchmal geschieht es auf Anweisung der Führung (etwa zur Nutzung von copilot), manchmal wächst etwas aus einem Hackathon heraus. In Forschungsorganisationen kommt so etwas auch vor, wenn technische Mitarbeiter gerade Freiraum haben, oder nach langer Analyse, wenn endlich Budget freigegeben wird. Schon die Zahl der Committer deutet darauf hin, dass hier ziemlich strategisch investiert wurde. Das ist kein Projekt, das man mal eben über Nacht zusammenschustert.
Ich hoffe, dass irgendwann das alte EDLIN mit Unicode-Unterstützung zurückkommt. EDLIN konnte über Batch-Dateien per Pipe mit Tastatureingaben gefüttert werden, um bestimmte Aufgaben zu automatisieren. Es war gewissermaßen ein partieller Ersatz für sed oder awk. Ich denke, vi hat eine ähnliche Architektur, aber wie abwegig das ist, steht auf einem anderen Blatt.
ed. Mit der Option-sist es perfekt für Skripte.Verwandte Diskussion (271 Punkte, 185 Kommentare) https://news.ycombinator.com/item?id=44031529