Texteditoren und Terminals

[GraphicsPower]

Vor einiger Zeit wurde hier schon mal das Thema Terminal-Editoren angesprochen, bei mir hat sich nun während der letzten Tage die Frage ergeben, wie aktuell ist eigentlich meine Installation Nano betreffend? Tatsächlich war sie nicht mehr auf dem letzten Stand, also habe ich das entsprechende Paket deinstalliert. Der Vorgänger Pico (Pine Composer) wird schon seit Jahren nicht mehr weiterentwickelt und ist schon länger nicht mehr verfügbar. Aber auch Nano hat inzwischen einen Nachfolger bekommen, der sich Micro nennt und darüber hinaus auch noch deutlich leistungsfähiger ist als dieser. Für ihn gibt es zusätzlich auch noch eine ganze Latte an Plugins, die es erlauben ihn permanent für fast alles zu betreiben. Dazu hat er auch noch ein verteiltes Hilfesystem integriert, das darüber informiert wie alles einzustellen ist was man für nützlich hält.

Die Installation des Editors war routinemäßig einfach, da es dafür bereits ein Debian-Paket Ver. 2.0.10 (4,27 MiB) gibt, das leider in den Repos nur selten auf dem letzten Stand ist. Für die nötigen Einstellungen ist allerdings erst mal einiges zu lesen und zu testen. Die Erklärungen und das Hilfesystem zur Bedienung und Konfiguration sind allerdings ziemlich spartanisch gehalten und man muß etliches erst ausprobieren, um damit zurechtzukommen. Die meisten Plugins wenden sich eigentlich eher an Programmierer, aber es gibt auch einige, die den Umgang mit Dateien bzw. Text erleichtern. Wie fast überall gilt auch bei Micro, wo viel Licht ist, da ist auch viel Schatten. So haben sich nach einer Weile auch ein paar lästige Stolpersteine gezeigt, die aber längst mit relativ wenig Aufwand zu beseitigen gewesen wären.

Der Editor setzt auch einige Funktionen beim Terminal voraus, die aber nicht überall vorhanden sind, was den Anwender zu weiteren Maßnahmen zwingt. So hat sich herausgestellt, daß die Funktion Copy & Paste nur eingeschränkt funktioniert, wenn keines der X11-Clipboards, Xclip oder Xsel, installiert ist, bzw. das Terminal das OSC 52 Protokoll nicht unterstützt. Bei ersterem gibt es schnelle Abhilfe indem man eben Xclip installiert, das ermöglicht bei entsprechender Einstellung die Interaktion mit externen Anwendungen außerhalb des Editors und auch außerhalb des Terminals. Bei letzterem ist die Sache aber etwas schwieriger, da man, wie z.B. beim Gnome-Terminal, nun gezwungen wäre den Emulator zu wechseln. Ich würde sowieso am liebsten iTerm2 installieren, der einer der besten Terminal-Emulatoren überhaupt ist, aber der läuft leider nur auf macOS und die schlankeren Emulatoren leiden alle unter diversen anderen Kinderkrankheiten, aber dazu äußere ich mich später noch.

Was bei Micro immer noch fehlt ist ein einfacher Eintrag in der Basis-Hilfe (aufzurufen mit [Alt+G]) für Copy & Paste, der so aussehen sollte: ^C Copy u. ^V Paste. Beide Funktionen stehen in der Standardeinstellung (> set clipboard internal) ohnehin zur Verfügung, allerdings nur innerhalb des Editors. Auch gibt es keinen Indikator in der Statuszeile, der die jeweilige Einstellung anzeigt, die etwa so aussehen sollte: cb:internal. Schon im Installationsprogramm sollte eine Abtastroutine enthalten sein, die automatisch feststellt, ob eines der gefragten X11-Clipboards vorhanden ist oder nicht, um den Standardwert für den eigenen Clipboardmanager eventuell von internal auf external zu stellen. Der dafür nötige Programmieraufwand hält sich in Grenzen, würde aber den Einstieg um manches erleichtern. Tastenkombinationen wie [Strg+C] und [Strg+V] kann man sich sicher auch merken, keine Frage, aber wer längere Zeit ausschließlich GUIs gewohnt war weiß, daß es keine einheitliche Regelung für Tastenkombinationen gibt.

Vielleicht hat hier jemand bereits ähnliches beobachtet, ich jedenfalls bevorzuge eine möglichst schlanke und gleichzeitig leistungsfähige Kombination aus Terminal plus Editor. Mal sehen was sich sonst noch ergibt und wie es weitergeht ...

[robertgoedl]

Also ich aus meiner Sicht verwende Nano, wenn es um die Konfiguration des Systems geht. Speziell unter Debian findet man Software die funktioniert - darum nutzt man Debian. Gerade, wenn man nicht programmiert, braucht man nicht die aktuellste Software - und aus meiner Sicht, wenn man programmieren will, nutzt man nicht Arch - denn gerade dann braucht man gar nicht aufhören an der Software zu arbeiten, weil sich täglich etwas ändert. Brauche ich wirklich etwas Spezielles nutze ich Emacs oder Vim, zwar gewöhnungsbedürftig - aber können alles und noch mehr was andere versprechen

[GraphicsPower]

Brauche ich wirklich etwas Spezielles nutze ich Emacs oder Vim, zwar gewöhnungsbedürftig - aber können alles und noch mehr was andere versprechen

Ich sehe den Editor eigentlich nicht als den Verursacher des Problems, sondern eher das Terminal. Aber mich stört es, wenn grundlegende Funktionen vernachlässigt werden, obwohl man sie ständig braucht. Sicher ist praktisch nirgendwo alles auf dem letzten Stand, nur wenn man schon die Anwendung wechselt, dann sollte man zumindest versuchen die möglichst aktuellste Version zu installieren, außer es verursacht technische Probleme, dann kann man immer noch auf die Repos zurückgreifen. Emacs oder Vim kommen für mich nicht in Frage, nicht nur wegen der Bedienung, sondern auch wegen der Größe, bei Emacs 45,1 MiB zum herunterladen, 193,5 MiB Speicherplatz benötigt, bei Vim 7,1 MiB zum herunterladen, 33,2 MiB Speicherplatz benötigt. Da ist Micro auf jeden Fall viel kleiner. Ich benutze die Repos bei Debian genauso wie du, allerdings mit LMDE 4 und hätte ich Debian installiert, dann wäre die Problematik mit der installierten Software haargenau die gleiche. Wir reden hier über ein altbekanntes Problemfeld, das bereits eine Menge Leute beschäftigt hat, unabhängig von jeglicher Distro.

[GraphicsPower]

Warum ist der Datenaustausch zwischen Anwendungen innerhalb des Terminals und solchen von außerhalb eigentlich so problematisch? Die Gründe dafür sind, wie man immer wieder beobachten kann, doppelt gelagert. Viele Programme, die für den Betrieb im Terminal geschrieben wurden, setzen eine Reihe bestimmter Eigenschaften sowohl bei der Terminalsoftware, als auch im Betriebssystem voraus. Niemand möchte wertvolle Zeit damit verschwenden etwa das Rad neu zu erfinden, daher geht man eben dazu über eine Reihe bekannter Tools einzubinden, die einen bestimmten Job gut genug erledigen. Da aber nicht selten solche Tools gar nicht installiert wurden, müssen diese oft nachträglich eingerichtet werden. Die Entwickler bemühen sich naturgemäß möglichst viele Terminal-Emulatoren benutzbar zu machen, allerdings nur sehr wenige erlauben danach einen technisch uneingeschränkten Betrieb.

Wie frustrierend solche Einschränkungen für manche Software-Entwickler sein können wird hier von Joe Wilm drastisch geschildert. Fallstricke gibt es schon bei Linux genug, umso schlimmer wird es, wenn auch andere Plattformen immer wieder neue Hindernisse aufweisen. Die einen lassen sich auf X11 buchstäblich festnageln, die anderen machen sich wieder von irgendwelchen APIs und/oder Bibliotheken abhängig und jeder kocht seinen Eintopf immer aus dem selben Stoff. Daß dabei unter anderem auch die Performance deutlich leidet, wird leider oft erst danach festgestellt und unter den Teppich gekehrt. Joe Wilm hat daher die Konsequenzen gezogen und seinen eigenen Terminal-Emulator Alacritty geschrieben, der bislang der wahrscheinlich schnellste weltweit ist und gleichzeitig die alten Bibliotheken in Linux und anderswo links liegen läßt. Das ist genau das was ich bevorzuge, sein Terminal-Emulator ist schlank, leistungsfähig und unfaßbar schnell dank GPU-Unterstützung. Im Moment befindet sich sein Programm noch im Beta-Stadium (Ver. 0.9.0), daher werde ich vorerst noch den Werdegang seiner Software nur im Auge behalten und erst wenn sie ausgereift ist installieren!

[robertgoedl]

Danke, mal versuchen. Verschiedene Shells werden mit der Zeit sowieso auch hier auftauchen

[GraphicsPower]

Es ist immer wieder erfrischend festzustellen, daß es auch Programmierer gibt, die sich absichtlich und ganz bewußt nicht an die üblichen Konventionen bei Linux halten. Es gibt bisher eigentlich nur wenige Anwendungen, die ganz ohne das Linux-Dateisystem oder irgendwelche Paketdienste auskommen und dennoch ausgezeichnet funktionieren, der Terminalemulator Kitty gehört jedenfalls dazu. Das Programm läßt sich quasi portabel installieren und ist daher auch noch wesentlich einfacher zu aktualisieren, indem man die Binaries einfach überschreibt. Die Repos bei Debian sind total veraltet und sollten daher, auch laut dem Ersteller, nicht mehr verwendet werden! Zwar ist das Programm noch immer etwas unterentwickelt, aber der Funktionsumfang kann sich sehen lassen, neben der Hardwareunterstützung via GPU kommen auch das OSC 52 und SSH Protokoll zum Einsatz. Kitty ist damit fast so schnell wie Alacritty, wer es nicht glauben will kann das sehr leicht selbst testen. Die Konfigurationsdateien müssen allerdings selbst erstellt werden und im richtigen Verzeichnis stehen. Insgesamt ist die Software als Binary-Bundle mit 13,3 MiB ausgesprochen schlank, mit sogenannten "Kittens" erweiterbar und auch noch plattformübergreifend. Die Performance betreffend wäre auch die CPU-Auslastung noch ein weiterer Faktor, während das Gnome-Terminal bis zu 17% beansprucht liegt sie bei Kitty bei nur max. 8%!

Der Programmierer Kovid Goyal stammt aus Indien und hat bereits einige Tools veröffentlicht.
Sein Vorname klingt vielleicht etwas pandemisch, aber ich hoffe, daß sich keine Viren über sein Programm ausbreiten.

[Alexs]

Ich verwende gedit (Xfce) als Texteditor, allerdings hatte ich vor kurzem ein großes Problem mit den neuen Nvidia-Treiber den meine Grafikkarte nicht mehr unterstützt. Daraufhin ließ sich der X-Server nicht mehr starten. Um auf den nouveau-Treiber umzusteigen (sddm und lightdm haben mit den legacy-Teiber aktuell nicht funktioniert), wurden sämtliche Nvidia-Pakete deinstalliert.
Über mc (sehr hilfreicher Dateimanager) ging ich als root in den Ordner /etc/X11/xorg.conf.d/ hinein, dann wurde über Strg+Alt+F2 ein anderer Terminal (TTY) geöffnet und mit mv 20-nvidia.conf 20-nouveau.conf die Datei dort umbenannt.

Anschließend ging ich mit mc über die Datei 20-nouveau.conf auf Bearbeiten und habe Nano als Editor ausgewählt. Ich musste lediglich das Wort nvidia mit nouveau ersetzen und speichern. Nach reboot ging wieder alles – vorerst ohne Nvidia.

Nano und mc ist für solche Sachen ganz easy. Vi(m) ist mir zu kompliziert.

Edit: Ich mag Kovid Goyal, da von ihm Calibre ist.
Calibre - E-Books unter Linux lesen, verwalten und konvertieren
Calibre und weitere Verwendungsmöglichkeiten

[robertgoedl]

Das Problem an Vi/m ist in vielen Fällen einfach, er ist für einfache Dinge überkonzipiert.

[rockyracoon]

@Alexs:

Nano und mc ist für solche Sachen ganz easy. Vi(m) ist mir zu kompliziert.

So sehe ich das auch. Nano ist bei mir der Standard-Editor.

[GraphicsPower]

Nano und mc ist für solche Sachen ganz easy. Vi(m) ist mir zu kompliziert.

Wem das genügt, der kann sich sicher mit dieser Kombination zufrieden geben. Da es aber auch Anwender gibt die nach höherem streben, verwende ich inzwischen die Kombination: Micro, Ranger, Rifle, Kitty. Die Einrichtung der Farben und Abstimmung aufeinander war in den letzten Tagen richtig zeitintensiv, man glaubt gar nicht wie viel Aufwand nötig ist, um auch noch andere Hürden dazwischen zu beseitigen. Inzwischen arbeiten diese Komponenten alle so wie ich möchte. Leider waren die mitgelieferten Informationen nicht immer ausreichend und so manche Lösung wurde erst nach längerem Suchen wieder in den Tiefen des Internets gefunden. Wie fast immer stößt man mitunter auf Hindernisse, die nur entstehen weil Editoren wie Nano als Standard betrachtet werden und daher oft genug Anpassungen notwendig machen. Das ist weder sinnvoll, noch fördert es die Entwicklung. Besser wäre es, wenn man die Wahl gänzlich dem Anwender überläßt. Seither geht es im Terminal jedenfalls richtig bunt zu!

Ich mag Kovid Goyal, da von ihm Calibre ist.

Du magst nicht ihn, sondern bestenfalls ein paar seiner Programme! Nebenbei, der Kerl hat auch schon öffentlich harsche Kritik von einigen Anwendern kassiert, da er auf diverse Anfragen bzw. auf konstruktive Vorschläge ziemlich unfreundlich reagiert hat. Seine Fähigkeiten als Programmierer stehen daher auf einem anderen Blatt!