Kennt Ihr den Spruch? »Emacs ist ein ganzes Betriebssystem, aber der mitgelieferte Text-Editor ist nicht so toll.« Der lange Glaubenskrieg zwischen den Lagern »Emacs« und »Vi« hätte längst beendet sein sollen und hat heute auch sehr an Bedeutung verloren. Im Grunde geht es aber um Usability (Deutsche Begriffe dafür haben sich nicht durchgesetzt.) und was der richtige Funktionsumfang für ein Programm ist. Dabei sind auch nicht alle Menschen gleich und was dem Einen wichtig ist will der Andere gar nicht wissen.

Den neuen MacVim kann man auf GitHub herunterladen. MacVim und gVim haben gemeinsam, dass man im Insert-Modus (in dem der Editor auch starten kann), alle wichtigen Kommandos - wie unter dem jeweiligen Betriebssystem gewohnt - über Menü und Tastatur erreichen kann. Insbesondere die Tastenkombinationen für Ausschneiden, Kopieren, Einfügen, Speichern und Beenden sind unter Vi und Emacs eine Einstiegshürde für neue Nutzer. GNU-Emacs versucht das mit dem CUA-Mode zu beheben, aber spätestens bei der Textsuche gibt es keine vernünftige Lösung. Aquamacs geht da in die gleiche Richtung wie MacVim, aber für Windows gibt es den nicht. 

Aber warum überhaupt diese alten Editoren benutzen, wenn man doch die Bedienung von moderneren Programmen benutzen will? Es gibt ein paar kleine Editoren, die eigentlich viel besser benutzbar sind. Aber sie sind meist vergleichsweise unbekannt und werden von ihren Entwicklern meistens nicht gepflegt. Jedes Betriebssystem-Update kann sie aus der Bahn werfen und im Allgemeinen laufen sie nicht überall. Gelegentlich braucht man einen größeren Funktionsumfang, als solche Mini-Projekte haben. »Vollwertige« Editoren (oder IDEs) sind aber oft so komplex, dass die Benutzbarkeit darunter leidet. 

So auch bei VIM. Er ist nicht mehr der einfache Vi, der für alle komplexeren Operationen einfach den Aufruf von externen Shell-Kommandos benutzt (obwohl das weiterhin funktioniert), sondern hat sich Emacs in den Funktionen stark angenähert (mehrere Puffer, besseres Undo, Syntax-Highlighting, …). Man kann sogar über die GUI eine HTML-Version des Syntax-Highlightings abspeichern. Und obwohl man bei MacVim und gVim beispielsweise die Schrift über das Menü ändern kann, muss für das dauerhafte Speichern der Einstellungen in einem etwas seltsamen Modus die Datei .vimrc mehr oder weniger von Hand (allerdings durchaus erreichbar über den Menüpunkt »Einstellungen…«) geändert werden. Während der hier einfacher zu bedienende WinVi auch mit Proportionalschrift umgehen kann, machen MacVim und gVim hier schlapp.

Moment! Warum machen Text-Editoren so etwas eigentlich selbst? Sollten die Funktionen des Betriebssystems nicht schon dafür sorgen, dass alle Schreibprogramme Proportionalschrift, Ligaturen und Emoji (MacVim kann Emoji - gVim nicht) unterstützen? Das Problem ist, dass im allgemeinen die Eingabefelder Betriebssystems  viele Funktionen behindern, die ein Programmierer wünscht, und deshalb praktisch kein Editor und keine IDE diese Klassen direkt verwendet. So verhält sich MacVim bei ↖︎,↘︎, ⇞ und ⇟ als wäre man in einem normalen Windows-Programm - naja fast: bei ⇞und ⇟ wandert die Schreibmarke mit. Bei der Kombination von Cursortasten mit Wahl- (⌥) und Befehlstaste (⌘) verhält er sich aber Mac-Like während gVim unter Windows nur die <Strg>-Taste kennt. (Letztere bewegt als Modifier den Cursor unter Windows Wortweise.)

Als IDE will ich Vim dann doch nicht unbedingt benutzen. Ich mag zum Beispiel die JetBrains Schrift, die auch unter Xcode und Visual Studio != als ≠ und <= ≤ als dargestellt wird. (Im Oberon System wurde damals das Pointer Symbol ^ per Zeichensatz als ↑ dargestellt.) Ich finde feste Laufweiten im allgemeinen nicht hilfreich. Stattdessen finde ich es besser, wenn - wie es beispielsweise Xcode mit CoreData-Modellen anbietet - auch mal Diagramme den Code repräsentieren können. Oder eine Illustration in einem (Kopf-)Kommentar der eine Funktion beschreibt? Es ist doch nicht so, dass das technisch ein größeres Problem wäre, aber hier gehen die Kinder des Schusters wieder Barfuß und malen notfalls mit ASCII-Kunst Pfeile in den Quelltext. Das ist heute akzeptierte Praxis, aber das sollte es nicht mehr sein.

Um mal eben ein kurzes Programm zu schreiben, ist ein MacVim aber sehr gut geeignet und wer auch mal über eine Telnet-Verbindung einen Text ändern muss, der freut sich, dass die gelernten Befehlskombinationen funktionieren (wie »⎋dd«, »1G«, »p«, »4j«, »ma«, »G«, »d’a« »:wq↩︎«), mit denen man so schnell über den Text flitzen kann ohne ständig die Hände verknoten zu müssen. 

Es sind oft Kleinigkeiten, die den Unterschied zwischen anstrengender und bequemer Software ausmachen. Beispielsweise Drag&Drop: Bin ich der Einzige, der nach dem Drop immer im Zielprogramm weiterarbeiten will? Aber ein Shortcut-Kommando geht nach einem Drop an das Programm, mit dem es begonnen hat (es sei denn man geht über das Dock - was Windows nicht kann). Aber das ist schon wieder ein ganz anderes Thema, oder nicht?