micro – eine moderne Alternative zu nano

 (micro-editor.github.io)
2 Punkte von GN⁺ 2023-08-19 | 1 Kommentare | Auf WhatsApp teilen
  • micro ist ein Texteditor für das Terminal, der so einfach wie nano starten soll, aber eine modernere und intuitivere Bedienung anstrebt
  • Er wird als statisches Binary ohne Abhängigkeiten ausgeliefert, was die Installation erleichtert; offizielle Release-Downloads und eine ausführliche Installationsanleitung werden bereitgestellt
  • Optionen und Key Bindings lassen sich im JSON-Format ändern; weitergehende Erweiterungen sind über Lua-Konfiguration und Plugins möglich
  • Unterstützt Syntax-Highlighting für über 75 Sprachen, 7 Standard-Farbthemes, 16-/256-/truecolor-Themes, mehrere Cursor im Sublime-Stil sowie Mausbedienung
  • Dank integriertem Terminal-Emulator kann man im Editor eine interaktive Shell ausführen und in einer geteilten Ansicht Code und bash nebeneinander sehen

micro als Terminal-Editor

  • micro ist ein terminalbasierter Texteditor und stellt moderne, intuitive Bedienbarkeit in den Vordergrund
  • Die neueste Version ist unter Download verfügbar; außerdem gibt es eine ausführliche Installationsanleitung
  • Es gibt ein Drittanbieter-Pipe-to-Shell-Skript nach dem Muster curl https://getmic.ro | bash, dieses steht jedoch nicht unter der Kontrolle von micro
  • Zur einfachen Installation wird micro als statisches Binary ohne Abhängigkeiten ausgeliefert

  • Konfiguration und Erweiterung

    • Für Optionskonfiguration und das Neubelegen von Tasten wird ein einfaches JSON-Format verwendet
    • Wenn stärkere Konfigurationsmöglichkeiten benötigt werden, kann Lua verwendet werden
    • Plugins werden in Lua geschrieben; ein Plugin-Manager übernimmt automatisches Herunterladen und Installieren

  • Bearbeitungsfunktionen

    • Unterstützt Syntax-Highlighting für über 75 Sprachen
    • Bietet 7 Standard-Farbthemes
    • 16-Farben-, 256-Farben- und truecolor-Themes können verwendet werden
    • Unterstützt mehrere Cursor im Sublime-Stil
    • Key Bindings können in bindings.json geändert werden

  • Maus und integriertes Terminal

    • Text kann per Klicken und Ziehen ausgewählt werden
    • Doppelklick dient zur wortweisen Auswahl, Dreifachklick zur zeilenweisen Auswahl
    • In micro kann eine echte interaktive Shell ausgeführt werden
    • In einer geteilten Ansicht kann auf einer Seite Code und auf der anderen bash angezeigt werden
    • Die vollständige Funktionsliste findet sich in der GitHub-Funktionsliste und in der Online-Hilfe

Projekt und Community

  • Bugs können über den GitHub-Issue-Tracker gemeldet werden; auch Fragen und Vorschläge für neue Funktionen sind möglich
  • Pull Requests werden angenommen
  • Informelle Diskussionen über den Editor sind im Gitter-Chat möglich
  • Relevante Links:
  • Nutzerreaktionen umfassen Einschätzungen wie ein schlicht funktionierender Editor, Mausunterstützung und die Möglichkeit, ihn statt nano oder Vim zu verwenden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-19
Meinungen auf Hacker News

  • Wenn ich in einem Kurs, in dem alle Anfänger sind, Kommandozeilen-Programmierung unterrichte, empfehle ich den Studierenden nano.
    Der größte Vorteil von nano für diese Nutzer ist, dass alle Befehle unten auf dem Bildschirm angezeigt werden; ich war überrascht, dass micro das nicht hat.

    • Der Unterschied zwischen micro und nano ist, dass nanos Tastenkürzel ziemlich eigenwillig sind, während micro den Konventionen folgt, die heute in den meisten grafischen Apps üblich sind: Ctrl+S zum Speichern, Ctrl+F zum Suchen, Ctrl+Z zum Rückgängigmachen, Ctrl+Q zum Beenden.
      Unten auf dem Bildschirm gibt es auch Hinweise, dass man mit Alt+G die Tastenkürzel und mit Ctrl+G die Hilfe anzeigen kann.
    • Die Absicht von micro scheint weniger zu sein, ein einsteigerfreundlicher oder überall vorhandener Editor zu sein, sondern eher ein moderner und erweiterbarer Editor.
      In dieser Hinsicht ist es für Studierende wohl weiterhin richtig, nano zu empfehlen; micro passt eher zu Leuten, die nach dem Lernen mit nano mehr Funktionen oder eine bessere UI wollen.
    • Mit Alt+G scheint ein Bildschirm mit Tastenkürzeln zu erscheinen, und Ctrl+G öffnet die Hilfe.
      Es scheint auch eine Art Kommentar-Modus zu geben.

  • Ich habe über 10 Jahre lang Emacs verwendet und nutze jetzt micro als meinen Haupt-Code-Editor. Nur für das Schreiben von Coq verwende ich ausnahmsweise vscode.
    Ich sehe micro als modernen Kompromiss in Richtung acme; es hat fast alle Funktionen, die die Kernideen von acme unterstützen. Um diese Richtung zu nutzen, habe ich auch ein Plugin geschrieben: https://github.com/xxuejie/micro-acme
    Bisher passt es perfekt.

    • Da ich heutzutage nur noch etwa 1 % der Emacs-Funktionen nutze, probiere ich als Emacs-Alternative immer wieder leichtgewichtige Terminal-Editoren aus, vermisse aber die gängigen Emacs-Major-Modes für C/C++ usw. und vor allem deren Einrückungsverhalten sehr.
      Ich wünschte, andere Editoren würden ebenfalls der Konvention folgen, mit Tab die korrekte Einrückung zu erzwingen.
    • Ich kenne micro nicht gut, deshalb frage ich: Gibt es einen Grund, warum sich die Entwicklungsgeschwindigkeit in den letzten ein bis zwei Jahren verlangsamt hat?
      https://github.com/zyedidia/micro/tags
    • Ähnlich bin ich von Emacs zu Acme gewechselt und nutze im Terminal mg.
      Inzwischen habe ich Micro so angepasst, dass es sich nach Acme anfühlt.

  • Ich wusste gar nicht, dass es Leute gibt, die nano als Haupt-Code-Editor verwenden. Auf *nix-Servern, an denen ich arbeite, nutze ich ihn ständig, wahrscheinlich zehntausende Male.
    Ich habe lange als Linux/BSD-Engineer gearbeitet, und manche Stellen haben sich geweigert, nano auf Servern zu installieren. Es gibt alteingesessene Linux-Administratoren, die außer vi absolut nichts zulassen, und ich verstehe das nicht. Es ist ein 20-MB-Paket, und die Angriffsfläche ist auch nicht besonders groß.

    • Alte Hasen verhalten sich am Ende eben wie alte Hasen.
      Ich muss immer lachen, wenn man jemanden aus der früheren Generation fragt, welche Systeme er betrieben hat, und er prahlerisch erzählt, er sei für die gesamte IT-Abteilung seiner lokalen Verwaltung zuständig gewesen, in einer recht großen Stadt mit mindestens etwa 500 Nutzern.
      Ich bin mir zu 105 % sicher, dass dieses System das sicherste im ganzen County gewesen sein dürfte, aber zugleich war es wohl ein unbenutzbares System. Wenn diese Person in Rente geht oder jemand im Büro sie aus Verzweiflung entfernt, hoffe ich, dass sie durch einen modernen Engineer ersetzt wird, der sich zwar vielleicht nicht mit vi auskennt, aber wenigstens ein bisschen um die Nutzer kümmert. Natürlich sind wir auch Engineers, also kümmern wir uns nicht allzu sehr.
    • Der Hauptgrund, warum ein Unix-Administrator vi in- und auswendig kennen sollte, ist, dass es auf Unix- und Linux-Systemen der kleinste gemeinsame Nenner ist.
      Wenn man als *nix-Techniker arbeitet, kann es sein, dass man mit Systemen wie QNX, HP-UX, SGI-Altix-Supercomputern oder Sun Ultra 2 zu tun hat. Linux war dank Paketverwaltung für freie/Open-Source-Software einfach, und bevor nano populär wurde, war es auch üblich, dass Emacs in der Standardkonfiguration enthalten war.
      Manchmal gab es Terminal-Probleme, sodass man nur eine einzige Zeile sehen konnte; dann musste man vi blind bedienen oder sed/awk verwenden. Vielleicht ist deshalb dieser KISS-Instinkt geblieben, allen vi beibringen zu wollen. Ich habe es auch so gelernt.
      Ein einzelner Editor schafft zwar keine große Angriffsfläche, aber ich schließe nicht aus, dass Angreifer Plugin-Funktionen als Mittel zur Persistenz missbrauchen könnten. Wenn er als root ausgeführt wird, verhält er sich wohl anders, bei Service-Accounts aber möglicherweise nicht.
    • Von 20 MB kann kaum die Rede sein: Die nano-Binärdatei ist 277 KB groß, und selbst das gesamte .deb-Paket hat 860 KB.
      https://packages.ubuntu.com/jammy/nano
    • Ich war ursprünglich nano-Nutzer, wurde aber von den alten Hasen zu vim gedrängt und fasse nano heute nur noch an, wenn ich meine vimrc-Datei aufräumen muss.
      Damals war ich sauer, aber heute bin ich froh über den Wechsel. Vim oder vi ist überall, sogar auf den Switches und Routern, an denen ich arbeite. nano ist nicht überall vorhanden und lässt sich auch nicht überall leicht hinzufügen.
      Wenn ich mich nicht regelmäßig per SSH auf alte oder ressourcenarme Hardware einloggen würde, hätte ich den Vorteil vermutlich weniger gespürt.
    • Persönlich hasse ich nano ziemlich und würde jederzeit vi wählen.
      Allerdings ist die Wahl eines Texteditors eine sehr persönliche Sache. Es ergibt überhaupt keinen Sinn, jemanden dazu zu zwingen, einen bestimmten Editor zu benutzen oder nicht zu benutzen. Man sollte die Leute einfach verwenden lassen, was sie mögen.

  • JOE ist ziemlich gut: https://joe-editor.sourceforge.io/
    Eine Mischung aus WordStar und Emacs; wenn man ihn als jstar startet, bietet er ein ziemlich authentisches WordStar-Erlebnis und hat zugleich noch etwas vom Flair der frühen Borland-Turbo-IDEs.

    • Ich mochte JOE wirklich sehr. Vermutlich, weil Spuren von WordStar darin steckten.
      Ich habe sogar einen Artikel darüber geschrieben, wie man die WordStar-Diamond-Tasten unter Linux nutzt: https://benhoyt.com/writings/wordstar-diamond/
    • Meine erste Textverarbeitung war WordStar unter CP/M, und meine erste Programmierumgebung war Borland Turbo Pascal.
      Später nutzte ich auch QEdit, das sich auf WordStar-Tastenbelegung konfigurieren ließ.
      Als ich Anfang der 90er von DOS zu Unix wechselte, war ich froh, JOE zu entdecken. Es ist das erste Programm, das ich auf einer neuen Linux- oder *BSD-Maschine bzw. VM installiere.
      Heutzutage hat JOE Syntax-Highlighting und viele gute Funktionen, sodass ich nie das Bedürfnis hatte, in vi oder emacs wirklich fit zu werden.
    • Ich habe gute Erinnerungen daran, in den 90ern für fast alles außer Code-Editing joe benutzt zu haben.
      Für Code war er nicht besonders gut, weil er eher dem Textverarbeitungsmodell folgte, etwa mit automatischem Zeilenumbruch und fehlendem Syntax-Highlighting.
      Aber zum Schreiben von Textdokumenten war er ein liebenswerter kleiner Editor.
    • Sind die Unterschiede zwischen den Modi und die Keybindings nicht im Handbuch dokumentiert?
      Vielleicht habe ich es nur nicht gefunden, aber ich sehe es wirklich nicht.
    • Ich starte ihn oft als jmacs und nutze dann das Set von Emacs-Tastenkürzeln.

  • Ich mag micro und nutze es täglich.
    Allerdings habe ich nach dem Ausprobieren von Helix den Wunsch, micro in einer Form mit eingebautem treesitter, LSP und kontextbezogener Hilfe zu haben. Helix hat dieses Funktionspaket wirklich gut umgesetzt, aber „ein Modus + Befehle“ und das Muskelgedächtnis für Strg-C/Strg-V sind so bequem, dass mir der Umstieg schwerfällt.

    • Ich nutze Helix seit etwa sechs Monaten täglich, und mir gefällt wirklich, dass es ein Editor mit vollständiger Grundausstattung ist. Ein hervorragender Editor.

  • Ich verstehe nicht, warum es immer noch Software gibt, die einen auffordert, für etwas aus dem Internet Heruntergeladenes sudo auszuführen.
    Es gibt einfachere, sicherere Optionen mit kleinerem Installationsumfang, die in allen Distributionen integriert sind – warum sollte man solche Skripte verwenden lassen?
    Zum Vergleich: Das micro-Paket von Alpine ist nach der Installation 4 MB groß, während das statisch kompilierte Binary von GitHub 11 MB hat. Das Paket aus dem Repository zu verwenden, wirkt für mich mehr im Sinne von micro.

    • Wird man wirklich dazu gebracht, sudo auszuführen?
      Unter https://github.com/zyedidia/micro#quick-install-script ist das Schnellinstallationsskript curl https://getmic.ro | bash, und das Skript legt das micro-Binary im aktuellen Verzeichnis ab.
      Danach kann man es, wenn man möchte, in ein Verzeichnis im Pfad verschieben; als Beispiel wird sudo mv micro /usr/bin genannt. Es weist nur darauf hin, dass man sudo braucht, wenn man es nach /usr/bin verschieben will – ich frage mich, ob das wirklich ein Problem ist.
    • Zu empfehlen, beliebige Quellen aus dem Internet in sudo oder (ba)sh zu pipen, ist völlig unverantwortlich.
      Ich bin auch die lächerliche Rechtfertigung „das machen doch alle so“ leid.
    • Persönlich möchte ich keinen Mittelsmann zwischen dem Anwendungsentwickler und mir haben.
      Ich möchte Anwendungen direkt vom Entwickler beziehen. So kann ich sicherstellen, dass ich die offiziell unterstützte Version nutze und niemand am Code herumgepfuscht hat.
      Wenn ich dem Anwendungsentwickler nicht vertraue, installiere ich die Anwendung einfach nicht.

  • Ich dachte, Nano sei die moderne Alternative zu Pico.

  • Ich frage mich, warum man sich für solche kleinen Editoren interessiert
    Der einzige Grund, vi/vim zu benutzen, ist, dass es überall vorhanden ist. Wenn ich einen Editor installiere, würde ich Emacs installieren
    Bei Remote-Systemen öffne ich Dateien per tramp über SSH und behalte so die volle Leistung und Geschwindigkeit meines lokalen Emacs. Für Terminal-UI-Bearbeitung wie sudoedit, git commit oder C-x C-e lasse ich Emacs als Daemon laufen, daher erscheinen neue Frames und Terminal-Frames sofort; inklusive Nerd Font und Farben ist es fast identisch mit der Emacs-GUI, und es ist buchstäblich Emacs
    Es ist nicht nötig, für verschiedene Zwecke mehrere Editoren zu haben

    • Ich nutze Linux seit über 20 Jahren, aber vi habe ich bis zuletzt nie richtig verstanden und empfinde es als nicht intuitiv
      Emacs war für mich attraktiver, und wenn ich mich per ssh auf ein leistungsschwaches Gerät wie einen Router mit OpenWRT verbinde, gibt es dort kein Emacs, also nutze ich unter den verfügbaren Editoren Nano, der mir intuitiv erscheint
      Ich weiß, dass man auch Emacs und TRAMP verwenden könnte, aber jeder entwickelt seinen eigenen Workflow. Ich will vi nicht schlechtreden; es ist ein bekanntes Phänomen, dass manche Hacker mit vi nie warm werden
    • Nicht alle interessieren sich für riesige Editoren und steile Lernkurven
      Manche wollen einfach nur schnell eine Datei ändern
      Es lässt sich mit dem Wissen nutzen, das man bereits aus Windows Notepad oder Mac SimpleText hat, und funktioniert auch in Situationen, in denen auf einer kaputten Maschine oder einem Server nur eine Unix-Konsole verfügbar ist
    • An solchen kleinen Editoren an sich habe ich kein Interesse
      An kleinen Editoren wie nano habe ich allerdings großes Interesse. Der Grund steht in diesem Root-Kommentar: https://news.ycombinator.com/item?id=37173126
      Auch der erste Absatz hier ist lesenswert: https://linuxize.com/post/how-to-use-nano-text-editor/
      Für heutige Systemadministratoren, die nicht mit vi oder vim aufgewachsen sind und sich auch nicht für das emacs-Lager entschieden haben, ist es eine höfliche Entscheidung, nano in Massen-Deployment-Images aufzunehmen
    • Auf jedem Betriebssystem, dem ich begegne, ist Nano vorhanden
      Ich bearbeite remote auch nicht oft etwas, und meistens sind es nur einfache Konfigurationsdateien
      Ich habe micro ausprobiert und mochte es, aber auf dem Pi war es nicht sofort verfügbar, und ich mache in einem Kommandozeilen-Editor keine so großen Arbeiten, dass ich die Funktionen unbedingt bräuchte
    • Ich nutze micro, weil ich mit wenig Aufwand eigene Plugins entwickeln konnte und es sich auch auf Systeme ohne brauchbaren Terminal-Editor einfach per Kopieren verteilen ließ
      Normalerweise bevorzuge ich vim, aber der Aufwand, eine gute Konfiguration auf Zielsysteme zu verteilen, ist zu groß

  • Das Problem, das ich mit micro hatte, war formatiertes Einfügen
    Wenn ich Code-Schnipsel einfügte, versuchte micro, jede Zeile einzurücken; weil es aber den Gesamtkontext nicht kannte, wurde die Einrückung des eingefügten Textes immer tiefer, praktisch endlos
    Da es pro Zeile die Formatierung ableitete, wurde der Vorgang außerdem fast bis zum Stillstand langsam. Statt einzufügen und eine Szene wie aus Matrix zu beobachten, ging man sich Kaffee holen
    Ich hoffe, das ist behoben, aber an diesem Punkt bin ich ausgestiegen. Wenn es behoben ist, könnte ich es noch einmal versuchen

    • Man kann es deaktivieren: Ctrl+E und dann set autoindent off
      https://github.com/zyedidia/micro/blob/master/runtime/help/o...
      Trotzdem sollte auch im aktivierten Zustand beim Einfügen eines ganzen Blocks korrekt eingerückt werden
      Wenn du Einstellungen, Umgebung und Konfiguration teilst, könnte ich versuchen, einen Patch zu erstellen
    • Mir ist das einmal unter Windows mit Wezterm passiert
      Es hängt davon ab, wie eingefügt wird. Ich bin mir nicht zu 100 % sicher, wie es genau funktioniert, aber micro scheint das Einfügen direkt mit xclip neu zu implementieren, und ich weiß nicht, was es unter Windows macht
      Wenn man mit Ctrl+V einfügt, wird der Inhalt der Zwischenablage sofort als Block eingefügt und die ursprüngliche Einrückung übernommen. Wenn man Ctrl+Shift+V verwendet, wird das in manchen Fällen so behandelt, als würde die Zwischenablage zeichenweise aus dem Terminal hereinkommen; sieht es ein Return-Zeichen, ohne das nächste Zeichen zu kennen, fügt es zusätzliche Einrückung ein und legt dann naiv noch ein paar Tabs obendrauf

  • Von 14 anderen Einreichungen hatte der Beitrag von 2020 103 Kommentare und der von 2021 162 Kommentare
    [0]: https://news.ycombinator.com/item?id=23334190
    [1]: https://news.ycombinator.com/item?id=29128702