Microsoft Edit

 (github.com/microsoft)
3 puntos por GN⁺ 2025-06-26 | 1 comentarios | Compartir por WhatsApp
  • Microsoft Edit es un editor para necesidades de edición simples, que rinde homenaje al clásico MS-DOS Editor mientras ofrece una interfaz moderna y controles de entrada similares a VS Code
  • Su objetivo es ofrecer un editor accesible que incluso los usuarios no familiarizados con la terminal puedan usar fácilmente
  • En Windows se puede instalar con WinGet, en macOS con Homebrew, y en Linux con un script de instalación si la distribución no ofrece binarios o si se desea compilar manualmente
  • Está construido en Rust, y se recomienda una configuración con nightly Rust porque reduce considerablemente el tamaño del binario y mejora ligeramente el rendimiento
  • Se recomienda a los gestores de paquetes usar el nombre msedit en lugar de edit por posibles conflictos de nombres de ejecutables, y la configuración de la biblioteca ICU afecta la función de buscar y reemplazar

Propósito y carácter de Microsoft Edit

  • Edit es un editor simple cuyo objetivo es ser un “simple editor for simple needs”
  • Rinde homenaje al clásico MS-DOS Editor, pero ofrece una interfaz moderna y controles de entrada similares a VS Code
  • Apunta a ser un editor accesible que incluso los usuarios no familiarizados con la terminal puedan usar fácilmente

Cómo instalarlo

  • Los binarios pueden descargarse desde la página de Releases

  • Windows

    • La versión más reciente puede instalarse con WinGet
    winget install Microsoft.Edit

  • Linux

    • Si la distribución no ofrece binarios o se desea compilar manualmente, puede usarse el script de instalación
    • Los requisitos son Rust, un compilador de C, ICU, curl o wget, y tar
    • La instalación predeterminada instala msedit en ~/.local/bin
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh
    • Con flags adicionales, --dev compila directamente desde la rama main y --system instala en /usr/local/bin
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh -s -- --dev --system

  • macOS

    • La versión más reciente puede instalarse con Homebrew
    brew install msedit

Forma de compilación

  • Para compilar se necesita tener Rust instalado y clonar el repositorio
  • Si se usa nightly Rust, el build de release se hace con el siguiente comando 
    cargo build --release --config .cargo/release.toml
  • Si se usa stable Rust, se recomienda configurar la variable de entorno RUSTC_BOOTSTRAP=1 y seguir las instrucciones del build nightly
    • Este método reduce considerablemente el tamaño del binario y mejora ligeramente el rendimiento
  • Para compilar con stable Rust sin configuración adicional, se usa el siguiente comando 
    cargo build --release

Opciones de configuración de compilación

  • Durante la compilación, la configuración puede ajustarse mediante variables de entorno
  • EDIT_CFG_ICU* está relacionado con la configuración de los nombres de bibliotecas ICU, y se recomienda que los gestores de paquetes en Linux revisen esta opción
  • EDIT_CFG_LANGUAGES especifica, separada por comas, la lista de idiomas que se incluirán en la compilación

Avisos para gestores de paquetes

  • El nombre estándar del ejecutable es edit y el nombre alternativo es msedit
  • Como el nombre edit puede entrar en conflicto con comandos existentes, se recomienda usar msedit como nombre del paquete y del ejecutable
  • Deben evitarse nombres como ms-edit
  • Si es posible, se recomienda asignar un alias edit

Configuración relacionada con ICU

  • Este proyecto depende de forma opcional de la biblioteca ICU para la función de buscar y reemplazar
  • De forma predeterminada, busca los nombres de bibliotecas ICU según la plataforma
    • Windows: icuuc.dll, icuin.dll
    • macOS: libicucore.dylib
    • Linux y otros: libicuuc.so, libicui18n.so
  • Si el SONAME del entorno de instalación es distinto, hay que configurar variables de entorno durante la compilación
    • EDIT_CFG_ICUUC_SONAME: por ejemplo libicuuc.so.76
    • EDIT_CFG_ICUI18N_SONAME: por ejemplo libicui18n.so.76
  • Se asume por defecto que los símbolos de ICU se exportan en una forma como u_errorName, sin prefijo _ ni sufijo de versión
  • En entornos que usan otra forma de símbolos, pueden usarse variables de entorno adicionales
    • EDIT_CFG_ICU_CPP_EXPORTS=true: busca símbolos de C++ como _u_errorName, y en macOS viene activado por defecto
    • EDIT_CFG_ICU_RENAMING_VERSION=76: busca símbolos como u_errorName_76
  • Si se configura EDIT_CFG_ICU_RENAMING_AUTO_DETECT=true, el ejecutable intentará detectar en tiempo de ejecución el valor de renaming version
    • Como este método no cuenta con soporte oficial de ICU, se recomienda no depender de él
    • En UNIX, salvo macOS, viene activado por defecto cuando no hay otra opción
  • La prueba de la configuración de compilación se ejecuta agregando la flag --ignored a cargo test 
    cargo test -- --ignored

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-06-26
Opiniones en Hacker News

  • Hubo tanto interés que este artículo se publicó tres veces en una semana

    1. El propio autor - https://news.ycombinator.com/item?id=44034961
    2. Ubuntu Publication - https://news.ycombinator.com/item?id=44306892
      Y este artículo

  • Antes recomendaba micro para el público objetivo de este editor, y ahora me pregunto si debería cambiar

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

    • No parece necesario cambiar
      edit, al menos cuando lo probé de inmediato, ni siquiera traía resaltado de sintaxis por defecto
    • La última vez que lo revisé, micro, considerando solo el tamaño del binario, era tan grande que habría que llamarlo macro
    • También está dte. Es un editor muy ligero que apunta exactamente al mismo lugar, pero con más funciones, como soporte para Unicode y atajos CUA
      Lo uso como editor de terminal en lugar de nano
      [1]: https://craigbarnes.gitlab.io/dte/
    • Micro es un excelente editor para reemplazar algo como nano. Pero no creo que sea un buen sustituto de edit; edit es muy básico, mientras que micro es bastante extensible con Lua
      También maneja archivos grandes bastante bien
    • En Windows también se puede instalar simplemente con "winget install zyedidia.micro". Me recuerda a los editores de 8 y 16 bits de una época similar

  • De verdad me da curiosidad cómo se aprueba un proyecto así en una organización del tamaño de Microsoft. Me pregunto si es un proyecto paralelo de algunos desarrolladores o parte de la hoja de ruta de un producto
    ¿Cómo habrán convencido al liderazgo de dedicarle tiempo a esto?

    • Según la explicación, necesitaban un editor de texto de línea de comandos que funcionara en instalaciones de Windows Core Server
      Hace bastante que Windows incluye SSH Server, así que se puede administrar completamente solo con SSH, y hacía falta un editor sin modos que también pudieran usar administradores de Windows sin experiencia con vi
    • Un editor de texto es un candidato demasiado natural para la integración con Copilot
    • Cada grupo tiene que hacer algo y termina proponiendo ideas. A veces sale de una directriz del liderazgo como “usen Copilot”, y a veces una idea de eventos tipo hackerdayz se expande
      También hay casos en los que, dentro de una organización de investigación, personal técnico empieza algo con cierta holgura, y otros en los que reciben financiamiento tras análisis profundos y varios semestres
      Viendo la cantidad de colaboradores aquí, este proyecto probablemente fue una inversión estratégica. No salió de la noche a la mañana

  • El edit.com original de DOS 6.22 y luego 7.0, por la época de Win95, fue mi primer IDE. Empecé con qbasic y me acostumbré a una interfaz similar o idéntica, y seguí usando edit.com cuando aprendía C/C++ con djgpp
    Mi “archivo de proyecto” era e.bat, que contenía edit file1.cpp file2.cpp file3.cpp, y lo usaba porque tenía un soporte bastante decente para múltiples archivos, con cambios fáciles mediante Alt-1,2,3. Incluso ahora reasigno los atajos de mis editores a Alt/Cmd-1,2,3 para cambiar de archivo, y trato de mantener mi “conjunto activo” reducido a unos pocos archivos al frente
    No tenía resaltado de sintaxis y el comportamiento de indentación no era muy bueno, así que no era un gran editor de código. Por eso, al inicio de mi carrera usaba indentación de dos espacios, fácil de escribir a mano y que no se sentía como tabulaciones. Aun así, daba una sensación muy fuerte de estar en contacto directo con el código
    Sabía que mucha gente usaba editores como qedit, pero por alguna razón no me terminaban de encajar, y los editores de estilo Unix también se sentían raros en DOS
    Lo probé un momento y, aunque parece admitir varios búferes, no parece permitir cambiar entre búferes con los mismos atajos

    • Sería bueno abrir un issue para eso. Si estas cosas entran temprano, tienen posibilidades de incorporarse
      Y no era simplemente parecido, sino literalmente igual. EDIT.COM solo ejecutaba QBASIC con una bandera especial, y también se podía ejecutar QBASIC directamente con esa bandera. Como dije en https://news.ycombinator.com/item?id=44037509, lo hice de verdad por diversión
    • No tenía resaltado de sintaxis, pero, por falta de una expresión mejor, sí tenía capitalización de sintaxis
      Si escribías una línea completa en minúsculas y presionabas Enter, convertía automáticamente las palabras reservadas a mayúsculas. No era gran cosa, pero ayudaba
    • Después de la época de copy con, edit fue realmente una salvación

  • Me gustan muchas cosas. Para empezar, eso de que la lista de dependencias esté vacía ya me convenció
    Funciona muy bien. Me cuesta creer que hayan creado desde cero una TUI completa con explorador de archivos y cuadros de diálogo para esto. Me gustaría usarla en mis proyectos, pero me pregunto qué tan fácil sería. Si alguien del proyecto está aquí, también me da curiosidad por qué no usaron Ratatui
    La calidad del código también es de primer nivel, y solo puedo decir una cosa: ¡Bravo!

    • Salvo algunas dependencias de desarrollo que facilitan las pruebas, literalmente no tiene dependencias
      Si es algo que se distribuye como herramienta básica para administradores en un sistema operativo como Windows, es una elección razonable. Para más contexto sobre lo de “hacerlo uno mismo”, se puede ver la respuesta de lhecker
      [1]: https://news.ycombinator.com/threads?id=lhecker

  • Hace alrededor de un mes escuché que Microsoft tenía su propia distribución de Linux para que los usuarios de Windows se sintieran más familiarizados. Según recuerdo, era una configuración de GNOME bastante simple, así que no tenía nada especial.
    Me sorprende que Microsoft no haya aprovechado la oportunidad para crear una distribución de Linux propia, con PowerShell en lugar de bash, Edit junto con opciones como vim y nano, y .NET y Visual Studio Code incluidos en una instalación para desarrolladores.
    También podría haberla convertido en la instalación predeterminada de WSL. No habría ganado la guerra contra distribuciones típicas como Ubuntu o Debian, pero como hay muchos usuarios de Windows, podría haber conseguido cierta cuota y convertirse en una opción común.
    Microsoft no puede dominar el kernel de Linux, pero sí puede adueñarse del espacio de usuario. Vale la pena imaginar qué habría pasado si hubiera creado una corriente en la que sus aplicaciones vinieran instaladas por defecto en distribuciones populares.
    Microsoft Edit también se puede usar en Linux, al igual que PowerShell y otros. Si hace unos 10 años hubiera jugado bien sus cartas, su distribución quizá estaría hoy entre las 5 más usadas, gracias a la cantidad de usuarios de Windows que la usarían con WSL.
    Las grandes empresas pueden meter su huella en el espacio personal. Ahora solo falta que Co-Pilot venga activado por defecto en Microsoft Edit.

    • Creo que, con el tiempo, es muy probable que Microsoft migre a Linux. Al menos en Windows Server y Windows embebido; después, el escritorio de Windows podría cambiar gradualmente o dividirse en opciones como Windows Legacy y Windows “Linux Workstation”.
      Podría ser algo como poner una especie de “súper” WINE sobre el kernel de Linux y ofrecer, para ciertos programas, un Windows clásico en una máquina virtual estrechamente integrada como fallback.
      El problema, sin embargo, es que el kernel NT tiene muchas partes mejor diseñadas que el kernel de Linux. Por ejemplo, el kernel NT puede recuperarse incluso si el driver de la GPU muere por completo, mientras que Linux probablemente tendría bastantes dificultades en una situación así. Con otros drivers pasa algo parecido.
      Pero Windows se está convirtiendo cada vez más en un pasivo más que en un activo para Microsoft, especialmente en el área de servidores. Sus principales fuentes de ingresos son Azure y Office 365, que siguen creciendo a doble dígito, mientras que el crecimiento de las licencias de Windows está estancado.
      Como mínimo, creo que aparecerán versiones como un Windows Server basado en Linux y un Windows Workstation basado en Linux.
    • WSL existe porque los desarrolladores empresariales necesitaban una forma de ejecutar Linux.
      El personal de soporte de TI y soporte técnico por lo general no conoce bien Linux y tampoco quiere darle soporte. WSL resuelve ese problema.
      La mayoría de los desarrolladores no quiere usar Linux en sí. Muchos desarrolladores ni siquiera saben usar bien la terminal y dependen de herramientas con GUI.
    • Si sorprende que Microsoft no haya creado una distribución de Linux propia, su último intento no salió tan bien. Se llamaba Xenix.
    • Creo que el reconocimiento del nombre ayuda. Los desarrolladores no quieren instalar una distribución de la que nunca oyeron hablar, pero sí quieren instalar Ubuntu.
      Si WSL soporta Ubuntu, puede aprovechar ese reconocimiento.
    • Parece que estás confundiendo Azure Linux (antes CBL-Mariner), la distribución Linux de primera línea de Microsoft, con los skins de entornos de escritorio Linux que parecen Windows y que la gente lleva años creando.
      Azure Linux es un sistema operativo con soporte de Microsoft pensado para contenedores, VM, servidores y otros usos.

  • Esto se ve simplemente como un proyecto hecho “porque tenía ganas de hacerlo”. Lo entiendo, porque yo también he hecho muchas cosas así para entender qué estaba pasando.
    Pero reescribir Turbo Vision en FPC y compilarlo para varios targets es algo que existe desde hace 20 años. Turbo Vision probablemente sea la mejor biblioteca de ventanas en modo texto que existe.
    La parte interesante empieza cuando puedes mapear toda la pantalla de texto a un arreglo como este:
    var
    Screen: Array[1..80,1..25] Of Byte Absolute $B800; // or something like that as i recall
    Lo que aportó Turbo Vision fueron ventanas modales/no modales que se podían mover. Básicamente era una estructura que reescribía continuamente ese arreglo en un loop, y era bastante ágil. Gané muchísimo dinero con esa biblioteca.

    • Para quienes tengan curiosidad, existe un port moderno de Turbo Vision en C++ que también soporta Unicode:
      https://github.com/magiblot/tvision
    • Esto no es un proyecto hecho “porque tenía ganas de hacerlo”. Hacía falta un editor TUI pequeño, incluido en Windows y que también funcionara a través de SSH.
      https://news.ycombinator.com/item?id=44034961
    • Para ser exactos, es array[1..25, 1..80] of Word absolute $B800:0000.
      Los arreglos de TP se disponían en orden por filas, y cada carácter se representaba con dos bytes: uno para el carácter en sí y otro para los atributos (color de primer plano/fondo y parpadeo).
      Así que una forma mejor de usarlo sería array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000.
      En pantallas de texto monocromáticas como Hercules (modo 7), bastaba con cambiar $B800 por $B000.
    • Me da curiosidad cómo ganaste dinero con Turbo Vision. Si no te molesta, me gustaría que lo compartieras.
    • Cada vez que veo un nuevo framework TUI moderno, la decepción es la misma: “ah, esto no es tan bueno como Turbo Vision”.

  • Ahora estoy esperando EDLIN con soporte Unicode.
    Recuerdo que se podían scriptar ciertas tareas de edición canalizando pulsaciones de teclas por la entrada estándar desde un archivo batch. Se sentía como reemplazar parte de las funciones de sed o awk.
    No lo he probado, pero creo que con vi también se podría. Si eso es una forma extremadamente maldita o no, es otra cuestión.

    • Lo que buscas probablemente sea ed. Según el caso, se puede usar con -s.

  • Interesante. Sinceramente, no sé bien para quién lo hicieron, pero se ve interesante.

    • Es para gente que quiere editar archivos en Windows Terminal. El antiguo comando edit dejó de estar soportado en Windows desde 2006, así que desde entonces no había un editor provisto por Microsoft que se pudiera usar desde la línea de comandos.
      Es impresionante lo rápido que es este editor. https://github.com/microsoft/edit/pull/408

      Si se escribe una rutina SIMD especializada en buscar saltos de línea, se puede llevar [hasta 125GB/s]

    • Está escrito directamente en el README:

      El objetivo es ofrecer un editor accesible que sea fácil de usar incluso para usuarios que casi no están familiarizados con la terminal

    • Es una mejora mucho mayor que Notepad
    • Si tiene, o llega a tener, soporte para LSP o búsqueda basada en ripgrep, con gusto podría reemplazar a vim.
      Ahora uso Helix, pero me gusta una buena TUI
    • Es para gente como yo, que odia vi y busca algo más sensato para reemplazar nano en la terminal

  • En 1993 solía abrir archivos binarios con edit y disfrutar viendo que aparecían formas de corazón

    • Esa experiencia, la visualización del defrag de DOS y editar manualmente archivos de guardado en hexadecimal son prácticamente la razón por la que hoy soy desarrollador