Einleitung
Ich entwickle seit mehr als 25 Jahren Perl. Den Code habe ich über die Jahre in vielen Editoren geschrieben. Nach mehreren Jahren mit Sublime bin ich wieder beim Emacs gelandet (siehe dazu auch meinen Gründungsbeitrag in meinem Blog emacs-lernen). Über die Jahre habe ich mir diverse Konfigurationsschnipsel zusammengesucht, die meine IDE für Perl formen. Ich beschreibe hier meinen Stand, mit dem ich schon ganz gut arbeiten kann. Andere mögen andere Einstellungen nutzen (s. LanX-Folien).
Grundlage: cperl-mode
Die Basis für alles ist der cperl-mode. Er kümmert sich um all die netten
Kleinigkeiten, die so grundlegend sind, dass ich fast vergessen hätte, ihn
aufzuführen. Die für mich wichtigsten sind diese:
- Syntax-Highlighting: Einfärbung des Code je nach syntaktischer Einheit
- automatische Einrückung
- Anzeigen des entsprechenden Gegenstücks bei Klammerungen
Wir schreiben 2018. Standard für Perl ist im Emacs immer noch der Perl-Mode –
warum auch immer. Jeder, den ich kenne, nutzt den cperl-mode; dieser sollte der
Standard sein.
Übernahme der Umgebungsvariable PATH
Ich bin auf dem Mac unterwegs. Im Emacs rufe ich gelegentlich externe Programme
auf, z.B. perltidy. Damit diese korrekt gefunden werden, muss der Suchpfad aus der
Umgebung der Shell korrekt übernommen werden. Dafür sorgt exec-path-from-shell.
Prüfung des Quelltextes während des Schreibens mit flycheck
Flycheck prüft den Text während des Schreibens auf Fehler. Aus
Textverarbeitungen kennen wir die Schlangenlinien unter Worten oder Phrasen,
die Fehler in der Rechtschreibung oder Grammatik anzeigen. Flycheck macht das
im Emacs für beliebigen Text. Und wenn ich den cperl-mode angeschaltet habe,
prüft er den Perl-Quelltext.
Flycheck ist vielleicht der wichtigste Baustein meiner Konfiguration, der mich
schneller entwickeln lässt. Wie macht er das?
Es gibt hier zwei Befehle, die nacheinander ausgeführt werden. Mit perl -c wird
die Syntax geprüft. Fehler werden durch rote Schlangenlinien angezeigt. Wenn
ich mit dem Cursor zu der entsprechenden Stelle gehe, wird mir der Fehler im
Minibuffer angezeigt (oder als Tooltip, wenn ich mit der Maus unterwegs bin).
(Bild)
Ein häufiger Fehler, den mir perl bei dieser Prüfung anzeigt, betrifft fehlende Module.
Damit perl auch meinen gesamten Code kennt, ergänze ich den Modulsuchpfad für
die Prüfung durch eine Angabe in .dir-locals.el.
Den Stil meines Codes prüft Emacs anschließend mit perlcritic. Etwaige Funde
werden mir durch eine gelbe Schlangenlinie angezeigt. Der passende Text zum Fund
wird mir auch hier im Minibuffer und als Tooltip angezeigt.
(Bild)
Und warum macht mich das jetzt schneller? Ohne Flycheck finde ich meine Fehler
erst viel später heraus – frühestens dann, wenn meine Tests sie aufdecken; mit
Glück während der Ausführung des Programms; mit Pech gar nicht. Dank Flycheck
sehe ich die Fehler viel eher und kann sie gleich korrigieren. Ich muss dann
auch nicht gedanklich zwischen den Kontexten hin- und herspringen.
Code-Formatierung mit perltidy
Dank perltidy mache ich mir über Code-Formatierung keine Gedanken mehr. Ich habe
mir perltidy.el aus dem Emacs-Wiki (Link) installiert und auf C-c t gelegt. Mein
Arbeitsablauf sieht mittlerweile so aus, dass ich mich auf die automatische
Einrückung vom Cperl-Mode verlasse, und alles andere von Perltidy machen lasse.
Auch dies macht mich schneller. Früher habe ich von Hand Klammern gesetzt, Variablenzuweisungen von Hand am Gleichheitszeichen ausgerichtet, Einrückungen repariert und diversen anderen Kleinkram am Layout des Quelltextes geschraubt.
Heute schreibe ich den Code hin und drücke anschließend C-c t. Ich verschwende
keinen Gedanken mehr an die Formatierung. Dadurch schleppe ich im Geiste weniger
Ballast mit.
Ich bin allerdings noch nicht soweit, dass ich das Formatieren automatisch beim Speichern der Datei erledigen lasse.
Demnächst ausprobieren
Ich habe buchstäblich seit Jahren vor, automatische Vervollständigung von
Bezeichnern mit perl-complete (Link) auszuprobieren. Das Werkzeug soll angeblich
Bezeichner kontextabhängig vervollständige und meinen Code so weit verstehen,
dass passend zum Inhalt einer Variablen die Methoden ergänzt werden.
Aus irgendeinem Grunde habe ich dieses Werkzeug noch nicht zum Laufen bekommen. Ich vermute, dass diese zusätzliche Eigenschaft meiner Entwicklungsumgebung ganz praktisch wäre, wirklich vermisst habe ich sie noch nicht. Wahnsinnig schneller werden würde ich vermutlich auch nicht.
Außerdem habe ich noch PerlySense (Link) auf dem Radar. Dieses eine Tool ist ein
IDE-Backend für Perl und bietet Schnittstellen zu Editoren. Da ich mich sehr
fürs Testen interessiere, ist das für mich spannendste Feature von PerlySense das
Herstellen der Verbindung zwischen Test und Code.
Wenn ich die Dokumentation richtig deute, dann nimmt sich PerlySense nach
Messung der Testabdeckung durch cover (Link) die angelegte Datenbank und
ermittelt daraus, welche Subroutine in welchem Test getestet wird. Im Emacs kann
ich dann zwischen Test und dem getesteten Code hin- und herspringen. Das würde
noch einen kleinen Geschwindigkeitsschub bringen.
Was für mich nicht funktioniert hat
Vor Jahren habe ich mal mit parametrisierten Vorlagen herumgespielt. Das einzige, wofür ich die Vorlagen ersthaft genutzt habe, war das Schreiben von POD bei Erstellung einer Subroutine. Und das hat für mich nicht funktioniert, weil es meinem Arbeitsablauf zuwiderläuft: Dokumentation schreibe ich zuletzt – und zwar für den Code, der am Ende meiner Arbeit übrig geblieben ist.
Ausblick
Wie alles beim Emacs ist dies nur der momentane Stand. Ich werde auf diesem Blog gelegentlich darüber berichten, wie meine Entwicklungsumgebung aussieht. Wer mich grundsätzlich bei meiner Reise mit dem Emacs begleiten möchte, kann das in meinem anderen Blog machen. (link) Meine Emacs-Konfiguration liegt auf Gitlab. (link)