Nach meinem ersten Statusupdate zum Thema vim folgt hier nun das erste Update - diesmal spezifisch zum Thema vim und Java ...

Ich habe mir angesehen, wie meine Arbeitsabläufe beim Entwickeln in der IDE in Java-Projekten sind und welche der von mir dort häufig einegsetzten Funktionalitäten sich einfach mit vim nachbilden lassen.

Einige solche Funktionalitäten allgemeinerer Art hatte ich im letzten Artikel bereits beleuchtet - auf diese gehe ich hier nicht nochmals gesondert ein. Ein von mir sehr häufig zurate gezogene Funktion ist Find Usage/Declaration - das Suchen der Deklaration oder aller Benutzungen eines bestimmten Symbols. Das lässt sich komfortabel in vim mittels der guten alten ctags abbilden: Mein Repository beinhaltet dafür eine (nicht von mir selbst erstellte) Konfiguration für cscope, die entsprechende Kommandos definiert. So gestatten es etwa s und g etwa vergleichbare Funktionalitäten zur Suche nach Symbolen auszulösen.

Indem man die Nummer der entsprechenden Fundstelle angibt, wechselt vim an die betreffende Stelle und öffnet die Datei vorher in einem neuen Buffer, falls nötig.

Wichtig war für mich an dieser Stelle die Navigation wieder zurück zu der Stelle, an der die Suche begann - besonders, wenn man auf diese Art und Weise einen ganzen Callgraph nachvollzieht. auch dafür hat vim selbstverständlich eine Lösung: die Kommandos dafür heißen und - damit springt man in der Liste der besuchten Location bufferübergreifend vor und zurück.

Das war bereits eine wichtige Funktionalität, die ich in meinen Arbeitsabläufen nur ungern vermissen wollte. Eine weitere war die Möglichkeit, aus der IDE - oder eben vim - heraus die aktuell editierte Klasse starten oder testen (wenn es sich um einen Unit-Test handelt) zu können. In älteren Java-Projekten habe ich noch nicht von ANT auf Maven umgestellt. Das hier Gesagte gilt für beide (und wahrscheinlich für viele andere Build-Tools), die konkreten Implementierungen im Repository beziehen sich aber auf ANT.

Zunächst muss man mittels 'compiler' in der Konfiguration das Build-tool festlegen. Dann wird mit dem vim Kommando :make dieses Tool gestartet. Gibt man hinter :make weiteren Text an, wird dieser an das Build-Tool als Kommandozeilenparameter durchgereicht. :make -f some_dir/build.xml target würde also das Target target in der Ant-Konfigurationsdatei some_dir/build.xml ausführen.

Damit startet man zunächst wie gesagt beliebige Targets des Buildprozesses. Möchte man aber wie oben beschrieben spezifische Klassen oder Tests ausführen (oder andere Targets dateispezifisch ausführen) geht das am einfachsten über Targets, die die Namen der Klassen oder Dateien aus der Kommandozeile übernehmen und dass diese dann korrekt gesetzt werden, ohne sie selber immer wieder tippen zu müssen, kann man mit folgenden Kommandos erreichen: :make -f some_dir/build.xml perform-selected-test -Dtest.file=%:r für ein Kommando, das einen Dateinamen erwartet und :make -f some_dir/build.xml run-selected-file -Drun.class=%:p für ein Kommando, das einen Klassennamen erwartet.

Geht beim Übersetzen etwas schief, kann man - mit geeigneter Konfiguration von efm vorausgesetzt - die Fehler in der Quickfix-Liste mittels :copen als Liste anzeigen, die sich mittels cclose wieder schließen lässt oder einfach mittels :cnext und :cprev zwischen den einzelnen Fehlern navigieren.

In der Konfiguration in meinem Repository ist vim übrigens so konfiguriert, dass sofort nach jedem Editiervorgang die betreffende Datei gespeichert wird, sodass man nicht vor jedem :make gezwungen ist, das noch manuell zu erledigen ...

Günstig fürs Programmieren - und eigentlich für jede Art von Arbeit am Text - ist auch eine schöne Integration von Git. Ich wählte dazu airblade/vim-gitgutter aus und wüsste nicht, was man mehr brauchen sollte. Eine hervorragende Anleitung zur Erschließung seiner Möglichkeiten gibt es im zugehörigen Repository.

Schön wäre es jetzt noch, wenn man direkt aus vim heraus auch debuggen könnte - aber das habe ich noch nicht erforscht.

Artikel, die hierher verlinken