micro: la alternativa moderna a nano

 (micro-editor.github.io)
2 puntos por GN⁺ 2023-08-19 | 1 comentarios | Compartir por WhatsApp
  • micro es un editor de texto para la terminal que empieza con la simplicidad de nano, pero apunta a una interacción más moderna e intuitiva
  • Se distribuye como un binario estático sin dependencias, por lo que la instalación requiere poco esfuerzo, y ofrece tanto la descarga oficial de lanzamientos como instrucciones detalladas de instalación
  • Las opciones y combinaciones de teclas se cambian en formato JSON, y una expansión más profunda puede hacerse con configuración y plugins en Lua
  • Soporta resaltado de sintaxis para más de 75 lenguajes, 7 temas de color predeterminados, temas de 16/256/truecolor, múltiples cursores al estilo Sublime y control con mouse
  • Gracias a su emulador de terminal integrado, permite ejecutar un shell interactivo dentro del editor y ver código y bash al mismo tiempo en pantalla dividida

micro como editor de terminal

  • micro es un editor de texto basado en terminal que apuesta por una experiencia moderna e intuitiva
  • La versión más reciente puede descargarse en Download, y también se pueden consultar las instrucciones detalladas de instalación
  • Existe un script de terceros tipo pipe to shell con curl https://getmic.ro | bash, pero no está bajo el control de micro
  • Se distribuye como un binario estático sin dependencias para facilitar la instalación

  • Configuración y expansión

    • La configuración de opciones y la reasignación de teclas usan un formato simple en JSON
    • Si se necesita una configuración más potente, puede usarse Lua
    • Los plugins se escriben en Lua, y el administrador de plugins se encarga de la descarga e instalación automáticas

  • Funciones de edición

    • Soporta resaltado de sintaxis para más de 75 lenguajes
    • Ofrece 7 temas de color predeterminados
    • Se pueden usar temas de 16 colores, 256 colores y truecolor
    • Soporta múltiples cursores al estilo Sublime
    • Las combinaciones de teclas pueden cambiarse en bindings.json

  • Mouse y terminal integrada

    • Se puede seleccionar texto con clic y arrastre
    • El doble clic sirve para seleccionar por palabra, y el triple clic para seleccionar por línea
    • Se puede ejecutar un shell interactivo real dentro de micro
    • En pantalla dividida, se puede tener código de un lado y bash del otro
    • La lista completa de funciones puede verse en la lista de funciones de GitHub y en la ayuda en línea

Proyecto y comunidad

  • Los errores pueden reportarse en el rastreador de issues de GitHub, y también se pueden hacer preguntas o proponer nuevas funciones
  • Se aceptan pull requests
  • La discusión no oficial sobre el editor puede hacerse en el chat de Gitter
  • Enlaces relacionados:
  • Entre las reacciones de usuarios se menciona que es un editor que simplemente funciona, con soporte para mouse, y que puede usarse en lugar de nano o Vim

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-08-19
Comentarios en Hacker News

  • Cuando enseño programación en línea de comandos en clases donde todos son principiantes, les recomiendo nano a los estudiantes
    La mayor ventaja de nano para estos usuarios es que todos los comandos aparecen en la parte inferior de la pantalla, y me sorprendió que micro no tuviera eso

    • La diferencia entre micro y nano es que los atajos de teclado de nano son bastante particulares, mientras que micro sigue el esquema que usan la mayoría de las apps gráficas hoy en día, como Ctrl+S para guardar, Ctrl+F para buscar, Ctrl+Z para deshacer y Ctrl+Q para salir
      También hay una pista de que puedes ver los atajos con Alt+G y la ayuda con Ctrl+G
    • La intención de micro parece estar más cerca de un editor moderno y extensible que de un editor amigable para principiantes o ubicuo
      En ese sentido, sigue teniendo sentido recomendar nano a los estudiantes, y micro parece más adecuado para quienes aprendieron con nano y luego quieren más funciones o una mejor UI
    • Parece que al presionar Alt+G aparece la pantalla de atajos, y Ctrl+G abre la ayuda
      También parece haber una especie de modo de comentarios

  • Después de usar Emacs por más de 10 años, ahora uso micro como mi editor principal de código. Solo hago una excepción con vscode para escribir Coq
    Veo micro como un acme modernizado con concesiones, y tiene casi todas las funciones que soportan las ideas centrales de acme. Incluso escribí un plugin para aprovechar esa dirección: https://github.com/xxuejie/micro-acme
    Hasta ahora me ha funcionado perfectamente

    • Últimamente solo uso como el 1% de las funciones de Emacs, así que sigo probando editores ligeros de terminal como alternativa a Emacs, pero extraño mucho los major modes de Emacs más comunes, como los de C/C++, y sobre todo la forma en que manejan la indentación
      Ojalá otros editores también adoptaran la convención de forzar la indentación correcta con Tab
    • No conozco bien micro, así que pregunto si hay alguna razón por la que la velocidad de desarrollo se haya ralentizado en el último año o dos
      https://github.com/zyedidia/micro/tags
    • Yo también hice un cambio parecido, de Emacs a Acme, y en la terminal uso mg
      Ahora tengo Micro personalizado para que dé una sensación tipo Acme

  • No sabía que hubiera gente que usara nano como editor principal de código. Yo siempre lo uso en servidores *nix donde estoy trabajando, y probablemente lo he usado decenas de miles de veces
    Trabajé mucho tiempo como ingeniero de Linux/BSD, y en algunos lugares se negaban a instalar nano en los servidores. Hay administradores veteranos de Linux que no te dejan usar nada aparte de vi, y no lo entiendo. Es un paquete de 20 MB y su superficie de ataque tampoco es tan grande

    • Los veteranos al final se comportan como veteranos
      Siempre me da risa cuando le preguntas a alguien de una generación anterior qué sistema administraba y te lo cuenta como si fuera para presumir: que llevaba todo el departamento de TI del gobierno local de su zona, que era una zona bastante grande y que tenía al menos 500 usuarios
      Estoy 105% seguro de que ese sistema habrá sido el más seguro de todo el condado, pero al mismo tiempo también habrá sido un sistema inutilizable. Cuando esa persona se jubile o alguien en la oficina logre quitarla por pura desesperación, espero que la reemplace un ingeniero más moderno que, aunque no conozca vi, al menos se preocupe un poco por los usuarios. Claro, nosotros también somos ingenieros, así que tampoco nos importará tanto
    • La razón principal por la que un administrador Unix debe conocer vi a fondo es que es el mínimo común denominador en sistemas Unix y Linux
      Si trabajas como técnico de *nix, puede tocarte lidiar con sistemas como QNX, HP-UX, supercomputadoras SGI Altix o una Sun Ultra 2. Linux era más fácil porque tenía gestión de paquetes de software libre/de código abierto, y antes de que nano se popularizara también era común que Emacs viniera en la instalación base
      A veces había problemas con la terminal y había que trabajar viendo solo una línea, y en esos casos tenías que manejar vi a ciegas o usar sed/awk. Tal vez por eso sigue existiendo ese instinto KISS de hacer que todos aprendan vi. A mí también me enseñaron así
      Un editor por sí solo no crea una gran superficie de ataque, pero no descartaría la posibilidad de que un atacante abuse de la función de plugins como mecanismo de persistencia. Cuando se ejecuta como root seguramente funcione distinto, pero quizá no pase lo mismo con cuentas de servicio
    • Decir 20 MB no suena muy preciso: el ejecutable de nano pesa 277 KB y el paquete .deb completo también es de 860 KB
      https://packages.ubuntu.com/jammy/nano
    • Yo era usuario de nano, pero los veteranos me empujaron a usar vim y ahora solo toco nano cuando tengo que arreglar mi archivo vimrc
      En ese momento me molestó, pero ahora estoy contento con el cambio. Vim o vi están en todas partes, incluso en los switches y routers con los que trabajo. nano no está en todas partes, ni siempre se puede poner fácilmente en todas partes
      Si no te hubiera tocado entrar por SSH con regularidad a hardware viejo o con pocos recursos, supongo que esa ventaja se sentiría menos
    • Personalmente odio muchísimo nano, así que elegiría vi en cualquier momento
      Aun así, elegir editor de texto es algo muy personal. No tiene ningún sentido que alguien obligue a otra persona a usar o dejar de usar un editor específico. Simplemente hay que dejar que cada quien use el que le guste

  • JOE es bastante bueno: https://joe-editor.sourceforge.io/
    Es una mezcla de WordStar y Emacs, y si lo ejecutas con jstar ofrece una experiencia de WordStar bastante auténtica, conservando también cierta sensación del viejo Borland Turbo IDE

    • Me gustaba mucho JOE. Probablemente era por ese rastro de WordStar
      Incluso escribí un artículo sobre cómo seguir usando las teclas WordStar Diamond en Linux: https://benhoyt.com/writings/wordstar-diamond/
    • El primer procesador de texto que usé fue WordStar en CP/M, y mi primer entorno de programación fue Borland Turbo Pascal
      Más adelante también usé QEdit, que se podía configurar para usar las teclas de WordStar
      Cuando en los 90 pasé de DOS a Unix, me alegró descubrir JOE. Es el primer programa que instalo en una máquina nueva con Linux o *BSD, o en una VM
      Hoy en día JOE tiene resaltado de sintaxis y varias funciones buenas, así que nunca sentí la necesidad de volverme experto en vi o emacs
    • Tengo buenos recuerdos de haber usado casi exclusivamente joe en los 90 para todo excepto editar código
      Para editar código no era muy bueno, porque se parecía más a un modelo de procesador de texto, con carencias como ajuste automático de línea y falta de resaltado de sintaxis
      Pero para escribir documentos de texto era un editor pequeño y encantador
    • ¿Las diferencias entre modos y las combinaciones de teclas no están documentadas en el manual?
      Tal vez no supe encontrarlas, pero de verdad no las veo
    • Muchas veces lo ejecuto como jmacs para usar el conjunto de atajos de teclado de Emacs

  • Me gusta micro y lo uso todos los días
    Pero después de probar Helix, terminé queriendo una versión de micro con treesitter, LSP y ayuda contextual integrados. Helix resolvió muy bien ese paquete de funciones, pero el modelo de “modo único + comandos” y la memoria muscular de Ctrl-C/Ctrl-V me resultan demasiado cómodos como para cambiarme

    • Llevo unos 6 meses usando Helix a diario, y me encanta que sea un editor con todo incluido desde el inicio. Es un editor excelente

  • No entiendo por qué todavía hay software en internet que te dice que ejecutes sudo sobre algo que descargaste
    Si existe una opción más fácil, más segura, que ocupa menos espacio al instalarse y además viene integrada en todas las distribuciones, me cuesta entender por qué te hacen usar esos scripts
    Para comparar: el paquete de micro en Alpine ocupa 4 MB después de instalarse, mientras que el binario estático compilado que descargas de GitHub ocupa 11 MB. Me parece que usar el paquete del repositorio es más fiel al espíritu de micro

    • ¿De verdad te hace ejecutar sudo?
      En https://github.com/zyedidia/micro#quick-install-script veo que el script de instalación rápida es curl https://getmic.ro | bash, y el script deja el binario de micro en el directorio actual
      Después, si quieres, puedes moverlo a un directorio dentro del PATH, y ponen como ejemplo sudo mv micro /usr/bin. Solo te avisan que necesitas sudo si quieres moverlo a /usr/bin; no sé si ese es realmente el problema
    • Recomendar que hagas pipe de una fuente aleatoria de internet a sudo o a (ba)sh es completamente irresponsable
      Y ya cansa esa justificación ridícula de “todos lo hacen”
    • En lo personal, no quiero que haya un intermediario entre el desarrollador de la aplicación y yo
      Prefiero obtener la aplicación directamente del desarrollador. Así sé que estoy usando la versión con soporte oficial y puedo verificar que nadie haya modificado el código
      Si no puedo confiar en el desarrollador de la aplicación, simplemente no la instalo

  • Pensaba que Nano era la alternativa moderna a Pico

  • Me pregunto por qué habría interés en un editor pequeño así
    La única razón por la que uso vi/vim es porque está en todas partes. Si voy a instalar un editor, instalaría Emacs
    Si es un sistema remoto, con TRAMP abro archivos por SSH y conservo toda la potencia y velocidad de Emacs local. Para ediciones en la UI de terminal como sudoedit, git commit o C-x C-e, tengo Emacs corriendo como demonio, así que una nueva frame, incluso una frame de terminal, aparece al instante y se ve casi igual que la GUI de Emacs, incluyendo nerd font y colores; literalmente es Emacs
    No hace falta tener varios editores para distintos usos

    • Llevo más de 20 años usando Linux, pero nunca terminé de entender bien vi y no me parece intuitivo
      Emacs me resultó más atractivo y, cuando entro por ssh a dispositivos de baja potencia como un router con OpenWRT, como no hay Emacs uso Nano, que me parece el editor más intuitivo de los que están disponibles
      Sé que también podría usar Emacs y TRAMP, pero cada quien termina teniendo su propio flujo de trabajo. No es por menospreciar vi; es bien conocido que algunos hackers nunca llegan a sentirse cómodos con vi
    • No todo el mundo está interesado en un editor enorme y una curva de aprendizaje empinada
      Algunas personas solo quieren editar un archivo rápidamente
      Pueden usar lo que ya saben de Windows Notepad o Mac SimpleText, y además funciona incluso cuando solo tienes la consola Unix de una máquina averiada o de un servidor
    • No es que me interesen estos editores pequeños en sí
      Pero sí me interesan editores pequeños como nano. La razón está en este comentario raíz: https://news.ycombinator.com/item?id=37173126
      También vale la pena leer el primer párrafo aquí: https://linuxize.com/post/how-to-use-nano-text-editor/
      Para los administradores de sistemas de hoy que no crecieron con vi o vim ni eligieron el bando de emacs, incluir nano en una imagen de despliegue masivo es una decisión considerada
    • Todos los sistemas operativos con los que me topo tienen Nano
      Tampoco edito cosas remotamente con tanta frecuencia, y por lo general solo son archivos de configuración simples
      También probé micro y me gustó, pero no se abría al instante en una Pi, y no hago trabajos lo bastante grandes en un editor de línea de comandos como para necesitar sus funciones
    • Uso micro porque pude desarrollar plugins personalizados sin mucho esfuerzo y porque se puede desplegar fácilmente con solo copiarlo, incluso en sistemas que no tienen un editor de terminal decente
      Normalmente prefiero vim, pero el esfuerzo necesario para desplegar una configuración decente en el sistema de destino es demasiado grande

  • El problema que tuve con micro fue el pegado con formato
    Al pegar fragmentos de código, micro intentaba indentar cada línea, pero como no conocía el contexto completo, la indentación del texto pegado se iba profundizando cada vez más hasta el infinito
    Además se volvía tan lento intentando inferir el formato línea por línea que casi parecía congelarse. En vez de pegar y ver una escena tipo Matrix, uno terminaba yendo por un café
    Espero que ya lo hayan resuelto, pero me fui en ese momento. Si ya está solucionado, podría darle otra oportunidad

    • Se puede desactivar: Ctrl+E y luego set autoindent off
      https://github.com/zyedidia/micro/blob/master/runtime/help/o...
      Aun así, incluso estando activado, al pegar un bloque completo debería mantener la indentación correcta
      Si compartes tu configuración, entorno y ajuste, podría intentar hacer un parche
    • Me pasó una vez usándolo con Wezterm en Windows
      Depende de cómo pegues. No estoy 100% seguro de cómo funciona exactamente, pero parece que micro vuelve a implementar el pegado directamente con xclip, y no sé qué hará en Windows
      Si pegas con Ctrl+V, inserta de inmediato el contenido del portapapeles como bloque y conserva la indentación original. Si usas Ctrl+Shift+V, a veces parece procesarlo como si el terminal fuera enviando el portapapeles carácter por carácter y, al ver un retorno de carro sin conocer el siguiente carácter, agrega indentación extra y luego ingenuamente le suma unos tabs más

  • De las otras 14 publicaciones, la de 2020 tuvo 103 comentarios y la de 2021 tuvo 162
    [0]: https://news.ycombinator.com/item?id=23334190
    [1]: https://news.ycombinator.com/item?id=29128702