Microsoft Edit

 (github.com/microsoft)
3 points par GN⁺ 2025-06-26 | 1 commentaires | Partager sur WhatsApp
  • Microsoft Edit est un éditeur de texte simple qui rend hommage au classique MS-DOS Editor
  • Il propose une interface moderne et des contrôles de saisie similaires à ceux de VS Code
  • Son objectif de développement est de fournir un environnement d’édition accessible même aux utilisateurs peu familiers avec le terminal
  • Il dispose d’une dépendance optionnelle à la bibliothèque ICU pour la fonction Search and Replace
  • Il inclut des indications sur un nommage clair des exécutables et des options de variables d’environnement pour les gestionnaires de paquets

Présentation du projet open source

  • Microsoft Edit est un éditeur de texte dans le style des éditeurs classiques pour les tâches simples
  • Il se distingue par une réinterprétation moderne de MS-DOS Editor, avec une interface conviviale et un mode de saisie inspirés de VS Code
  • Il a été conçu en mettant particulièrement l’accent sur une simplicité permettant même aux utilisateurs ayant peu d’expérience du terminal de l’utiliser facilement

Caractéristiques et fonctionnalités

  • Avec un minimum de complexité, il permet d’effectuer facilement les opérations de base d’édition de texte
  • L’interface offre une sensation familière et met l’accent sur l’accessibilité et la facilité d’utilisation
  • Il prend en charge la fonction Search and Replace via une dépendance optionnelle à la bibliothèque ICU (International Components for Unicode)

Points d’attention pour les gestionnaires de paquets et les responsables du packaging

Nommage des paquets

  • Le nom de l’exécutable par défaut est "edit", et le nom alternatif est "msedit"
  • En raison des conflits possibles avec la commande système existante "edit", il est recommandé d’utiliser un nom alternatif comme "msedit"
  • Il est recommandé d’éviter des noms comme "ms-edit"

Nommage de la bibliothèque ICU (SONAME)

  • La bibliothèque ICU peut être utilisée pour la fonction Search and Replace
  • Les bibliothèques recherchées par défaut selon l’OS sont les suivantes
    • Windows: icuuc.dll
    • macOS: libicuuc.dylib
    • UNIX et autres: libicuuc.so
  • Si le nom de la bibliothèque (SONAME) diffère selon l’environnement système, il peut être configuré via diverses variables d’environnement (EDIT_CFG_ICUUC_SONAME, EDIT_CFG_ICUI18N_SONAME, etc.)
  • Des variables d’environnement supplémentaires sont fournies pour les cas où les conventions de nommage des symboles exportés par ICU diffèrent

Divers

  • Des options supplémentaires sont disponibles, comme la détection automatique du renommage d’ICU et la prise en charge des symboles C++
  • Ces réglages peuvent être testés avec la commande cargo test -- --ignored

Conclusion

  • Un éditeur open source qui met l’accent sur la simplicité et l’accessibilité, tout en permettant une configuration d’environnement flexible
  • Il fournit des directives claires et une forte compatibilité pour les développeurs, contributeurs open source et gestionnaires de paquets

À lire aussi

1 commentaires

 
GN⁺ 2025-06-26
Avis sur Hacker News

  • C’est l’histoire d’un projet fait juste « parce que j’en avais envie », et ça me rappelle que j’ai moi aussi souvent construit des choses de cette façon pour comprendre leur fonctionnement interne. Mais une version qui réécrit Turbo Vision en FPC et compile pour plusieurs cibles existe déjà depuis une vingtaine d’années. Je pense que Turbo Vision est la meilleure bibliothèque de fenêtres en mode texte. Le vrai plaisir commence quand on mappe tout l’écran texte dans un tableau. var Screen: Array[1..80,1..25] Of Byte Absolute $B800 C’était un truc de ce genre, si je me souviens bien. Ce qui rendait Turbo Vision vraiment révolutionnaire, c’était ses fenêtres (non) modales déplaçables. En gros, on faisait juste tourner une boucle sur ce tableau pour le réécrire en permanence. C’était assez rapide. Je me souviens aussi avoir gagné pas mal d’argent avec cette bibliothèque

    • Pour les curieux, il existe une version moderne de Turbo Vision en C++, avec même un port qui prend en charge l’Unicode https://github.com/magiblot/tvision

    • Les tableaux de TP étaient en row-major. Chaque caractère occupait 2 octets (glyphe + attribut). On avait donc même des commodités du genre array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000. Sur un affichage texte monochrome, il suffisait de remplacer $B800 par $B000. Par exemple sur Hercules

    • Ce serait vraiment génial d’avoir ce genre d’interface dans le terminal de VSCode, même à distance

    • Je me demande comment il a gagné de l’argent avec cette bibliothèque. J’aimerais bien connaître le secret

    • À chaque fois que je vois sortir un nouveau framework TUI, j’ai toujours la même pensée : « c’est moins bien que Turbo Vision »

  • En parallèle, on force des mastodontes inutiles comme AI Copilot dans Notepad. Dans mon souvenir, l’essence même de Notepad, c’était de n’avoir aucune fonction superflue et de bien faire une seule chose

    • Le nouvel Edit n’échappe pas non plus à ce type de décisions. À l’époque de Satya, MS a fait semblant d’aimer le FOSS, mais dans mon souvenir, l’ère Gates/Ballmer était bien plus accueillante pour les développeurs Windows. Aujourd’hui, les frameworks web et desktop sont mélangés, au point d’être parfois à peine utilisés en interne. À la place des anciens assistants et plugins de VS, on se retrouve à dumper des fichiers Excel avec des outils CLI. Ça montre bien le manque de savoir-faire, aussi bien dans la culture de développement Windows entre générations qu’au niveau du management

    • Raymond Chen a déjà dit que Notepad servait étonnamment souvent pour les tests. C’est une application simple, mais souvent utilisée comme terrain d’expérimentation https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795

    • J’ai essayé de coller une capture d’écran dans le nouveau Paint de Windows 11, et même minimisé il continuait à prendre 5 % de CPU et environ 250 Mo de mémoire. Pour la RAM, passe encore, mais gaspiller autant de CPU, ça me semble excessif. J’ai le souvenir qu’il y avait autrefois une certaine fierté et un vrai contrôle qualité

    • Quand mon FAI avait des pannes intermittentes (problème IPv4/MTU), Notepad refusait même d’enregistrer. Je ne pouvais y arriver qu’en le fermant de force. À ce moment-là, j’étais justement en train de bricoler un contournement temporaire avec Wireguard

    • Si on supprime le notepad moderne, même l’ancien notepad n’apparaît plus quand on le cherche dans le menu Démarrer

  • Je me souviens avoir entendu il y a environ un mois que MS avait sorti une distribution Linux plus familière pour les utilisateurs Windows. De mémoire, c’était juste un environnement GNOME assez basique, sans rien de spécial. Pourtant, MS aurait pu créer sa propre distribution Linux, remplacer bash par powershell, vim/nano par Edit, et inclure .NET ou Visual Studio Code comme outils de développement par défaut… Si MS en avait fait la distribution par défaut de WSL, ils n’auraient peut-être pas gagné la guerre, mais ils auraient pu gagner des parts d’usage. Même sans contrôler le noyau, MS peut très bien dominer l’espace utilisateur (userland). Beaucoup d’utilisateurs Windows finiraient naturellement par utiliser les outils MS s’ils sont installés par défaut. Désormais, Microsoft Edit est lui aussi disponible sur Linux, tout comme Powershell et d’autres applications. Si cette stratégie avait été lancée il y a 10 ans, on peut imaginer qu’aujourd’hui une distribution MS figurerait peut-être dans le top 5 de WSL. L’idée que de grandes entreprises (M$) puissent étendre leur influence jusqu’à mon PC personnel me met un peu mal à l’aise. Au final, j’en viens à imaginer le jour où ce Microsoft Edit sera livré avec Co-Pilot par défaut

    • Un jour ou l’autre, je pense que MS finira au moins par migrer progressivement vers Linux sur certains segments, comme Windows Server ou Windows embarqué. À long terme, même le desktop Windows pourrait évoluer graduellement avec une option « Windows Legacy » vs « Windows Linux Workstation ». J’imagine une évolution vers un noyau Linux + un WINE optimisé + une VM intégrée pour certains usages legacy. Le problème, c’est que le noyau NT reste supérieur à Linux sur plusieurs points de conception (par exemple la capacité à récupérer après un crash complet des pilotes GPU). Mais Windows lui-même devient de plus en plus un fardeau plutôt qu’un actif. Les vrais moteurs de croissance de MS, ce sont Azure et Office 365, et les licences Windows stagnent presque. Au minimum, on peut envisager des serveurs et postes de travail Windows basés sur Linux

    • Azure Linux (ex-CBL-Mariner) est la distribution Linux officielle de MS pour les conteneurs, les VM et les serveurs. Il faut la distinguer d’un simple habillage ou environnement desktop destiné aux utilisateurs Windows classiques

    • Il me semble qu’il y avait autrefois une distribution Linux de MS appelée « Xenix », mais mes souvenirs sont qu’elle n’a pas eu beaucoup de succès

    • WSL est né parce que les développeurs des grandes entreprises avaient de plus en plus besoin d’un environnement Linux. Le support IT ne connaît généralement pas bien Linux, et n’a pas forcément envie de le prendre en charge. WSL a résolu ce problème. En pratique, beaucoup de développeurs ne veulent pas vraiment utiliser Linux et sont mal à l’aise avec le terminal. Ils dépendent des outils GUI

    • L’idée que MS maintienne en secret sa propre distribution juste pour flatter la sensibilité des utilisateurs Windows me paraît assez irréaliste

  • Cette actu est assez brûlante pour avoir été postée trois fois en une semaine

    1. Post de l’auteur - https://news.ycombinator.com/item?id=44034961
    2. Post officiel d’Ubuntu - https://news.ycombinator.com/item?id=44306892
    3. Et maintenant ce post

  • À l’origine, edit.com (à partir de DOS 6.22, puis 7.0/Windows 95) a été mon premier IDE. J’ai commencé avec qbasic, et c’était quasiment le même programme qu’edit.com. Même en apprenant le C/C++ avec djgpp, j’ai continué à utiliser edit.com. Mon « fichier de projet », c’était e.bat, qui me permettait d’ouvrir plusieurs fichiers d’un coup avec edit file1.cpp file2.cpp.... Les autres éditeurs géraient mal le passage d’un fichier à l’autre, alors que là je pouvais basculer directement avec alt-1,2,3... et j’adorais ça. D’ailleurs, encore aujourd’hui, quand je change les raccourcis clavier d’un éditeur, j’essaie toujours de conserver ce style. Bon, comme éditeur de code, ce n’était pas formidable. Il n’y avait pas de coloration syntaxique, et l’aide à l’indentation était médiocre (c’est pour ça qu’au début j’indentais avec deux espaces, c’était plus simple à faire à la main). Mais l’immédiateté du retour sur le code écrit et la familiarité étaient imbattables. Il y avait aussi des éditeurs comme qedit, mais ce n’était pas mon style ; et les éditeurs de la famille Unix me semblaient assez mauvais sous DOS. Ce nouvel éditeur prend bien en charge les multi-buffers, mais il ne semble pas reprendre le système de raccourcis auquel j’étais habitué

    • Ça vaudrait le coup d’ouvrir une issue. Ce genre de retour, quand il arrive tôt, est souvent réellement pris en compte. Et en fait, ce n’était pas juste un logiciel similaire : edit.com était littéralement qbasic lancé avec un flag supplémentaire. J’utilisais même parfois qbasic directement avec ce flag https://news.ycombinator.com/item?id=44037509

    • Il n’y avait pas de coloration syntaxique, mais il y avait la mise en majuscules de la syntaxe (par exemple les mots-clés réservés passaient automatiquement en majuscules). Même si on tapait toute une ligne en minuscules, les mots-clés passaient en majuscules au moment d’appuyer sur Entrée. Ce n’était pas grand-chose, mais c’était pratique

    • Comparé à l’époque de copy con, edit a vraiment été un sauveur

  • Il y a beaucoup de choses qui me plaisent là-dedans. D’abord, cette liste de dépendances propre, sans dépendance externe : j’adore. J’ai du mal à croire qu’ils aient développé tout le TUI eux-mêmes rien que pour cet éditeur. Il y a même des boîtes de dialogue et un navigateur de fichiers. J’aimerais bien appliquer ça à mon propre projet. S’il y a quelqu’un de l’équipe dans le coin, je serais curieux de savoir pourquoi ils n’ont pas utilisé Ratatui. La qualité du code est vraiment excellente. En un mot : Bravo !

  • Avant, je recommandais micro[1] aux gens qui cherchaient un éditeur de texte de ce type. Maintenant, je me demande quoi recommander

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

    • À mon avis, pas besoin de changer de recommandation. edit ne prend pas en charge la coloration syntaxique, du moins dans mon expérience

    • La dernière fois que j’ai vérifié, la taille du binaire était telle qu’on devrait plutôt l’appeler macro que micro

    • Il y a aussi l’option dte[1]. C’est très simple mais puissant, avec prise en charge de l’Unicode, des raccourcis CUA, etc. J’en suis satisfait comme éditeur terminal de remplacement pour nano https://craigbarnes.gitlab.io/dte/

    • Sous Windows, on peut l’installer simplement avec winget install zyedidia.micro. Ça rappelle les éditeurs de l’époque 8 bits / 16 bits

  • Je me demande vraiment comment un projet comme celui-ci est validé dans une grande organisation comme MS. Est-ce juste le side project d’un développeur, une partie de la roadmap produit, ou y a-t-il eu tout un travail de persuasion auprès du management ?

    • Un éditeur de texte est une cible parfaite pour une offensive d’intégration de copilot

    • Comme l’explique la justification, ils avaient besoin d’un éditeur fonctionnant en ligne de commande (pour les installations Windows Core Server), utilisable aussi en SSH (Windows embarque un serveur SSH par défaut depuis quelques années), et il fallait un éditeur non modal pour les administrateurs Windows sans expérience de vi. C’est ce type de besoins qui a mené à ce projet

    • Il arrive que chaque équipe doive remplir une forme de quota et proposer des idées ; parfois cela vient d’une consigne de la direction (comme l’usage de copilot), parfois ça démarre dans un hackathon avant de prendre de l’ampleur. Dans les structures de recherche, quand les profils techniques ont un peu de latitude, il peut sortir ce genre de projet ; et parfois il faut de longues analyses avant qu’un budget soit enfin accordé. Rien qu’au nombre de committers, ça ressemble à un investissement assez stratégique. Ce n’est pas un projet bricolé du jour au lendemain

  • J’aimerais voir revenir l’ancien EDLIN avec prise en charge de l’Unicode. On pouvait lui envoyer des frappes au clavier par pipe depuis un fichier batch pour automatiser certaines tâches. C’était une sorte de substitut partiel à sed ou awk. J’ai l’impression que vi a une architecture comparable, mais la question de savoir à quel point c’est aberrant est un autre débat

    • Je pense que ce que tu cherches, c’est plutôt ed. Avec l’option -s, c’est parfait pour les scripts

  • Discussion connexe (271 points, 185 commentaires) https://news.ycombinator.com/item?id=44031529