micro, une alternative moderne à nano

 (micro-editor.github.io)
2 points par GN⁺ 2023-08-19 | 1 commentaires | Partager sur WhatsApp
  • micro est un éditeur de texte pour terminal, conçu pour démarrer avec la simplicité de nano tout en visant une utilisation plus moderne et intuitive
  • Distribué sous forme de binaire statique sans dépendances, il est facile à installer, avec téléchargement des versions officielles et guide d’installation détaillé
  • Les options et raccourcis clavier se modifient au format JSON, tandis que les extensions plus poussées passent par la configuration et les plugins en Lua
  • Il prend en charge la coloration syntaxique de plus de 75 langages, 7 thèmes de couleurs par défaut, des thèmes 16/256/truecolor, le multi-cursor façon Sublime et la souris
  • Grâce à son émulateur de terminal intégré, il permet d’exécuter un shell interactif dans l’éditeur et d’afficher côte à côte le code et bash en écran partagé

micro comme éditeur de terminal

  • micro est un éditeur de texte en terminal qui met en avant une utilisation moderne et intuitive
  • La dernière version est disponible sur Download, et un guide d’installation détaillé est également proposé
  • Il existe un script tiers de type pipe to shell via curl https://getmic.ro | bash, mais il n’est pas sous le contrôle de micro
  • Pour faciliter l’installation, il est distribué sous forme de binaire statique sans dépendances

  • Configuration et extensions

    • Les options et la réaffectation des touches utilisent un format JSON simple
    • Si une configuration plus avancée est nécessaire, il est possible d’utiliser Lua
    • Les plugins sont écrits en Lua, et le gestionnaire de plugins s’occupe automatiquement du téléchargement et de l’installation

  • Fonctions d’édition

    • Prend en charge la coloration syntaxique de plus de 75 langages
    • Fournit 7 thèmes de couleurs par défaut
    • Permet d’utiliser des thèmes 16 couleurs, 256 couleurs et truecolor
    • Prend en charge le multi-cursor façon Sublime
    • Les raccourcis clavier peuvent être modifiés dans bindings.json

  • Souris et terminal intégré

    • Le texte peut être sélectionné par clic et glisser-déposer
    • Le double-clic sert à sélectionner un mot, le triple-clic une ligne entière
    • Il est possible d’exécuter un véritable shell interactif dans micro
    • En écran partagé, on peut afficher le code d’un côté et bash de l’autre
    • La liste complète des fonctionnalités est disponible dans la liste des fonctionnalités GitHub et l’aide en ligne

Projet et communauté

  • Les bugs peuvent être signalés via l’issue tracker GitHub, qui permet aussi de poser des questions ou de proposer de nouvelles fonctionnalités
  • Les pull requests sont acceptées
  • Les discussions informelles sur l’éditeur peuvent avoir lieu sur le chat Gitter
  • Liens associés :
  • Les retours des utilisateurs mentionnent notamment un éditeur qui fonctionne simplement, la prise en charge de la souris et le fait qu’il peut remplacer nano ou Vim

À lire aussi

1 commentaires

 
GN⁺ 2023-08-19
Avis sur Hacker News

  • Quand j’enseigne la programmation en ligne de commande dans un cours où tout le monde débute, je recommande nano aux étudiants.
    Pour ces utilisateurs, le principal avantage de nano est que toutes les commandes sont affichées en bas de l’écran ; j’ai été surpris de voir que micro n’a pas cela.

    • La différence entre micro et nano, c’est que les raccourcis clavier de nano sont assez spécifiques, tandis que micro suit les conventions de la plupart des applications graphiques modernes : Ctrl+S pour enregistrer, Ctrl+F pour rechercher, Ctrl+Z pour annuler, Ctrl+Q pour quitter, etc.
      En bas de l’écran, il y a aussi une indication disant qu’Alt+G permet de voir les raccourcis, et Ctrl+G d’afficher l’aide.
    • L’intention de micro semble moins être d’être un éditeur adapté aux débutants ou disponible partout que d’être un éditeur moderne et extensible.
      De ce point de vue, il reste pertinent de recommander nano aux étudiants, tandis que micro semble convenir à ceux qui, après avoir appris avec nano, veulent davantage de fonctionnalités ou une meilleure UI.
    • Il semble qu’Alt+G affiche l’écran des raccourcis, et que Ctrl+G ouvre l’aide.
      Il y a aussi apparemment une sorte de mode commentaire.

  • Après avoir utilisé Emacs pendant plus de 10 ans, j’utilise maintenant micro comme éditeur de code principal. La seule exception est vscode pour écrire du Coq.
    Je vois micro comme un acme modernisé avec des compromis : il dispose de presque toutes les fonctionnalités qui prennent en charge les idées centrales d’acme. J’ai aussi écrit un plugin pour exploiter cette direction : https://github.com/xxuejie/micro-acme
    Jusqu’ici, cela me convient parfaitement.

    • Ces temps-ci, je n’utilise plus qu’environ 1 % des fonctionnalités d’Emacs, donc je continue d’essayer des éditeurs de terminal légers comme alternatives à Emacs, mais les modes majeurs d’Emacs courants pour C/C++ et autres me manquent beaucoup, surtout leur manière de gérer l’indentation.
      J’aimerais que d’autres éditeurs reprennent la convention consistant à forcer la bonne indentation avec la touche Tab.
    • Je connais mal micro, donc je me demande s’il y a une raison pour laquelle la vitesse de développement semble avoir ralenti au cours des un ou deux dernières années.
      https://github.com/zyedidia/micro/tags
    • De manière similaire, je suis passé d’Emacs à Acme, et j’utilise mg dans le terminal.
      J’ai maintenant personnalisé Micro pour lui donner une sensation à la Acme.

  • Je ne savais pas qu’il y avait des gens qui utilisaient nano comme éditeur de code principal. Je l’utilise toujours sur les serveurs *nix sur lesquels je travaille, et je l’ai sans doute utilisé des dizaines de milliers de fois.
    J’ai longtemps travaillé comme ingénieur Linux/BSD, et certains endroits refusaient d’installer nano sur les serveurs. Il y a des administrateurs Linux vétérans qui ne laissent absolument rien utiliser d’autre que vi, et je ne comprends pas. C’est un paquet de 20 Mo, et sa surface d’attaque n’est pas si grande.

    • Un vétéran finit toujours par se comporter comme un vétéran.
      Quand on demande aux gens de l’ancienne génération quel système ils administraient, il leur arrive de se vanter en disant qu’ils géraient tout le département IT de leur collectivité locale, dans une ville assez grande avec au moins 500 utilisateurs, et cela me fait toujours rire.
      Je suis sûr à 105 % que ce système était le plus sécurisé de tout le comté, mais qu’en même temps c’était un système inutilisable. Quand cette personne prendra sa retraite, ou quand quelqu’un au bureau finira par s’en débarrasser par désespoir, j’espère qu’elle sera remplacée par un ingénieur moderne qui, même s’il ne connaît pas vi, se soucie un peu des utilisateurs. Bien sûr, nous sommes aussi des ingénieurs, donc nous ne nous en soucierons pas tant que ça.
    • La principale raison pour laquelle un administrateur Unix doit connaître vi sur le bout des doigts, c’est que c’est le plus petit dénominateur commun sur les systèmes Unix et Linux.
      Quand on travaille comme technicien *nix, on peut devoir gérer des systèmes comme QNX, HP-UX, un supercalculateur SGI Altix ou un Sun Ultra 2. Linux était plus facile grâce à la gestion de paquets de logiciels libres/open source, et avant que nano ne devienne populaire, il était aussi courant qu’Emacs soit inclus dans la configuration par défaut.
      Il arrivait aussi que des problèmes de terminal obligent à travailler avec seulement une ligne visible ; il fallait alors manipuler vi à l’aveugle ou utiliser sed/awk. C’est peut-être pour cela qu’il reste un réflexe KISS consistant à faire apprendre vi à tout le monde. C’est aussi comme ça que j’ai appris.
      Un éditeur en lui-même ne crée pas une grande surface d’attaque, mais je n’écarterais pas la possibilité qu’un attaquant abuse de fonctionnalités de plugins comme moyen de persistance. Il se comportera sans doute différemment lorsqu’il est exécuté en root, mais pas forcément avec des comptes de service.
    • Pour 20 Mo, l’exécutable nano ne fait que 277 Ko, et le paquet .deb complet fait 860 Ko.
      https://packages.ubuntu.com/jammy/nano
    • À l’origine, j’étais utilisateur de nano, mais les vétérans m’ont poussé vers vim, et maintenant je ne touche à nano que lorsque je dois remettre de l’ordre dans mon fichier vimrc.
      À l’époque, j’étais en colère, mais aujourd’hui je suis satisfait d’avoir changé. Vim ou vi est partout, y compris sur les switches et routeurs sur lesquels je travaille. nano n’est pas partout, et on ne peut pas non plus l’y ajouter facilement.
      Si je ne me connectais pas régulièrement en SSH à du matériel ancien ou limité en ressources, j’en verrais sans doute moins l’intérêt.
    • Personnellement, je déteste vraiment nano, donc je choisirais vi à chaque fois.
      Cela dit, le choix d’un éditeur de texte est très personnel. Cela n’a absolument aucun sens de forcer quelqu’un à utiliser ou à ne pas utiliser tel éditeur. Il suffit de laisser les gens utiliser celui qu’ils préfèrent.

  • JOE est plutôt pas mal : https://joe-editor.sourceforge.io/
    Un mélange de WordStar et d’Emacs ; lancé avec jstar, il offre une expérience WordStar assez authentique, tout en gardant un petit air des premiers IDE Borland Turbo.

    • J’aimais vraiment beaucoup JOE. Probablement parce qu’on y retrouvait des traces de WordStar.
      J’ai même écrit un article sur la manière d’utiliser les touches WordStar Diamond sous Linux aujourd’hui : https://benhoyt.com/writings/wordstar-diamond/
    • Mon premier traitement de texte était WordStar sous CP/M, et mon premier environnement de programmation était Borland Turbo Pascal.
      Plus tard, j’ai aussi utilisé QEdit, qu’on pouvait configurer pour utiliser les touches de WordStar.
      Quand je suis passé de DOS à Unix au début des années 90, j’ai été ravi de découvrir JOE. C’est le premier programme que j’installe sur une nouvelle machine Linux ou *BSD, ou dans une VM.
      Aujourd’hui, JOE propose la coloration syntaxique et plusieurs bonnes fonctionnalités, si bien que je n’ai jamais ressenti le besoin de devenir à l’aise avec vi ou emacs.
    • J’ai de bons souvenirs d’avoir utilisé joe dans les années 90 pour à peu près tout, sauf éditer du code.
      Il n’était pas très adapté à l’édition de code, car il relevait davantage d’un modèle de traitement de texte, avec retour automatique à la ligne et absence de coloration syntaxique.
      Mais pour écrire des documents texte, c’était un petit éditeur adorable.
    • Les différences entre les modes et les raccourcis clavier ne sont-elles pas documentées dans le manuel ?
      C’est peut-être moi qui ne les ai pas trouvées, mais je ne les vois vraiment pas.
    • Je le lance souvent avec jmacs pour utiliser le jeu de raccourcis clavier d’Emacs.

  • J’aime micro et je l’utilise tous les jours.
    Cela dit, après avoir essayé Helix, j’ai envie d’un micro avec treesitter, LSP et aide contextuelle intégrés. Helix a vraiment réussi cet ensemble de fonctionnalités, mais le « mode unique + commandes » et la mémoire musculaire Ctrl-C/Ctrl-V sont tellement confortables qu’il est difficile de changer.

    • J’utilise Helix quotidiennement depuis environ six mois, et j’apprécie vraiment le fait que ce soit un éditeur avec toutes les fonctionnalités de base incluses. C’est un excellent éditeur.

  • Je ne comprends pas pourquoi il existe encore des logiciels qui vous demandent d’exécuter avec sudo quelque chose téléchargé depuis Internet.
    Alors qu’il existe une option plus simple, plus sûre, plus légère à installer et intégrée à toutes les distributions, je me demande pourquoi on fait utiliser ce genre de script.
    À titre de comparaison, le paquet micro d’Alpine fait 4 Mo après installation, tandis que le binaire compilé statiquement téléchargé depuis GitHub fait 11 Mo. À mon avis, utiliser le paquet du dépôt est plus dans l’esprit de micro.

    • Est-ce qu’on vous fait vraiment exécuter sudo ?
      Si l’on regarde https://github.com/zyedidia/micro#quick-install-script, le script d’installation rapide est curl https://getmic.ro | bash, et le script place le binaire micro dans le répertoire courant.
      Ensuite, si vous le souhaitez, vous pouvez le déplacer dans un répertoire présent dans le PATH, avec sudo mv micro /usr/bin donné en exemple. Il se contente d’indiquer que sudo est nécessaire pour le déplacer dans /usr/bin ; je ne vois pas vraiment où est le problème.
    • Recommander de passer une source arbitraire d’Internet dans sudo ou dans (ba)sh via un pipe est totalement irresponsable.
      Et la justification ridicule du type « tout le monde fait comme ça » commence à fatiguer.
    • Personnellement, je ne veux pas qu’un intermédiaire se place entre le développeur de l’application et moi.
      Je veux obtenir l’application directement auprès du développeur. C’est ce qui me permet de savoir que j’utilise une version officiellement prise en charge et que personne n’a modifié le code.
      Si je ne fais pas confiance au développeur de l’application, je ne l’installe tout simplement pas.

  • Je pensais que Nano était l’alternative moderne à Pico.

  • Je me demande pourquoi on s’intéresse à ce genre de petits éditeurs
    La seule raison d’utiliser vi/vim, c’est qu’il est partout. Si je dois installer un éditeur, j’installerai Emacs
    Sur un système distant, avec tramp, j’ouvre les fichiers via SSH tout en conservant toute la puissance et la vitesse de mon Emacs local. Pour l’édition dans des UI de terminal comme sudoedit, git commit ou C-x C-e, je garde Emacs lancé en daemon, donc un nouveau frame, y compris un frame terminal, s’ouvre instantanément ; avec nerd font et les couleurs, c’est presque identique à l’interface graphique d’Emacs, et c’est littéralement Emacs
    Pas besoin d’avoir plusieurs éditeurs selon les usages

    • J’utilise Linux depuis plus de 20 ans, mais je n’ai jamais vraiment réussi à comprendre vi, et je le trouve peu intuitif
      Emacs m’a davantage attiré ; quand je me connecte en ssh à un appareil peu puissant, comme un routeur sous OpenWRT, Emacs n’est pas disponible, donc j’utilise Nano, qui me paraît intuitif parmi les éditeurs disponibles
      Je sais qu’on peut aussi utiliser Emacs et TRAMP, mais chacun finit par avoir son propre workflow. Il ne s’agit pas de dénigrer vi : c’est un phénomène bien connu que certains hackers n’arrivent pas à s’y sentir à l’aise
    • Tout le monde ne s’intéresse pas à un éditeur énorme avec une courbe d’apprentissage raide
      Certaines personnes veulent juste modifier rapidement un fichier
      On peut l’utiliser avec des connaissances déjà acquises dans Windows Notepad ou Mac SimpleText, et il fonctionne même quand on n’a qu’une console Unix sur une machine cassée ou un serveur
    • Ce ne sont pas ces petits éditeurs en eux-mêmes qui m’intéressent
      En revanche, les petits éditeurs comme nano m’intéressent beaucoup. La raison est dans ce commentaire racine : https://news.ycombinator.com/item?id=37173126
      Le premier paragraphe ici vaut aussi le détour : https://linuxize.com/post/how-to-use-nano-text-editor/
      Pour les administrateurs système d’aujourd’hui, qui n’ont pas grandi avec vi ou vim et n’ont pas non plus choisi le camp emacs, inclure nano dans les images distribuées à grande échelle est un choix courtois
    • Tous les systèmes d’exploitation que je rencontre ont Nano
      Je n’édite pas souvent des choses à distance, et ce sont généralement de simples fichiers de configuration
      J’ai aussi essayé micro et je l’ai apprécié, mais il ne s’ouvrait pas instantanément sur un Pi, et je ne fais pas de travaux assez gros dans un éditeur en ligne de commande pour avoir vraiment besoin de ses fonctionnalités
    • La raison pour laquelle j’utilise micro, c’est que j’ai pu développer des plugins personnalisés sans grand effort, et qu’il était facile de le déployer par simple copie sur des systèmes dépourvus d’un bon éditeur terminal
      D’habitude je préfère vim, mais l’effort nécessaire pour déployer une configuration correcte sur les systèmes cibles est trop important

  • Le problème que j’ai rencontré avec micro, c’était le collage avec mise en forme
    Quand je collais un fragment de code, micro essayait d’indenter chaque ligne ; comme il ne connaissait pas le contexte global, l’indentation du texte collé devenait progressivement infiniment profonde
    Le processus devenait aussi presque bloqué à force d’inférer la mise en forme ligne par ligne. Au lieu de coller puis de regarder une scène à la Matrix, on finissait par aller se chercher un café
    J’espère que cela a été corrigé, mais j’étais parti à ce moment-là. Si c’est réglé, je pourrais réessayer

    • On peut le désactiver : Ctrl+E puis set autoindent off
      https://github.com/zyedidia/micro/blob/master/runtime/help/o...
      Cela dit, même activé, il devrait indenter correctement quand on colle un bloc entier
      Si vous partagez les réglages, l’environnement et la configuration, je peux essayer de préparer un patch
    • Cela m’est arrivé une fois sous Windows avec Wezterm
      Ça dépend de la façon dont on colle. Je ne suis pas sûr à 100 % du fonctionnement exact, mais micro semble réimplémenter directement le collage avec xclip, et je ne sais pas ce qu’il fait sous Windows
      Si on colle avec Ctrl+V, il insère immédiatement le contenu du presse-papiers comme un bloc et copie l’indentation d’origine. Avec Ctrl+Shift+V, le terminal traite parfois le presse-papiers comme si les caractères arrivaient un par un ; quand il voit un retour à la ligne sans connaître le caractère suivant, il ajoute de l’indentation, puis empile naïvement quelques tabulations de plus

  • Parmi les 14 autres soumissions, celle de 2020 avait 103 commentaires, et celle de 2021 en avait 162
    [0] : https://news.ycombinator.com/item?id=23334190
    [1] : https://news.ycombinator.com/item?id=29128702