- Microsoft Edit es un editor de texto simple que rinde homenaje al clásico MS-DOS Editor
- Ofrece una interfaz moderna y controles de entrada similares a VS Code
- Su objetivo de desarrollo es ofrecer un entorno de edición accesible incluso para usuarios no familiarizados con la terminal
- Tiene una dependencia opcional de la biblioteca ICU para la función de Search and Replace
- Incluye orientación sobre nombres claros de ejecutables y opciones de variables de entorno para administradores de paquetes
Resumen del proyecto de código abierto
- Microsoft Edit es un editor de texto con estilo de editor clásico para tareas sencillas
- Se caracteriza por ser una reinterpretación moderna de MS-DOS Editor, aplicando una UI amigable y un método de entrada al estilo de VS Code
- Está diseñado con especial énfasis en la simplicidad para que incluso usuarios con poca experiencia en terminal puedan usarlo fácilmente
Características y funciones
- Con una complejidad mínima, permite realizar fácilmente tareas básicas de edición de texto
- La interfaz ofrece una sensación familiar y prioriza la accesibilidad y la facilidad de uso
- Depende opcionalmente de la biblioteca ICU (International Components for Unicode) para soportar la función de Search and Replace
Avisos para administradores de paquetes y encargados del empaquetado
Nombres de paquetes
- El nombre del ejecutable predeterminado es "edit" y el nombre alternativo es "msedit"
- Debido a posibles conflictos con el comando de sistema existente "edit", se recomienda usar nombres alternativos como "msedit"
- Se recomienda evitar nombres como "ms-edit"
Nombres de bibliotecas ICU (SONAME)
- Se puede usar la biblioteca ICU para la función de Search and Replace
- Las bibliotecas que se buscan por defecto según cada sistema operativo son las siguientes
- Windows:
icuuc.dll
- macOS:
libicuuc.dylib
- UNIX y otros:
libicuuc.so
- Si el nombre de la biblioteca (SONAME) varía según el entorno del sistema, puede configurarse mediante varias variables de entorno (
EDIT_CFG_ICUUC_SONAME, EDIT_CFG_ICUI18N_SONAME, etc.)
- También se proporcionan variables de entorno adicionales para los casos en que la convención de nombres de los símbolos exportados de ICU sea distinta
Otros
- Hay opciones adicionales como detección automática de renombrado de ICU y soporte para símbolos de C++
- Para validar esta configuración, se puede probar con el comando
cargo test -- --ignored
Conclusión
- Un editor de código abierto que prioriza la simplicidad y la accesibilidad, al mismo tiempo que permite una configuración flexible del entorno
- Ofrece lineamientos claros y alta compatibilidad para desarrolladores, contribuidores de código abierto y administradores de paquetes
1 comentarios
Comentarios en Hacker News
Es básicamente la historia de un proyecto hecho “solo porque quería hacerlo”, y yo también recuerdo haber construido cosas así para entender cómo funcionaban por dentro. Pero una versión que reescribe Turbo Vision en FPC y compila para varios objetivos ya existe desde hace unos 20 años. Creo que Turbo Vision es la mejor biblioteca de ventanas en modo texto. La verdadera diversión empieza en la parte donde mapeas toda la pantalla de texto como un arreglo. var Screen: Array[1..80,1..25] Of Byte Absolute $B800 Recuerdo que era algo así. Lo realmente innovador de Turbo Vision era que tenía ventanas (no) modales que se podían mover. O sea, al final se trataba de recorrer ese arreglo en un loop y reescribirlo constantemente. Era bastante rápido. Yo también recuerdo haber ganado bastante dinero con esa biblioteca
Para quien tenga curiosidad, existe una versión moderna de Turbo Vision para C++, y también un port con soporte Unicode https://github.com/magiblot/tvision
Los arreglos de TP eran row-major. Cada carácter ocupaba 2 bytes (letra + atributo). Así que incluso existía la comodidad de algo como array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000. En pantallas de texto monocromas bastaba cambiar $B800 por $B000. Por ejemplo, en entornos como Hercules
Estaría buenísimo que en VSCode una interfaz así funcionara en la terminal, incluso de forma remota
Me intriga cómo ganaste dinero con esa biblioteca. Ojalá compartieras el secreto
Cada vez que veo frameworks TUI nuevos, siempre pienso lo mismo: “siguen sin estar a la altura de Turbo Vision”
Por otro lado, están metiendo a la fuerza lastre innecesario como AI Copilot en Notepad. Según recuerdo, la esencia original de Notepad era precisamente hacer bien una sola cosa, sin funciones extra
El nuevo Edit tampoco se libra de ese tipo de decisiones. En la era Satya, MS ha fingido que le gusta el FOSS, pero recuerdo que en la época de Gates/Balmer era mucho más amable con los desarrolladores de Windows. Ahora hay una mezcla rara de frameworks web y de escritorio, y ni siquiera se usan bien internamente. En vez de los viejos asistentes y plugins de VS, ahora terminan usando herramientas CLI para volcar archivos de Excel y cosas así. Se nota mucho la falta de cultura de desarrollo para Windows entre generaciones, y también la falta de experiencia en la gestión
Raymond Chen comentó alguna vez que Notepad se usa sorprendentemente mucho para pruebas. La idea era que, aunque es simple, se usa seguido como herramienta experimental https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795
Probé pegar una captura de pantalla en el nuevo Paint de Windows 11, y aun minimizado seguía usando 5% de CPU y unos 250 MB de memoria. La RAM todavía se la puedo perdonar, pero desperdiciar CPU así ya me parece demasiado. Recuerdo que antes había cierto orgullo y control de calidad
Cuando mi ISP tenía fallas intermitentes (problemas de IPv4/MTU), ni siquiera podía guardar en Notepad. Solo podía hacerlo si lo cerraba a la fuerza. En ese momento estaba configurando un desvío temporal con Wireguard
Si borras el notepad moderno, el notepad viejo tampoco aparece al buscarlo en el menú Inicio
Recuerdo haber oído hace como un mes que MS había sacado una distribución de Linux más familiar para usuarios de Windows. Si no me falla la memoria, era básicamente un entorno GNOME sin nada especial. Más bien, si MS iba a hacer su propia distro Linux, podría haber reemplazado bash por powershell, Edit por vim/nano, e incluir .NET o Visual Studio Code como herramientas de desarrollo predeterminadas... Si MS hubiera usado eso como distro base de WSL, quizá no habría ganado la guerra, pero sí podría haber aumentado su cuota de usuarios. Aunque MS no controle el kernel, sí podría dominar el userland. Muchísimos usuarios de Windows terminarían usando de forma natural las herramientas de MS si vinieran instaladas por defecto. Ahora Microsoft Edit también se puede usar en Linux. Lo mismo pasa con otras apps como Powershell. Si hubieran seguido esa estrategia hace 10 años, hoy una distro de MS podría estar en el top 5 dentro de WSL. Me incomoda un poco pensar que corporaciones grandes como M$ puedan extender su influencia hasta mi PC personal. Ya me imagino el día en que este Microsoft Edit venga con Co-Pilot por defecto
Algún día creo que MS va a empezar a moverse gradualmente hacia Linux, al menos en ciertos ámbitos como Windows Server o Windows embebido. A largo plazo, hasta el escritorio de Windows podría ir cambiando poco a poco, con opciones tipo ‘Windows Legacy’ vs ‘Windows Linux Workstation’. Me imagino una evolución hacia kernel Linux + WINE afinado + una VM integrada para algunos legados. El problema es que el kernel NT tiene varias ventajas de diseño sobre Linux (por ejemplo, poder recuperarse de una caída total del driver de GPU). Pero Windows como producto se está volviendo cada vez más una carga que un activo. Al final, los verdaderos motores de crecimiento de MS son Azure y Office 365, y las licencias de Windows están casi estancadas. Como mínimo, sí veo posible un Windows Server y una workstation basados en Linux
Azure Linux (antes CBL-Mariner) es la distro oficial de Linux de MS para contenedores, VM y servidores. Hay que distinguirla de una simple skin o entorno de escritorio para usuarios de Windows
MS ya había tenido antes una distro llamada “Xenix”, pero recuerdo que no le fue muy bien
WSL nació porque dentro de las grandes empresas los desarrolladores necesitaban mucho un entorno Linux. El área de soporte IT no sabe mucho de Linux y tampoco tiene muchas ganas de dar soporte. WSL resolvió ese problema. En la práctica, muchos desarrolladores ni siquiera quieren usar Linux y además no se manejan bien en la terminal. Dependen de herramientas GUI
Es un poco poco realista pensar que MS mantendría por su cuenta una distro secreta solo para satisfacer la sensibilidad de los usuarios de Windows
Esta noticia ha dado tanto de qué hablar que la publicaron 3 veces en una semana
En su momento, edit.com (desde DOS 6.22, luego 7.0/Windows 95) fue mi primer IDE. Empecé con qbasic, y era prácticamente el mismo programa que edit.com. Incluso cuando aprendí C/C++ con djgpp seguí usando edit.com. Mi “archivo de proyecto” era e.bat, y podía abrir varios archivos de una sola vez con algo como edit file1.cpp file2.cpp... En otros editores cambiar entre múltiples archivos era incómodo, pero me encantaba poder saltar directo con alt-1,2,3... Todavía hoy, cuando cambio atajos de teclado de un editor, siempre conservo ese estilo. Aunque como editor de código era flojito. No tenía syntax highlighting y el soporte de indentación era pobre (por eso al principio usaba dos espacios, porque era más fácil hacerlo a mano). Aun así, la retroalimentación inmediata y la familiaridad que me daba al escribir código eran lo mejor. Había editores como qedit, pero no eran de mi gusto; los editores estilo Unix nunca me parecieron gran cosa en DOS. En este editor nuevo sí hay soporte multibuffer, pero parece que no adoptaron el estilo de key bindings al que yo estaba acostumbrado
Estaría bueno reportarlo como issue. Ese tipo de feedback, si se da temprano, muchas veces sí termina reflejándose. Y de hecho no era solo que se parecieran: edit.com era literalmente qbasic arrancado con un flag extra. Yo mismo llegué a usar qbasic así https://news.ycombinator.com/item?id=44037509
No había syntax highlighting, pero sí había capitalización de sintaxis (por ejemplo, convertir automáticamente las palabras reservadas a mayúsculas). Si escribías toda una línea en minúsculas, al dar Enter las reserved words cambiaban solas a mayúsculas. No era gran cosa, pero resultaba bastante cómodo
Comparado con la época de copy con, edit fue un verdadero salvavidas
Me gustaron muchas cosas en varios sentidos. Para empezar, ¡una lista limpia sin dependencias! Me encantó por completo. No puedo creer que hayan construido todo el TUI para este editor desde cero. Incluso tiene diálogos y explorador de archivos. Me gustaría aplicar algo así en mi propio proyecto. Si hay alguien del equipo por aquí, me gustaría saber por qué no usaron Ratatui. La calidad del código es impresionante. En una palabra: ¡Bravo!
Antes solía recomendar micro[1] a quien buscara un editor de texto de este tipo. Ahora no sé qué recomendar
https://micro-editor.github.io/
Yo no cambiaría la recomendación. edit, al menos por lo que probé, ni siquiera soporta syntax highlighting
La última vez que revisé, el archivo binario de micro era tan grande que más bien habría que llamarlo macro
También está la opción dte[1]. Tiene soporte Unicode, key bindings CUA y es muy simple pero potente. Lo uso contento como reemplazo de nano en terminal https://craigbarnes.gitlab.io/dte/
En Windows se puede instalar solo con
winget install zyedidia.micro. Tiene vibra de editor de la época de 8 y 16 bitsDe verdad me intriga cómo se aprueban proyectos así dentro de una organización grande como MS. No sé si fue solo un side project de algún desarrollador, parte del roadmap de producto, o si hubo todo un proceso para convencer al liderazgo
Un editor de texto es un blanco perfecto para meter integración con copilot
Como se puede ver en la explicación, hacía falta un editor que funcionara desde la línea de comandos (para instalaciones Windows Core Server), que también pudiera usarse por SSH (ya que desde hace unos años Windows trae servidor SSH integrado), y que además fuera no modal para administradores de Windows sin experiencia con vi. Esas necesidades fueron las que llevaron a este proyecto
A veces cada equipo tiene que proponer ideas para cumplir una cuota, a veces sale por indicación de liderazgo (como usar copilot), o empieza en un hackathon y luego escala. En organizaciones de investigación también pasan estas cosas cuando el personal técnico no está del todo ocupado, y en otros casos el presupuesto recién aparece después de un análisis largo. Con solo ver la cantidad de committers, parece haber sido una inversión bastante estratégica. No fue un proyecto improvisado de la noche a la mañana
Ojalá algún día salga una versión de EDLIN con soporte Unicode. EDLIN permitía automatizar ciertas tareas desde archivos por lotes mandándole pulsaciones por pipe. Era una especie de reemplazo parcial de sed o awk. Creo que vi también podría usarse con una arquitectura parecida, aunque qué tan aberrante sería ya es otro tema
Discusión relacionada (271 puntos, 185 comentarios) https://news.ycombinator.com/item?id=44031529