Text Editoren

Das ist ja wirklich ein Thema, was die Gemüter erhitzen kann. Der Texteditor ist besonders unter Unix-Nutzern eine wichtige Entscheidung. Eigentlich kann kann man diese Nutzer in drei "Lager" aufteilen:

• Vi und dessen Ableger
• Emacs und dessen Ableger bzw. Editoren, die sich an Emacs orientiert haben
• Alle anderen, die z.B. sowas wie Atom oder Jed benutzen (meistens keine Konsolenbenutzer)

Das Thema ist wichtig, denn man beschäftigt sich den ganzen Tag mit seinem Editor, insbesondere, wenn man das beruflich macht. Und wenn man als Admin unterwegs ist, dann ist ein Editor, der nicht alleine durch das er gestartet wird, den Rechner lahmlegt, ein Muss.

Historisch gab es einen ziemlichen "Zwist" zwischen den Vi-Lovern und den Emacs-Usern. Die Konzepte könnten nicht wirklich gegensätzlicher sein: VI ist vom Prinzip her minimalistisch ausgelegt und soll auch auf den kleinsten Rechnern mit wenig RAM funktionieren, wohingegen Emacs ausgebaut werden kann zu einem eigenen Betriebssystem (das ist schon ein wenig zynisch, denn der Emacs kann eben unheimlich viel).

Ich habe selbst Erfahrung mit beiden Editoren. Möchte jetzt hier mal ein wenig aus dem Nähkästchen plaudern. Die anderen Editoren lassen wir außer Acht, denn die Features sind da relativ schnell abgehakt, insbesondere im Vergleich zu Emacs und Vi. Und außerdem sind die beiden Editoren nicht nur auf Grund ihrer Geschichte eindeutig die "coolere" Wahl.

ein wenig Geschichte

Das ist wirklich super interessant, denn diese Editoren haben eine lange Geschichte. Sie entstammen beide aus Zeiten in denen weder Tastaturen noch Bildschirme einer Norm folgten. Auch die Bedienung war noch nicht wirklich "standardisiert". Von Grafischer Benutzeroberfläche oder Maus ganz zu schweigen. Die allerersten Editoren (also die Vorgänger von Vi und emacs) waren sogar zeilenbasiert, d.h. man hat immer nur eine Zeile bearbeitet. Einer der verbreitesten Vertreter dieser Gattung war der Editor ed - den man heute sicherlich nicht mehr als Editor bezeichnen würde (in MS-DOS gab es damals auch ein Pendant dazu namens edlin). Aber aus ihm wurde der Streaming Editor, sed, der auch heute noch unter Linux/Unix zum Standardtoolset gehört (damit kann man sehr einfach eingaben mit Hilfe von z.B. Regular Expressions verarbeiten, verändern und anpassen).

Normalerweise hat man sich zu diesen Zeiten mit einem Terminal-Client über eine recht langsame Leitung (z.B. 300 baud, also bit/sec - BIT - nicht Megabit oder so) mit einem Computer verbunden (Telnet Protokoll). Bei den langsamen Übertragunsraten war es essenziell, die Übertragung zu optimieren. So wurde (natürlich) nur Text übertragen (gab ja nix anderes) - aber dieser eben auch nur 7-bittig (fast alle Übertragungsprotokolle gingen damals davon aus, dass 7-Bit ausreichen würden). Die Tastaturen waren nicht standardisiert, insbesondere Tasten wie ALT oder CMD gab es nicht überall. Deswegen hat man sich beim VI auf den kleinsten gemeinsamen Nenner beschränkt: Die Tasten für die ASCII-Codes (0-127!) und ESC. Das ist erstaunlich effizient - immer noch.

Beim Emacs ging man derweil andere Wege. Auch hier hatte man mit den gleichen Unzulänglichkeiten der frühen Computer zu kämpfen. Aber man entschied sich, zumindest die CTRL-Taste vorauszusetzen. Damit konnte der Emacs seine Befehle über Tastenkombinationen mit Hilfe von CTRL erhalten. Das führte zu sehr umständlichen Tastaturkürzeln: CTRL-C CTRL-X in kurzer Folge getippt, beendet den EMACS. Und das ist noch eines der kürzeren Beispiele.

Auch wurde bei der Implementierung des Emacs ein anderer Weg eingeschlagen. Die Sprache der Wahl für den Emacs viel auf Lisp - eine Sprache, die als Funktionale Sprache zur Zeit wohl auch wieder ein Revival erlebt. Aber der Emacs ging noch etwas weiter. Er wurde nicht nur in Lisp geschrieben, er konnte mit Lisp auch um eigene Funktionen erweitert werden und der Emacs konnte Lisp-Code ausführen. Der emacs war also relativ von Begin an eine Lisp-Entwicklungsumgebung.

Der Vi wurde mehr oder minder in C/C++ geschrieben und war demzufolge etwas sehr viel schlanker und auch flotter - gerade beim Start. Die Erweiterbarkeit war lange Zeit auch ein "Problem" aber es wurde mit "Vimscript" eine würdige Alternative gefunden.

Vi emacs

VI vs Emacs

Wie man am Titel schon erkennen kann, bin ich mittlerweile eher im VI-Lager angekommen. Das hat mehrere Gründe. Für mich waren die Tastaturkürzel beim Emacs einfach nicht wirklich intuitiv, obwohl ich den Emacs wirklich einige Jahre lang als meine Primäre Entwicklungsumgebung genutzt hatte. Ich hatte dem Emacs beigebracht, Java-Projekte zu compilieren, zu debuggen etc. Und dennoch waren die Tastenkürzel gewöhnungsbedürftig. Das zieht sich beim Emacs durch die gesamte Bedienung, meistens muss man irgendwelche "Affengriffe" auf der Tastatur vollführen, um einen Befehl einzugeben.

Der VI löst das meiner Meinung nach eleganter: man startet im sog. "Normal" Modus. In diesem Modus kann man Kommandos eingeben, die irgendwas tun. z.B. "d" um etwas zu löschen, oder "a" um etwas anzufügen. Bei den meisten Kommandos muss man noch eine Richtung angeben, wie z.B. beim Löschen. Also man tippt "d" und dann noch, was man löschen will, z.B. "w" für alle Zeichen bis zur Wortgrenze. Bei dem "a"-Kommando kommt man in den "Insert"-Modus. Da kann man ganz normal seinen Text editieren. Um aus dem Insert- wieder in den Normal-Modus zu kommen, benutzt man die ESC-Taste.

Das ist so ziemlich das wichtigste, was man zum VI wissen muss. (Außer vielleicht noch, dass man jedes Kommando z.B. mit Zahlen-Präfixen versehen kann. Z.b. würde 5dw die nächsten 5 Wörter löschen)

Der Emacs ist allerdings in seiner Standardausprägung deutlich mächtiger als der normale VI. Was nicht gerade zu seiner Verbreitung beigetragen hat. RAM war damals knapp. Und wenn ein Texteditor dann 8 MB benötigt, um vernünftig zu funktionieren, war das wirklich ein Problem. Deswegen sagen Zynische Zungen auch, Emacs ist kein Texteditor, das ist ein Betriebssystem das allein von der Größe her selbst Windows in den Schatten stellt (zum Verlgeich: Windows brauchte damals gerade Mal 1MB RAM um zu funktionieren 😉 )

Es entwickelte sich so eine kleine Fede zwischen den Emacs-Usern und den Vi-Lovern. Die Vi-Nutzer erfanden andere Bedeutungen für Emacs (Emacs Makes Any Computer Slow oder Eight Megabyte And Constantly Swapping. Und in Anspielung auf die etwas blöden Tastenkombinationen könnte Emacs auch für Escape Meta Alt Control Shift stehen). ein Zitat, was des öfteren im Internet kursiert ist: „Emacs is a great operating system – it lacks a good editor, though.“ (soll auf Thomer M. Gil zurück gehen).

Spasseshalber hat eine der Berühmtheiten der GNU/Opensource Community Richard Stallman sogar eine Religion auf Emacs gegründet: The Church of Emacs - und er selbst ist St. IGNUcius. Das Glaubensbekenntnis der Kirche des Emacs ist: There is no system but GNU, and Linux is one of its kernels. Das soll man 3x am Tag aufsagen 😉 Nerdiger Humor...

Richard M. Stallman: “Emacs started out as a text editor, which became a way of life for many users because they could do all their work on a computer while never exiting from Emacs, and ultimately it became a religion as well.”

Die VI-Lover haben sich natürlich nicht lumpen lassen und haben auch ihrerseits eine "Religion" gegründet: The Cult of VI

Alles in allem schaukelte sich das zu einem echten "Ding" im noch frühen Internet hoch, dem "Editor WAR". Viele Diskussionen zu den beiden Editoren wurden geführt und irgendwie hat keiner so recht "gewonnen" (wenn man in so einem Fall überhaupt von gewinnen sprechen kann). Beide Editoren und deren Ableger gibt es immer noch und erfreuen sich großer Beliebtheit.

Vi-Ableger

Da der VI sehr beliebt war und auf jedem Unix-System immer vorhanden war, gab es auch schnell Erweiterungen und Verbesserungen, wie z.B. den "Vi Improved" oder kurz vim. Dieser Editor ist mehr oder Minder im 21 Jahrhundert angekommen, kann wesentlich mehr als der normale Vi und ist insbesondere sehr stark erweiterbar.

Natürlich gibt es für den Vi ein Menge Grafische Oberflächen, MacVim z.B., oder Plugins, die Texteditoren mit den Vi-Tastaturkürzeln ausstatten (z.B. für InelliJ). Aber seit ein paar Jahren gibt es einen neuen "Player" im Vi-Getümmel: NeoVim

NeoVim

NeoVim ist zunächst mal genau das gleiche, wie es Vim für VI war: eine Verbesserung. Eine Neu-Interpretation des Vi-Gedanken und eine modernere Implementierung mit neuen Features. So unterstützt NeoVim die Sprache Lua für die Erstellung von Erweiterungen (sog. Plugins). Dies macht den Editor deutlich mächtiger insbesondere im Vergleich zum "normalen" vim, der mit "VimScript" zwar auch eine Programmiersprache für Erweiterungen anbietet. Diese birgt aber so ihre Tücken und somit ist die Community ein wenig umgeschwenkt.

Grundsätzlich funktioniert NeoVim aber genauso wie der Vi, wenn er nicht gesondert konfiguriert ist. Aber genau das ist der Charme. Man kann sich den Vi so konfigurieren, wie es einem selbst gefällt. Die Tastenkürzel lassen sich selbst bestimmen. Das ist Aufwand. Aber dann hat man seine persönliche Text-Edit-Umgebung. Die kann dann genau das, was man braucht. Nicht mehr und nicht weniger.

Plugins

Die Plugins, die man in NEoVim installieren kann, machen ihn so dermaßen mächtig. Und dann könnte man meinen, das ganze ding ist so fürchterlich langsam mit jedem zusätzlich installiertem Plugin. Aber das ist bei weitem nicht so. Ich habe so einige Plugins installiert und konfiguriert. Und dennoch startet der NeoVim bei mir in deutlich unter einer Sekunde.

Geschwindigkeit

Das ist im Übrigen eines DER besonderen Features des NeoVim - der Speed mit dem Dinge passieren. Das ist man so nicht gewohnt. Gerade Entwicklungsumgebungen leiden unter all den Features, die benötigt werden um sinnvoll damit arbeiten zu können. Und werden dadurch langsam. Das beste Bespeil dafür ist Eclipse - das war zeitweise wo aufgeblasen, dass man es eigentlich gar nicht mehr starten konnte, ohne sich zwischendrin ne Tasse Kaffee zu holen.

Den NeoVim jetzt mit einer Ide wie Eclipse zu vergleichen hinkt zwar ein wenig, und in anderen Aspekten auch wieder nicht. Die IDEs könnten mehr, als es NeoVim derzeit anbieten kann, aber er kommt wirklich nahe ran. Dennoch will man den Begriff IDE nicht so wirklich als passend für NeoVim empfinden, wenn man ehrlich ist. Eher so was wie PDE - Personal Develop Environment.

Denn Sowohl NeoVim, VIM, oder auch Emacs mit seinen Ablegern sind weit mehr als reine Texteditoren. Diese mit z.B. Notepad zu Vergleichen grenzt wirklich an eine Beleidigung. Und wenn ihr weiter lest, werden ihr verstehen, warum...

Eine der großen Besonderheiten des VI und all seiner Klone ist die Art und Weise, wie man im Text navigieren kann. Die Vim-Movements sind super wichtig zu verstehen. Wenn man das mal verinnerlicht hat, kann man mit nur ein paar wenigen Tasten an jede Stelle im Sichtbaren Editorbereich navigieren. Allein diese effiziente Navigation macht Vi und dessen Ableger auch heute noch so effizient und auch so beliebt. Es gibt so super sinnvolle Dinge, die Gerade Programmiere zu schätzen wissen. Beispielsweise kann man mit % zur zugehörigen Klammer wechseln - und zwar passend mit Verschachtelungen! Das ist GOLD wert! (gerade in Programmiersprachen, die viele Klammern benutzen, wie z.B. Java oder C/C++ und RUST).

Aber auch die Navigation innerhalb einer Zeile ist manchmal umständlich. Nehmen wir diese Zeile hier. Wenn der Cursor am Anfang irgendwo steht und ich zum Wort "manchmal" springen will, gibt es einige Möglichkeiten:

• ich drücke die Taste w so oft, bis ich an der richtigen Stelle bin (springe wortweise nach vorne, W wäre rückwärts)
• ich drücke 6w - weil ich direkt 6 Worte vorspringen will
• ich Drücke fm und springe direkt zum nächsten m in der Zeile. Diese "Vi Motions" sind äußerst effizient, man sollte sich die Zeit nehmen, immer mal wieder ein wenig was dazu zu lernen.

All diese Kommandos für die Navigation lassen sich nämlich auch mit anderen Kommandos kombinieren, so kann ich z.B. die nächsten 5 Worte in der Zeile löschen indem ich 5dw tippe... oder ich möchte bis zur nächsten Klammer löschen, also d% - super praktisch, weil es die Verschachtelung mit berücksichtigt.

Aber das ganze kann man noch weiter spinnen... Wenn sich der Cursor in einem Wort befindet, welches ich löschen möchte, tippe ich einfach diw und das wort ist entfernt.

Das alles ist für Nicht-Vi-Nutzer super verwirrend und soll hier nur die Mächtigkeit dieses Editors und gerade der Vim-Motions demonstrieren. Damit kann man alles machen ohne auch nur an die Maus zu denken... gerade wenn man einen modernen Ableger des VI benutzt und dort noch Plugins integriert. Dann sind einem eigentlich keine Grenzen gesetzt. Man könnte das so weit spinnen, Dass man den NeoVim als Eigene Entwicklungsumgebung nutzt...

NeoVim als IDE

Mit Hilfe der Plugins kann man NeoVim zu einer sehr "persönlichen" IDE konfigurieren. In meinem Fall, kann ich Bash, Lua, Python, Rust und vor allem Java programmieren und habe alle nötigen Features in meinem Editor: TextVervollständigung, Snipplets, Fehler Anzeige, Formatieren von Code, Generieren von Code (automatische Imports in Java z.B.), Starten und Debuggen von Tests oder ganzen Programmen. (wobei mir das mit Rust noch nicht gelungen ist).

Wenn ich das mit anderen IDEs vergleiche (IntelliJ oder NetBeans), welche allein zum starten schon mind. 30 Sekunden brauchen, ist das mit NeoVim doch erfrischend flott. Vor allem, wenn man sich eh im Terminal "aufhält", nur "nur mal kurz" was ausprobieren oder anpassen will. Da wäre das hochfahren der IDE einfach nur Overkill.

Die Frage, ob das ein wirklich für den professionellen Einsatz gangbarer Weg ist, werde ich in den nächsten Wochen mal testen.

Grundsätzlich hat das ganze jedoch so seinen Charme. Ich bin sowieso immer in der Kommandozeile unterwegs, sei es mit SSH oder auch lokal. Wenn ich dann "mal schnell" eine Datei öffnen will und dafür erst eine ganze IDE hochfahren muss, kann das schnell umständlich werden. Meistens lasse ich die IDE im Hintergrund laufen, damit ich das entsprechende File öffnen kann, wenn ich es benötige.

Naütrlich kann eine moderne IDE wie IntelliJ eine Menge, aber für "schnell mal" in ein Projekt gehen und dort einen Test laufen lassen, oder kleinere Änderungen machen. Das hat schon was. Das geht wirklich flotter als mit IntelliJ z.B.

Das ist heute sogar passiert, ich musste in einigen Projekten Suchen, da ich nicht 100% sicher war, wo es drin ist. Das ging in der Kommandozeile wesentlich flotter, als in IntelliJ: mit ripgrep im Filesystem nach den Dateien gesucht, dann das richtige Projekt in nvim geöffnet. Das alles zusammen ging schneller, als das erste Projekt in IntelliJ finden und öffnen (und warten, bis es synchronisiert ist - da waren auch recht große Projekte dabei, die beim start immer ein wenig brauchen). So hat das ganze keine 10s gedauert...

Ein weiterer Aspekt ist meiner Meinung nach die Steuerung des VI mit den verschiedenen Befehlen. Auch das quantifizieren von Befehlen hat wirklich Vorteile. (z.B. 15> rückt die nächsten 15 Zeilen eine Stufe weiter ein). Und über die sehr mächtigen Suchen/Ersetzen Funktionen müssen wir gar nicht reden.

Die meisten dieser Features kann man auch in die IDE seiner Wahl bekommen, wenn man Bock darauf hat. für IntelliJ gibt es mehrere Plugins, die einen VI-Modus implementieren und mit einigen Features erweitern. Alles in allem auch ein guter Kompromiss.

Und wenn man dann noch die Settings in IntelliJ auf das gleiche stellt, wie im NeoVim (oder umgekehrt), fällt einem der Wechsel leichter, auch falls man wieder zurück will oder muss.

Einführung NeoVim

NeoVim ist aktuell normalerweise relativ einfach über die normale Softwaremanagement Systeme eingebunden werden. Auf dem Mac funktioniert es am besten mit brew install nvim (neovim wird fast immer nvim abgekürzt).

Wenn man den NeoVim mit nvim dann startet, dürfte der geneigte Benutzer erst mal etwas ernüchtert sein. Der Screen, der einen da begrüßt ist, gelinde gesagt leer - keinerlei features etc.

Das liegt daran, dass NeoVim zunächst wie ein ganz normaler VI-Clone funktioniert und auch so startet. Jetzt muss man ihn nur noch konfigurieren.

Die Konfiguration des NeoVim liegt im Verzeichnis ~/.config/nvim und die wichtigste Datei ist init.lua. Diese Datei wird beim start des NeoVim ausgeführt. Dort trägt man alle Konfigurationen ein, die man benötigt.

Des Weiteren kann man da auch plugins etc. konfigurieren. Wenn man von Null anfängt, kann einen das schon etwas überfordern. Es gibt im Internet so einige Stellen, wo Leute ihre NeoVim Konfiguration teilen und ich habe auch damit angefangen. Allerdings hat mich das nicht so weit gebracht, wie erhofft. Die meisten Konfigurationen sind halt doch sehr persönlich und stark davon abhängig, was man eigentlich macht. Jemand, der nur von Zeit zu Zeit was mit Java machen muss, sich aber hauptsächlich in Python bewegt hat sicherlich andere Dinge im Fokus als jemand, der hauptsächlich Java oder C++ schreibt. Deswegen habe ich mir dann auch die Mühe gemacht, meine eigene Konfiguration zu bauen. Dabei ist es besonders wichtig, auf die eigenen Bedürfnisse zu "hören". Was ist mir beim Entwickeln wichtig? Welche Features, die mir z.B. eine Full-BlownIDE wie IntelliJ anbietet, nutze ich wirklich. Und was fehlt mir bei so einer IDE.

Ich mus ganz ehrlich sagen, so richtig "gefehlt" hat mir bei IntelliJ nichts. Nur, dass es fürchterlich umständlich ist manchmal, wenn man zwischen branches hin und her wechselt, dass die IDE ne gefühlte Ewigkeit für die Synchronisation benötigt. Und so lange diese nicht abgeschlossen ist, kann man einige Funktionen nicht nutzen. Das ist lästig... aber auch kein gravierendes Problem ehrlich gesagt. Sicherlich kein Grund zu wechseln.

Features, die ich benötige:

• Syntax Highlighting für "meine" Sprachen: Java, Bash/Shell, Python, Lua und Rust. Und es ist schön, das zwischendurch dann doch auch mal unbekannte Sprachen einfach "so" funktionieren. Swift z.B., oder Markdown, oder HTML oder JavaScript
• Autovervollständigung und Suggests für die oben genannten Sprachen
• Fehlererkennung und grundlegende Prüfungen des Codes. (Tippfehler, z.B.)
• Code-Aktionen, wie automatische Imports, umbenennen von Variablen
• Debugging sollten möglich sein

Das war es eigentlich "schon".

Grundlegende Konfiguration

Hier noch ein paar Tipps, wie ich mir die Konfiguration zusammengebaut habe:

1. in der init.lua habe ich eigentlich nur Referenzen auf andere Dateien, die bestimmte Aufgaben übernehmen. Z.b. Plugin Installation, für die meisten Plugins eigene Dateien
2. Dadurch erhält man eine wesentlich bessere Übersichtlichkeit und man kann features leichter hinzufügen und auch bei Bedarf wieder abklemmen
3. Man muss sich ein wenig mit der Programmiersprache LUA auseinandersetzen. Die ist syntaktisch wirklich sehr einfach und es sollte jemandem, der eine IDE braucht nicht schwer fallen, sich da einzulesen. Aber ein paar Grundzüge sind hilfreich
4. Ich habe ein eigenes include, dass sich nur um die Keymappings kümmert. Da kann man sich super austoben. Das "Problem" ist, dass einige Plugins eigene Settings mitbringen. Da muss man evtl. darauf achten, dass man das berücksichtigt.
5. "Debugging" von dem Lua-Code ist etwas hakelig, ich habe es nicht hin bekommen. Aber mit normalen print-Statements kann man sich behelfen. (die Ausgabe sieht man dann, wenn man im NeoVim :messages eingibt)
6. Das aller wichtigste dabei ist aber: Have Fun!

Konfiguration von NeoVim als IDe

Die Konfiguration des NeoVim als IDE ist schon eine Bastelei. Das ist aber auch irgendwie das Ziel, oder nicht 😉 Aber ernsthaft: wer keinen Bock auf Basteln hat, wer keine Lust hat, sich auch mit dem Thema Kommandozeile und zugehörige Tools auseinanderzusetzen, der sollte dann doch zu einer "echten" Entwicklungsumgebung wechseln bzw. dort bleiben.

Die Bastelei mit NeoVim hat mir schon einige neue Ideen gegeben. So habe ich damit die Test-Suite von Morphium so umgestellt, dass ich sie jetzt auch von der Kommandozeile aus starten kann. Das ist grundsätzlich ein Vorteil, selbst wenn ich IntelliJ verwende. So kann ich die Tests laufen lassen, ohne die IDE bemühen zu müssen. (und ich habe mehr Möglichkeiten, die Tests sauberer voneinander zu Trennen!).

Ein paar Konzepte muss man verstanden haben, damit einem Klar ist, was passiert. Das allerwichtigste ist die Unterstützung für LSP - das Language Server Protocol. Dieses dient dazu, z.B. Fehler im Code an den Editor zu geben so dass dieser diese dann anzeigen kann.

Ein weiteres Konzept ist DAP oder Debug Adapter Protokol - damit kann man über den Editor Debug Sessions starten und entsprechend kontrollieren.

Man sollte verstehen, dass diese Konzepte unabhängig von der verwendeten Sprache funktionieren. D.h. ich kann sowohl Python als auch Java mit dem NeoVim debuggen, ohne dass ich mich umgewöhnen muss. Ähnliches gilt natürlich auch für das einblenden von Compiler-Fehlern etc. Das ist auch unabhängig von der Programmiersprache, man benötigt nur den passenden Language Server. (z.B. für Java oder Bash oder Python).

Ich habe oben schon erwähnt, was für mich wichtig war. Es gibt dafür verschiedene Plugins, die ich beim mir eingesetzt habe. Ich möchte hier nicht einfach eine Konfiguration posten, denn - wie ich auch oben schon ausgeführt habe - ist das normalerweise nicht wirklich hilfreich. Wenn man das nutzen will, muss man sich mit dem Thema auseinander setzen.

Also, hier die Liste der von mir verwendeten Plugins.

• Packer - das wichtigste aller Plugins, denn über das werden die Plugins runtergeladen und konfiguriert. Am besten liest man sich did Dokumentation auf github dazu an.
• Mason - ein super Plugin, welches die gesamt LSP/DAP-Verwaltung übernimmt. Dabei geht es besonders um die installation der zugehörigen Plugins und Helfer
• Whichkey - zeigt mir an, welche Tasten jetzt welche Aktion ausführen würden. Bei mir ist z.B. die Tastenkombination <space>Lt eingetragen um einen Test zu starten. Falls ich nicht mehr genau weiß, was ich tun kann, erscheint bei einer "Pause" ein Menü. Tippe ich nur <space>L wird mir ein Menü mit allen optionen angezeigt.
• Null.ls - formatter für verschiedene Programmiersprachen. Bei mir läuft er mit dem Kürzel <space>lf
• impatient - das ist ein Plugin, welches die Startzeit des neovim start reduziert indem es die plugins erst bei bedaruf und vor allem asynchron installiert / konfiguriert. Dadurch startet der NeoVim selbst mit mehreren Duzend Plugins in ein paar millisekunden

Über das Mason Plugin werden insbesondere die LSP-Unterstützungen nachinstallert. Das ganze ist wirklich relativ einfach - zumindest für die meisten Fälle.

Syntax highlighting und Code Formatting funktioniert meistens out of the box allerdings wird es deutlich schwieriger, wenn man dann auch noch so features wie autocompletion (InelliSense) und die Anzeige von Fehlern (Syntax/Compile fehler) integriert werden sollen. Dazu muss man zwingend den passenden LSP-Server installieren.

Diese werden meistens gleich von Mason mit installiert, aber manchmal muss man von hand etwas nachhelfen.

Auch benötigen einige z.B. CodeFormatter spezielle Kommendozeilentools. Beispielsweise lasse ich meinen Java-Code über astyle formattieren (weil das ergebnis mir besser gefällt, als das vom google-formatter). Aber - und genau das ist das schöne daran - das kann man ja beliebig Einstellen / Umstellen / herumspielen, wie man es mag.

Fazit

Ich nutze den NeoVim jetzt seit ein paar Wochen als meine primäre IDE, anfangs nur für meine HobbyProjekte (z.B. Morphium) aber jetzt auch immer häufiger auch für den Einsatz in der Arbeit beim Bearbeiten großer Java Projekte.

Die Vorteile des NeoVim liegen ganz eindeutig in seiner Geschwindigkeit: starten des NeoVim und suchen nach einer Datei ist in gefühlten Millisekunden getan, in IntelliJ würde alleine das öffnen eines Projektes länger dauern. Das ist ein Riesiger Vorteil!

Die Cursor-Navitgation mit Hilfe der Vim-Movements sind ein weiteres sehr großes Plus und ein MUSS für jeden Editor ehrlich gesagt. Ich will es nicht mehr missen. Der Editor macht es möglich, dass ich ohne Probleme jede Stelle auf dem Bildschirm erreichen kann, ohne dass die Hand zur Maus wechseln muss.

Und das beste: all diese Navigationen lassen sich auch noch mit "echten" Kommandos kombinieren. Diese Tastenkürzel sind unheimlich mächtig, aber auch mächtig kompliziert. Aber wer gelernt hat, dass yip den Paragraphen, in dem Sich der Cursor gerade befindet, copiert (und mit neovim ist das dann in der Zwischenablage des Betriebssystems, also z.B. vom Mac), möchte das überall nutzen. 😉

und wenn man diese Kommandos dann noch quantifiziert, dann wird es erst richtig lustig: 5yip kopiert die nächsten 5 Absätze in die Zwichenablage!

Wer es etwas deutlicher haben will, kann auch mit :5,25y die Zeilen 5 bis 25 in die Zwischenablage kopieren.

Und gerade als Entwickler gibt es noch ein paar features, die man gut brauchen kann. So kann man mit yi{ z.B. alles kopieren, was die den Curser umschließenden geschweiften Klammern beschreibt. Das geht auch mit anderen Klammern oder Anführungsstrichen.

Und wenn es etwas destruktiver haben will, der kann das y in den Kommandos mit einem d ersetzen und schon wird gelöscht anstelle von kopiert (streng genommen wird sogar ein cut gemacht, also "ausgeschnitten", denn danach ist immer noch alles in der Zwischenablage).

Aber natürlich hat so ein Setup auch seine Nachteile und die muss man gewillt sein, in Kauf zu nehmen. Der Wichtigste Nachteil ist vermutlich die steile Lernkurve. Das betrifft nicht nur die Vim Motions, sondern auch die Konfiguration und wie man mit LSP etc umgehen muss. Das ist alles recht kompliziert und man benötigt schon ein paar Tage bis man da rein gewachsen ist.

Der Gewichtigste Nachteil ist evtl. aber auch ein Vorteil: Es gibt kaum etwas "vorgefertigtest" was auf die eigenen Bedürfnisse so 100% passt. Man ist also gezwungen, seine eigenen Vorstellungen abzubilden. Das ist zgegebenermaßen nicht jedermanns Sache und das muss es auch nicht. Aber wer Spass am Basteln hat, sollte dem Ganzen vielleicht eine Chance geben.

Und ich will auch nicht verschweigen, dass solch ein Setup manchmal etwas nervt. Es passiert häufiger, dass es updates gibt, die sobald sie eingespielt werden, mehr Probleme bereiten, als sie lösen. Aber das hat man häufiger mit Software. Hier ist es nur so, dass durch die verschiedenen Plugin-Autoren das ganze noch deutlich stärker streut, als von einem einzelnen Hersteller.

Wie gesagt, solch ein Setup ist nicht jedermanns Sache, ist aber erstaunlich leistungsfähig. Und ich habe früher im Scherz gesagt, "mir ist egal in was du entwickelt, von mir aus sogar im VI" - und genau das tue ich jetzt! 😉