Gastbeitrag beim Gewürzrevolver

Ich habe einen Gastbeitrag auf www.gewürzrevolver.de veröffentlicht:

Die Supergeheime Pfannkuchentorte

Going up

5

I I I I I I a I I I a a I a a I a a a I I a a a a a I I a I a I I I I I I I I I I a I a I a

150

I can not talk about anything.

200

I try to not to say those things that I am told not say.

300

I may not say some things, but still try not to talk like a baby. It is a hell of a job.

500

This is my try to deal with the problem of telling what the problem is and not to say any word that is not one of the 500 that people use most. It is really hard. For every word that gets lost from your word set gets, you need more words to say anything at all and it gets hard to understand what all this means, but I had help from a think-thing that does the some of the easy work. The idea came from a man, who’s work many people look at.

1000

This is a test, where I try to explain the test in the 1000 words people use most. The less words you have the more you have to talk. I had help from one of those think-thing that does some of the easy work. The idea came from a man, who’s work many people look at.

5000

This is an experiment, where I try to explain the experiment itself in the 5000 most common english words. It is actually pretty difficult not to use difficult terms, often you have to describe them. As a setup, I used a web based editor, that does the counting for me. The original idea is from a famous series of pictures from the Internet.

infinity

This is an experiment, where try I to explain the experiment itself in the n most common English words (where n is now finaly infinity, so I can say what I want). As it turns out, shrinking down your own vocabulary is pretty hard and you have to go back to the definitions. As a setup, I used a web based editor that does the counting for me. It was inspired by xkcd, a famous webcomic.

Photo by Jon Fife from here under CC-BY-ND.

Am Arch

(Titelbild von olibac unter CC BY 2.0 von hier)

Bei meiner Wahl der Distribution habe ich einen Fehler gemacht.

Ich hatte damals meine Auswahlkriterien folgendermaßen definiert:

  • modern: wenn es neues Zeug und coole Erfindungen gibt, will ich davon profitieren
  • stabil: so modern nun auch wieder nicht, dass ständig alles abstürzt
  • einsteigerfreundlich: ein System, das man auch als angagierter Anfänger meistern kann, eine Anlaufstelle für meine großen Haufen von Fragen
  • lebendig: ein System das beständig weiterentwickelt wird, mit Sicherheitsupdates, neuste Versionen und Kompatibilität für alles

Die Wahl fiel damit auf Fedora, und diese Konsequenz würde ich heute auch noch so ziehen. Aber meine Präferenzen haben sich geändert:

Hilfe aus dem RL

(Wer nicht weiß was das RL ist, der verbringt entweder zuwenig Zeit am Computer oder sehr viel zuviel.) Manchmal bleibt man stecken und dann hilft einem die ganze schöne Dokumentation nicht. Dann helfen auch keine Wikis, Hilfeforen, dann nützt Stack Overflow nichts und Reddit versagt. Manchmal muss man jemanden fragen. Ich rate also jedem, sich eind Distribution zu suchen, die in der unmittelbaren Umgebung auch schon benutzt wird.

Bei uns in der Uni läuft ausschließlich Ubuntu in den Computerräumen. In meiner unmittelbaren Umgebung werden außerdem Debian, Arch und Mint eingesetzt. Künftig werde ich das in meine Entscheidungen mit einfließen lassen.

Neues Kriterium:

  • RL-Support: zum über Dinge untehalten und sich gegenseitig Sachen zeigen kann

(Hätten wir unseren ursprünglichen Plan - gemeinsam auf Linux umzusteigen - direkt verwirklicht, dann wäre das kein Problem gewesen. Aber Till wechselt seine Betriebsysteme sobald der Wind sich dreht, da muss ich also in andere Richtungen suchen.)

Stabilität wird teuer erkauft

Kurz und gut: Die hoffnung ein modernes aber stabiles System zu bekommen war etwas zu optimistisch. Oft ist es mir schon passiert, dass ich von einer neuen Version eines Programmes gelesen habe, die dann aber nicht in den Repositorys aufgetaucht ist. Die Phrasen “gut abgehangen” und “bewährt” tauchen in diesem Zusammenhang immer wieder auf.

Weil ich dazu neige, die wenigen Programme die ich benutze auch etwas weiter auszureizen (das Wort “Poweruser” ist ja inzwischen so ausgelutscht das man es wahrhafig nicht nocheinmal in den Mund zu nehmen braucht) habe ich es trotzdem immer wieder geschaft, die Programme gegen die Wand zu fahren. Das passiert einfach.

Inzwischen weiß ich besser was ich will:

~~ modern: wenn es neues Zeug und coole Erfindungen gibt, will ich davon profitieren~~

Ich brauche nicht wirklich ein stabiles System. Ich brauche nur Backups und einen Packetmanager, der mir (auch gerne stündlich) die neusten Updates um die Ohren haut.

Konsequenz?

Ich bin weg von Fedora und komplett auf Arch Linux gewechselt. Zum Umzug später mehr.

Sane defaults for navigation keys?

(Image by Martin Fisch from here with a cc-by-sa license)

When I switched to Emacs, I thought there would be a consistent plan for navigation in a file (or buffer). I thought there would be a key for

  • character,
  • word,
  • line,
  • sentence,
  • paragraph,
  • the whole file

…and so on. In addition (so I imagined) there would be a key for every standard function you could apply to such a text component, like

  • copy,
  • paste,
  • kill,
  • mark,
  • jump forward or backward,
  • replicate,
  • exchage with neigbour,
  • move up and down

etc.

This way I would be able to build commands like “kill a word” (C-k w), “duplicate line” (C-r l) or “mark the paragraph” (C-m p) etc. It wouldn’t be necessary to remember those shortcuts, you could easily derive them. Damn, you could even combine them (use (C-l C-w C-w k) to delete one line and two words). And they would perfectly fit together with the universal argument (C-u).

I don’t even know why I expected it to be so. I just thought that the best editors (and Emacs claims to be on the top, no doubt) would have a concept like this (or better) with their shortcuts.

Instead, there are these short, but hard to remember combinations. Wouldn’t it make sense to have similar shortcuts for similar tasks? In Emacs, this doesn’t seem to be the case. For example, “Move to the beginning of the file” (M-<) and “Move to the beginning of this line” (C-a) just don’t seem to be connected. Neither are “Kill word” (M-d) and “Kill line” (C-k).

Of course, I am far away of being some good at Emacs. I don’t know any saints in the Church of Emacs to ask. There are two possibilities:

  1. There is a deeper sense in the defaults, I just don’t see it. It would be so kind if someone could give me some hint (you can find my mail address in the impressum). At some point, I will achieve wisdom.
  2. The default keys were never designed, the just grew that way. And while this would be very disappointing, this is still Emacs, isn’t it? Nothing would stop me to define my own shortcuts, much better then the old ones. Perhaps someone did this before me and there is some module I should know?

I am still not sure what I want it to be.

Im Mathestudium spielen Plots eine erstaunlich geringe Rolle (man möchte sich davor schützen, aus Bildern falsche Schlüsse zu ziehen). Trotzdem ist es manchmal nützlich/notwendig, es gibt hauptsächlich zwei Anwendungsfälle:

  • Mal schnell rausfinden, wie eine Funktion aussieht oder wie sich ein Parameter auswirkt
  • Eine schicke Grafik für ein Skript oder eine Präsentation erstellen.

Mit guten Plots kann man prima angeben. Und deshalb möchte ich hier mal die besten Plotter vorstellen, die ich im Laufe meines Studiums kennen und schätzen gelernt habe.

Um einen halbwegs sinnvollen Vergleich zu bekommen habe ich bei jedem Programm die Funktion f(x)= sin(1/x) geplottet.

Schnell und Flexibel

Für Zwischendurch und wenn man mal schnell eine Vorstellung oder Abschätzung des Graphen braucht. Die Programme sollen schnell zu bedienen sein und fix arbeiten. Wenn man mit Parametern arbeitet will man diese verschieben können und der Plot verändert sich live mit. Das Wort kompilieren will man hier nicht hören.

Quick Graph

Quick Graph

Plattformen:

  • iOS

Besondere Stärken:

  • mal schnell was plotten
  • großer Funktionsumfang auf mobilem Gerät

Ich habe seit Jahren keine andere App zum plotten auf dem iPhone als Quick Graph. Auf seinem Telefon will man ja meistens keine Wissenschaft machen sondern “mal schnell was rausfinden”.

Gibts in einer kostenlosen und einer Bezahlversion.

Grapher

Grapher

Platform:

  • Mac OS

Besondere Stärken:

  • vorinstalliert
  • (2D-)Vektorgrafik Export
  • Navigieren im Plot (verschieben, zoomen)
  • starke Mathematische Funktionen
  • Vektorfelder (2D und 3D)

Demos:

  • im Programmmenü unter Examples

Grapher ist das am meisten unterschätzte Programm auf dem Mac (finde ich).

Graphers Schwächen liegen in der Bedienung bei komplizierteren Funktionen. Bei schwierigeren Sachen muss man muss schon ein bisschen arbeiten, bis man das sieht was man wollte. Dafür funktionieren dann aber auch Dinge (Vektorfelder, Fallunterscheidungen, Spuren von Differetialgleichungen ect) die man sonst kaum findet.

Man sollte sich deswegen auf jeden Fall die mitgelieferten Beispiele anschauen, außerdem gibt es im Internet ein bisschen Dokumentation.

Graphing Calculator

Graphing Calculator

Plattformen:

  • Mac OS
  • Windows

Vorteile:

  • einfache Bedienung

Das Quick-Graph für den Desktop. Zum “schnell mal eben gucken” total gut. Starten, Funktion eintippen, Bild erscheint. Graphen exportieren geht leider nicht ordentlich.

Quick-Graph ist nicht herausragend, aber er macht was er soll und braucht keine Eingewöhnungszeit.

Google/Wolfram Alpha

Google Wolfram Alpha

Platformen:

  • Browser

Vorteile:

  • Verfügbarkeit

Geht natürlich auch. Wer nichts installieren will oder kann bekommt hier schnell was er braucht. Trotzdem würde ich nativen Programmen immer den Vorzug geben. Komplizierte Funktionen werden hier schnell knifflig und Parameter bekommt man nicht so einfach hin.

Seriös und elegant

Für Skripte, Präsentationen ect… Die Graphen sollen genau sein, gut aussehen, ordentlich beschriftet sein und wichtige Informationen vermitteln. Außerdem sollen verschiedene Ausgabeformate (pdf, svg, png..) unterstützt werden (Vektorgraphiken sind besser als Pixelgrafiken). Dafür ist es auch gerechtfertigt, etwas mehr Arbeit und Zeit zu investieren.

Weil es hier mehr um Programmieren als um Programme geht schreibe ich die Plattform nicht jedes mal dazu - auf Linux, OS X, BSD und Windows wird jedes der Programme laufen.

Gnuplot

Gnuplot

Demos

Besondere Stärken:

  • Datenpunkte plotten
  • programmierbar/automatisierbar
  • Open Source

Ich muss aber zugeben dass ich (damals) auf dem Mac Schwierigkeiten hatte Gnuplot zu installieren - gelohnt hat es sich trotzdem. Auf Linux hatte ich keine Probleme.

Wer es nicht installieren will kann Gnuplot auch im Browser ausführen (auch wenn man dann die meisten Vorteile verliert). Zum Beispiel hier oder hier.

Mit Gnuplot kann man hervorragend Messdaten visualisieren, plotten und diese Prozesse automatisieren. In meiner Bachelorarbeit musste ich den Verlauf eines chaotischen Algorithmuses nachvollziehen und hier kann man die Stärken des Programms wirklich ausspielen: Man lässt sich die Logdateien des Algorithmus ausgeben und lässt diese von Gnuplot auslesen und parsen. Auch bei großen Datenmengen ging das wunderbar, wo andere Programme schon in die Knie gegangen sind.

R

R

Demos

Besondere Stärken:

  • Daten visualisieren
  • Mit Zufallsdaten arbeiten
  • Nicht-Funktionen-Plots
  • programmierbar/automatisierbar

R ist eigentlch ein Statistik Programm. Aber es ist auch super im Daten visualisieren, besonders wenn es nicht um normale Plots geht sondern um Histogramme, Kuchendiagramme, Punktdiagramme, gefittete Funktionen ect.

Ich selbst kenne mich nicht so gut aus mit R (denn ich habe selten mit Wahrscheinlichkeitsrechnung zu tun), aber die Ergebnisse waren immer extrem gut.

Ach ja, eines noch: Der Name ist extrem dumm. Der Nächste der vorschlägt, etwas nach einem Buchstaben zu benennen sollte sich vorher genau überlegen, wie man im Internet nach Dokumentation dafür suchen soll.

LaTeX

PGFPlots

Besondere Stärken:

  • direktes Erzeugen im Latexdokument
  • extrem detailfreudig wenn nötig

(Wer nicht weiß was LaTeX ist sollte jetzt wirklich aufhören diesen Artikel zu lesen und sich schleunigst damit beschäftigen (etwa hier).)

Wenn man ein Dokument mit Latex erstellt liegt es nahe, auch die Graphiken damit zu machen. Geht auch. Das Paket heißt PGFPlots und basiert auf TikZ.

Die Vorteile liegen auf der Hand:

  • der Stil des Plots ist genau der des restlichen Dokumentes
  • wenn sich die Daten nochmal ändern sollten muss man nicht alles neu plotten sonder nur einmal sein File neu kompilieren
  • es gibt keine third-party, auf die man sich verlassen muss

Die Beispielseite zeigt auch recht deutlich, dass man es hier mit den Details wirklich ernst nimmt. Sehr (sehr) viele Varianten mit sehr feinen Unterschieden. Wer sich fragt ob man sich über Plots überhaupt so viele Gedanken machen kann, den bitte ich einfach einmal durch das Handbuch zu scrollen. (Man braucht es nicht lesen, einfach einmal von oben bis unten scrollen und ein paar Bilder anschauen.)

Ich habe mit PGFPlots selbst noch nicht gearbeitet, aber TikZ selbst schon sehr viel. Es ist immer viel Arbeit, aber man hat die absolute Kontrolle über alles und die Ergebnisse sind immer großartig gewesen.

Python

Python

Mit den meisten Programmiersprachen kann man auf die eine oder andere Weise plotten. Matplotlib ist eine Python Bibliothek, die das halt auch kann.

Besonders toll finde ich aber die xkcd-Style Plots.

Vor kurzem hat dieser Artikel ein paar Wellen geschlagen. Es geht darum, warum es (manchmal) gut ist wenn Bilder/Diagramme wie gemalt wirken. Dann achtet man nämlich nicht mehr auf die genauen Werte, sondern nur noch auf den Verlauf der Kurve. Manchmal will man ja genau das.

Und in Matplotlib ist das auch sehr einfach zu machen. Man ruft einfach vor dem plotten einmal matplotlib.pyplot.xkcd() auf und alles sieht aus wie von Randall Munroe persönlich gezeichnet. Mein Script sieht so aus:

import numpy as np
import matplotlib.pyplot as plt
plt.xkcd()
x = np.linspace(-1.0, 1.0, 1000)
y = np.sin(1/x)
plt.plot(x, y, 'r-')
plt.title('plotted in xkcd-style')
plt.ylabel('sin(1/x)')
plt.show()

Bilanz

Und welchen Plotter soll ich jetzt nehmen?

  • automatisiert Daten auswerten
    • Gnuplot
  • einzelne PLots für Folien und Skripte
    • Gnuplot (für weniger aufwendige Sachen)
    • Python (für Folien, der xkcd-Style kommt im Vortrag gut an)
    • Grapher (wenns ganz schnell gehen muss)
    • LaTeX (wenns um ungewöhnliche Details geht)
  • schnell eine Funktion anschauen
    • irgendwas

Emacs lernen, Tag 3

  • bin wieder dabei, los gehts
  • versuche, einen eingebauten Markdown-Mode zu finden. Es scheint keinen zu geben - wo kann ich Modes kennen lernen? Schau ich später nach, jetzt mach ich noch den Rest vom Tutorial zu Ende.
  • Dokumentation zu Befehlen gibt es mit C-h c für den Funktionennamen (was oft ausreicht) und mit C-h k BEFEHL für ein ausführlichere Beschreibung.
  • Heute komme ich nicht recht vorran, andere Sachen wollen erledigt werden.
  • Tutorial ist fertig. Kam nichts Interesantes mehr.
  • Was mache ich jetzt? Ich könnte mich wieder mit dem Handbuch beschäftigen. Oder ich schaue mal, welche Modes ich so brauchen könnte.
  • Ich schau mal nach Modes. Für Haskell gibt es eine tolle Anleitung , aber die ist so lang, dass ich das nach hinten verschiebe. Erstmal Markdown.
  • Ein Markdownpackage ist scheinbar nicht installiert, zumindest finde ich mit M-x nichts. Auch der Packetmanager findet nichts, das auf emacs und markdown matcht.
  • Es gibt ein Emacs-Wiki mit einem Eintrag zu einem Markdown Mode. Darin auch ein Link zur Website des Entwickler dieses Moduses.
  • Aha, ich soll emacs-goodies installieren. Kein Problem.
  • Der Emacs muss neu gestartet werden, damit die Completion den markdown modus kennt. Dann endlich ist es geschaft - ich hab Markdown-Syntax-Highlighting.
  • Der Markdown-Modus ist nicht so schmeichelhaft wie ich erhofft hatte. Wenn ich eine Liste mache und enter drücke, muss ich das * selbst tippen. Das ärgert mich ein bisschen. Immerhin gibt es nur 2 sinnvolle Dinge, die ich dann manchen wollen kann: Die Liste mit einem neuen Element fortsetzten (*) oder die Liste beenden (zwei Newlines).

Für heute muss ich Schluss machen, gibt viel zu tun.

Emacs lernen, Tag 4

  • So, jetzt würde ich gerne etwas programmieren. In Haskell
  • Mache ein neues File auf und fange an zu tippen.
  • Nach zwei Zeilen merke ich, dass das ohne Syntaxhighlighting keinen Spaß macht.
  • rufe https://github.com/serras/emacs-haskell-tutorial/blob/master/tutorial.md auf. Hoffentlich funktioniert das jetzt schön flott.
  • Ich soll (find-file user-init-file) evaluieren. Nach dem dritten Versuch kommt mir, dass ich die Klammern mit tippen muss. Wahrscheinlich ist das so bei Lisp.
  • Ich benutze heute mal den Graphischen Emacs um zumindest einer Menubar zu haben, mit der ich etwas anfangen kann.
  • Installiere den Haskell mode. Tada!
  • Beim Rumklicken im Menü stelle ich fest, dass es das Tutorium auch auf Deutsch gegeben hätte. Super.
  • Programmiere hin und her. Mir fehlen noch viele der wichtigen Shortcuts, aber ich hab schon wirklich Schwierigkeiten mit dem Courser. Immer wieder springe ich an stellen, wo ich nicht hin wollte.
  • Immerhin der Shortcut für Zwischenspeichern sitzt schon bombenfest. Das macht ja Hoffnung für den Rest.
  • Es hilft auch nicht dass das, was ich gerne coden würde nicht funktioniert.

Pause


Emacs lernen, Tag 5

  • Ein paar Tage sind vergangen seit ich das letzte mal einen Editor angefasst habe. Die Uni hat ein bisschen Zeit gefordert.
  • Es ist seltsam: Ich kann mich seit dem letzten mal an kaum einen Shortcut erinnern, aber wenn ich sie brauche sind sie da. Eigentlich cool, hoffentlich klappt das ab jetzt ja immer so.
  • Kein Syntaxhighlighting. Wie wechselt man nochmal den Modus?
  • C-x m, und der Editor erwartet von mir, dass ich eine Mail schreibe. Seltsam, das war es wohl nicht.
  • Immer noch nicht gefunden, dafür (in der graphischen Variante) unter ‘Options’ irgendwo Themes gefunden. Von den dort verfügbaren hat mir keines gut gefallen. Darum kümmere ich mich später.
  • Schön: Der Schortcut C-l scrollt so, dass der Courser in der Mitte ist - auch wenn das File noch gar nicht so lang ist. Wenn man einen Text schreibt ist das ganz angenehm: Oben das Geschriebene, unten noch leerer Platz. Das fühlt sich richtig an, ist für Code aber nicht nützlich.

  • Etwas Recherche: In ~/.emacs kann man auch konfigurieren, das Files mit bestimmten Endungen (.md oder .hs) in bestimmten modi geöffnet werden.
  • Gleichmal alles mit git versionieren. Ich hab ja schonmal geschrieben, dass ich meine Configs auf Github hochlade. Die .emacs liegt hier.
  • Arbeite jetzt zum ersten mal sinnvoll mit zweigeteiltem Editor. Einmal um diesen Text zu schreiben, der andere Teil ist für ein Haskellprogramm. Damit kann ich mir jetzt schön Stück für Stück meinen Haskellmode konfiguriern.
  • Was sich als etwas schwieriger herausstellt als gedacht.
  • Jetzt habe ich eine Promt im Emacs aufgemacht (cool, dass das geht) und bekomme den Rahmen nicht mehr zu.
  • Habs jetzt doch geschafft. Man geht in den Befehlsmods (M-x) und tippt “delete-window” ein. Bin ich sogar selbst drauf gekommen :)

Für mich reichts jetzt, ich geh ins Bett.

Bilanz der letzten Tage

Trotz längerer Pause habe ich das Gefühl, dass die zumindest die grundlegensten Befehle funktionieren. Emacs fühlt sich immernoch wie rießiges Monstrum an, dass ich nicht im Ansatz verstehe. Aber immerhin durfte ich schon ein bisschen von den Vorzügen kosten. Ich werde jetzt mal meinen Primäreditor auf Emacs umstellen und sehen, ob sich das bewährt.

Logbuch, Tag 2

  • Starte Emacs mit emacs -nw wie gestern gelernt.
  • Starte einen zweiten emacs, um das Logbuch mit zu tippen. Wie bekomme ich jetzt eine neue Datei? Hab keine Ahnung. Behelfe mich schließlich mit emacs -nw Blogeintrag.mdown. Das geht noch besser.
  • Weil die Pfeiltasten noch abgeklebt sind muss ich die Shortcuts benutzen um hin und her zu springen. Juhu!
  • Bevor ich loslege sollte ich wahrscheinlich lernen, wie man eine Textdatei speichert. Sonst gibts nachher Tränen.
  • Speichern geht mit C-x C-s
  • Der erste Hammer des Tages: Paste ist nicht, wie erwartet C-v sondern C-y für yank (großzügig übersetzt mit zurückreißen).
  • Yank ist komplizierter als gedacht.
  • Der Shortcut für undo (C-\macht auf amerikanischen Tastaturen mehr Sinn, weil dort das \ direkt unter dem Delete Key ist. Mist - ich habe eine Deutsche Tastatur an meinem Laptop und daran wird sich so bald auch nichts ändern.
  • Lerne ich lieber C-_ dafür, da muss man sich nicht so verrenken.
  • Undo wird erklärt, aber wie geht redo? Wird hier nicht erklärt, hätte ich aber gerne.
  • Warum ist undo eigentlich nicht C-z? AAAAAAAAAAAAAARrrrrrrgh! Ich wollte es doch nur ausprobieren, nicht den Emacs schließen! Nein! und das letzte mal, dass ich das Logbuch gespeichert habe ist ewig her.
  • Als ich die Datei wieder öffne und beginnen will, das verlorene wieder einzutippen, erhalte ich eine seltsame Nachricht:
  • Gibt es noch Hoffnung für meine Änderungen? Ich tippe s und der Dialog verschwindet - ohne die erwünschte Wirkung. Mist, das wäre mal ein Feature gewesen das ich brauchen kann. (später lerne ich: Hätte man ins Terminal einfach fg getippt wäre alles ok gewesen. Tja)
  • Viel zwischenspeichern ab jetzt. C-x C-s C-x C-s C-x C-s C-x C-s
  • Ein Bisschen Theorie über Buffer. Alles wo Text drin steht ist ein Buffer.
  • Man kann Buffer scheinbar wie Tabs benutzen, nur ohne die Tableiste. Dafür mit C-x b und dann den Namen von dem Tab eingeben.
  • Ein File öffnen geht mit C-x C-f. Das steht angeblich für “_f_ind file”, aber ich merke mir einfach _f_ile.
  • Mittagspause
  • Mir wird erklärt, dass die Datei vorhin nicht wirklcih weg war, sondern “nur in den Hintergrund gerückt”. C-z ist auch eigentlich kein Emacs-Befehl sondern geht direkt an das Terminal, in dem der Emacs läuft. Ich habe noch keinen Überblick über die vielen Schichten der Komplexen Programme, die hier laufen.
  • Es gibt eine Art Notificationcenter (eigentlich ein Buffer), wo alle eingegangenen Nachrichten (in der unteren Zeile aufgeführt werden. Langsam wird mir klar, warum Leute Emacs als Betriebssystem verstehen.
  • Nach dem ich 57% des Tutorials durchlaufen habe wird erklärt, wie man Emacs beendet. Ich habe es ja schon schmerzhaft selbst herausgefunden.
  • Die Echo Area (letzte Zeile, wo die Tastencombos angezeigt werden die man bereits getippt hat) hat einen eingebauten Delay. Das finde ich schlecht, sobald ich weiß wie hier alles läuft mache ich den Weg.
  • Zwischendurch was trinken, ist ja auch wichtig.
  • Jetzt wird es spannend. Es gibt Modes. Für verschiedene Programmiersprachen verwendet man verschiedene Modi, die Dinge verändern (zum Beispiel, wie ein Kommentar aussieht oder was ein Paragraph ist)
  • Es gibt Major-Modi und Minor-Modi. Man kann nur einen Major- aber mehrere Minor-Modi gleichzeitig benutzen.
  • Ich wechsle sofort vom Fundamental-(Major-)Mode in den Text-(Major-)Mode.
  • Fühle mich gleich besser. Es ist gut, wenn der Editor weiß, was ich tue (wenn ich es schon nicht immer weiß)
  • Der Minor Mode Autofill nervt eher. Was ich nicht mag, wird nicht benutzt. Ha!
  • Ich habe das Gefühl, ein großer Teil der Flexibilität von Emacs wird aus diesen Modes kommen.
  • Mein Kopf brummt. Gut dass heute nicht viel los ist.
  • Weiter machen: Searching
  • Die Incremental search ist genau das, was bei Sublimetext das Strg-I macht. Nur nicht fuzzy.
  • fuzzy search wird überhaupt immernoch viel zu sehr unterschätzt, außer Sublimetext macht das kaum einer richtig.
  • Mehrere Frames in einem Fenster. Den Teil überfliege ich nur, von sowas bin ich kein großer Freund. Schön, dass es geht.
  • Shortcut des Tages: als ein all-purpose “get out” command. Das ist gut, denn das drückt man sowieso meistens ganz panisch.

Bilanz, Tag 2

  • Diesen Text habe ich im Emacs getippt, Yeah! (und es ist mir nur einmal schief gegangen.
  • Das Tutorium habe ich zu 90% durch, sehr gut. Morgen suche ich mir was anderes zum Üben.
  • Leider hab ich, als es etwas zu Programmieren gab noch Schwierigkeiten gehabt und dann doch schnell Sublimetext genommen. Ein Moralischer Fehltritt.
  • Vielleicht suche ich mir morgen ein paar Modes heraus, die mich beim Schreiben wirklich unterstützen - heute habe ich von ihnen kaum was gemerkt.

Ich freu mich auf morgen.

Auf der Suche nach einem Editor beschäftige ich mit Emacs. Auf Emacs selbst gehe ich später noch genauer ein, hier geht es um meine ersten Kontakte damit.

Logbuch, Tag 1

  • Fange jetzt an, Emacs zu lernen. Ich google nach einem Handbuch und werde fündig: https://www.gnu.org/software/emacs/manual/emacs.html
  • Tippe emacs in die Konsole. Eine Hässliche GUI geht auf. Die will ich nicht. Tipp meines Nachbarn: Mit DISPLAY =emacs bekommt man einen Terminalbasierten Emacs. Schon besser. (Später lerne ich, dass es mit emacs -nw besser geht)
  • Außer mir sind noch andere Personen im Raum, die vergnügt Tipps geben Details aus Richard Stallmanns Leben rezitieren. Alle Tipps sind verwirrend.
  • Das Handbuch erklärt erstmal, wie toll Emacs ist. Doof.
  • Einer der Kollegen zieht aus seinem Schreibtisch zwei Seiten (klein gedruckte) Emacs Schortcuts: Die GNU Emacs Reference Card
  • Es gibt eine Tutorial, ähnlich dem vimtutor. Dieser ist aber natürlich erst später eingeführt worden, Emacs war erster! Das Tutorial bekommt man in Emacs mit C-h t.
  • Habe die letzten Minuten damit verbracht, Emacs abzuschießen (weil ich nicht mehr rauskam) und das Tutorial wieder aufzurufen. Wie man Emacs richig beendet habe ich noch nicht rausgefunden.
  • Mittagspause
  • Das Tutorial ist ganz gut. Manche von den Shortcuts kann ich sogar nachvollziehen. Ich lass das Handbuch beiseite und arbeitet mich durch das Tutorial.
  • Die Shortcuts in Emacs werden auf eine bestimmte Weiße aufgeschreiben:
    • M steht für Meta (also Alt)
    • C steht für Controll (also Strg)
    • - trennt mehrere Tasten, die man gleichzeitig drückt (im Gegensatz zu Leerzeichen, wo Sachen hintereinander gedrückt werden)
    • Kleine Buchstaben bedeuten die jeweilige Taste.
    • Den Emacs verlässt man mit C-x C-c. Das Bedeutet übersetzt: “Drücke erst Strg und X (gleichzeitig) und dann Strg und C(gleichzeitig). Dabei ist es kein Problem, wenn man Strg nicht loslässt.
    • Das Tutorial findet man mit C-h t, als Strg und h gleichzeitig und dann (ohne andere Tasten) ein t.
  • Bis jetzt kann ich mit originalen Emacs Shortcuts: Ein(e)(n) Buchstaben/Wort/Zeile/Seite vor/zurück springen. Hat mit den alten Tasten ja auch viel zu lange gedauert. Schön: Die Shortcuts sind mit den Tasten back, forward, previous, und next belegt. Das kann man sich ja sogar merken :)
  • Hmmm, C-a und C-e für Anfang/Ende der Zeile. Auf deutsch ganz gut zu merken, im Englischen sind mir die Shortcuts nicht gnaz so klar.
  • Man kann Befehle mehrfach hintereinander ausführen lassen. Das kenne ich noch aus meinen wenigen Vim-Erfahrungen. Schön, dass es hier auch geht.
  • Die Syntax dafür ist C-u Anzahl Eigentlicher-Befehl. Ich merke mir mal u wie in unit.
  • Jonathan neben mir beginnt mit zu fiebern. Er tippt wild Programme in Emacs, aber benutzt nicht genug Shortcuts. Ich klebe uns beiden die Pfeiltasten ab, um die Emacsshortcuts zu erzwingen.
  • In Zeile 316 des Tutorials das erste mal ein Hinweis darauf, wie man text manipuliert: “If you want to insert text, just type the text.” Bisher bin nur vor und zurück gesprungen.
  • Das Abkleben der verführerischen Tasten funktioniert: Selbst wenn man sie noch ein bisschen benutzen kann, fühlt man sich schlecht dabei.
  • Im Gegensatz zu Vim scheint es keinen Commandmode zu geben. Daraus folgen Zwei Dinge:
    • Wenn man was tippen will kann man das einfach tun
    • Wenn man Shortcuts benutzen will, sind diese länger (werden zum Beispiel mit C-x eingeleitet).
  • Es gibt einen Unterschied zwischen delete (einfach löschen) und kill (nur ausschneiden, aber noch zum wieder einfügen in den Buffer legen). Manche Befehle machen das eine, andere das andere. Meine Güte, das wird kompliziert.
  • Obwohl alle um mich herum Vi(m) benutzen, sind sie aufgeschlossen und fiebern mit. Der eine ehemalige Emacsuser gibt Ratschläge und entusiastisch vorgetragene Anekdoten zum besten.
  • An den Commandmode hatte ich mich scheinbar mehr gewöhnt als gedacht. Ab und zu suche ich ihn noch und wundere mich, wenn komische Dinge passieren (oder nicht passieren)
  • Mit C-u 100 r kann man Hundert rs auf einmal schreiben :)
  • rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
  • Dieses Log schreibe ich im Moment noch in Sublime Text, aber langsam fühle ich mich tatsächlich fit genug, das auch direkt in Emacs zu machen.

Bilanz, 1 Tag

  • Hat Spaß gemacht heute.
  • Viele ungewohnte Shortcuts gelernt, auch für Dinge die ich schon vorher anders konnte. (Ich soll zum Beispiel kein Page Up/Down und keine Pfeiltasten benutzen)
  • Einige Dinge kommen einem zuerst komisch vor, machen aber später Sinn. (Zum Beispiel werden einzelne Buchstaben immer gelöscht (delete), ganze Worte, Sätze und Zeilen aber gekillt, so dass man sie schnell an anderer Stelle wieder einfügen kann.)
  • Das Tutorium ist besser geschrieben als der Vimtutor. Dort werden die Shortcuts hauptsächlich eingeführt, bei Emacs wird erklärt, warum sie sinnvoll sind. Das macht viel aus.
  • Von der wahren Macht von Emacs habe ich noch nicht kosten dürfen. Alles bisherige kannte ich anders auch aus Sublimetext, abgesehen von dem C-u, C-l, M-a und M-e.

Morgen mache ich weiter und schreibe das Log in Emacs.

Wer nach dem Urlaub nach Hause kommt muss erstmal einiges an Haushalt erledigen: Sachen einräumen, den Kühlschrank auffüllen, Wäsche waschen, durchfegen, Blumen gießen, sich bei Nachbarn und Freunden melden und sich um die Post kümmern.

Im Digitalen fallen erstaunlich ähnliche Dinge an. Nach einer Woche Offline-Abstinenz in Italien (nur gelegentlich unterbrochen von kurzen Netz-Momenten) geht es ans Liegengebliebene:

  • RSS-Nachrichten der letzten Tage durchgehen
    • zumindest grob, vielleicht war ja was interessantes dabei
  • RSS-Feeds auffrischen
    • Von ein paar schönen Blogs habe auf der Heimfahrt gelesen, die kommen dazu.
    • Ein paar Nachrichtenseiten gehen mir langsam zu sehr auf den Keks, weg damit.
  • Späterlesendienst ausschütteln
    • auf der Fahrt habe ich zwar einiges weggelesen, aber mir ist aufgefallen dass ich schon seit Monaten kein Inbox Zero mehr hatte.
    • Was ich in den letzten 8 Wochen nicht gelesen habe lese ich wohl nicht mehr. Hier darf großzügig gelöscht werden.
  • Mails beantworten
    • Zum Glück nicht zu viele, dafür aber ein paar Wichtige.
    • Ham zu Ham, Spam zu Spam
  • Sich in den Sozialen Netzwerken blicken lassen
  • Urlaubsfotos archivieren
    • Alle Fotos von Allen Urlaubsteilnehmern sollen auch allen zur Verfügung stehen.
    • Wird Zeit dass ich mal eine Mediagobblin Instanz aufsetzte. Hmmmm, später.
  • Frisch geplante Projekte müssen auf Tauglichkeit überprüft und in den Alltag eingebettet werden, ohne dass die Arbeit drunter leidet

Tatsächlich ist es genau wie Hausarbeit: Es tut gut, mal alles liegen zu lassen. Dannach fängt man an und je mehr man tut desto mehr müsste man noch machen. Ganz sauber wird es nie, nur sauberer.

Wer Code schreiben will, braucht einen Code-Editor. Es lohnt sich, sich einen Guten zu suchen, denn man wird viel Zeit mit ihm verbringen und er ist schnell ein essentieller Teil des Computers.

Ich selbst bin noch immer auf der Suche nach einem Editor, der mich restlos zufrieden stellt.

Was ich will

Ein Editor mit dem ich glücklich werde müsste ein paar Mindestanforderung erfüllen.

  • Open Source
  • Erweiterbar durch Plugins
  • Cross-Platform zumindest für alle Unixoiden Systeme. Wer weiß schon was die Zukunft bringt.
  • schnell (auch bei wirklich großen Files mit mehr als 100000 Zeilen)
  • durchdacht und nicht durchwachsen. Man merkt einem Programm an ob es designed wurde oder mit der Zeit gewachsen ist.
  • Starken Language Support für die Sprachen, die ich oft benutze. Das ist im Moment hauptsächlich Haskell und Markdown.
  • Starke Shortcuts die das editieren erleichtern und schneller machen
  • Git Integration gerne auch durch Plugin
  • Build um Code auch mal direkt im Editor auführen zu lassen

Außerdem gibt es noch ein paar Standardfeatures, die ohnehin bei den meisten Editoren dabei sind, wie

  • Zeilennummern
  • Wortergänzung
  • Syntax Highlighting
  • Klammer Support für runde, eckige, geschweifte, spitze Klammern und was für die jeweilige Sprache noch als Klammer dient (bei Markdown zum Beispiel auch _, __, *, ** etc)
  • Distractionfree Programming (eher wenn man normalen Text schreibt und dafür keine Seitenleisten, Menüleisten, Vorschau… braucht)

Shortcuts

Shortcuts die ich besonders häufig verwende sind

  • Zeile löschen
  • Zeile dublizieren
  • Zeile verschieben (nach oben oder unten)
  • Zeile markieren
  • Wort markieren
  • nächstes gleiches Wort markieren (Multicursor)
  • zu Wort springen (mit fuzzy search oder regulären Ausdrücken)

Ich lerne langsam auch neue dazu (man muss sie ja dann auch verwenden), aber das braucht immer etwas Zeit. Im Idealfall finde ich einen Editor der all das erfüllt und verwachse so sehr mit ihm, dass alle Shortuts intuitiv werden.

Besonders toll (auch wenn ich es nie gelernt habe) finde ich die modularen Shortcuts beim vim:

  • man tippt 3 um den Befehl dreimal auszuführen, d für delete und aw für a word. Der Editor entfernt dann die nächsten 3 Worte.
  • man tippt d für delete und 0 für Anfang der Zeile. Der Editor entfernt alles vom Anfang der Zeile bis zum Courser.
  • man tippt 10 für zehnmal und x für delete Character und die nächsten 10 Buchstaben werden entfernt.

Wer das einmal verinnerlicht hat will das sicher nicht mehr missen.

große Files

Manchmal verprogrammiert man sich und erzeugt aus Versehen rießige Dateien. Manchmal muss man Logfiles anschauen und bearbeiten, die seit Jahren geschreiben werden. Manchmal muss man eine seltsame Datei im Editor aufmachen, weil man dann vielleicht versteht welches Format sie hat (funktioniert öfter als man denkt, probiert das mal mit PDF/Bilddateien/Websiten).

Deshalb muss mein Editor mit Files umgehen können, die seeeeeehr lang sind.

Language Support

Knifflig, da will man ja immer was anderes.

Für Markdown reicht mir eine Semi-Vorschau im Editor und ab und zu ein Blick auf das gerenderte (html-)Dokument im Browser. Immerhin ist Markdown (Aktuelle Lösung: Sublimetext im Distraction Free Mode mit den Paketen MarkdownEditing (dark) und Markdown Priview und Firefox mit dem Plugin Auto Reload).

Da kann man sich konzentrieren.

Für Haskell (und alle Sprachen die ich danach lerne) will ich die krasseste Unterstützung die auf diesem Planeten möglich ist, bitte. Ich wünsche mir

  • Syntax Highlighting
  • Qualifizierte Vorschläge und Ergänzungen
  • Snippets
  • Automatische Einrückung
  • Cabal Support
  • Linting
  • Warungen bei unnötigen imports
  • integrierte Documentation (auch zum offline abrufen)
  • Benchmarking
  • Automatische Berechnung von Signaturen

Sprich, wenn ich Code schreibe soll mein Editor zur mächtigen IDE werden. Das ist alles möglich (und im ghc schon angelegt), also keine Ausreden!

Die Kandidaten

Es gibt ein paar Kandidaten die erstmal in die engere Auswahl kommen. Ich werde zu den Einzelnen noch etwas schreiben, vielleicht (hoffentlich) kommen ja noch was dazu. Bis jetzt habe ich auf dem Schirm:

  • Sublime Text
  • Vim
  • Atom
  • Emacs

Ich habe schon einige Editoren getestet und mit den meisten bin ich nicht recht warm geworden. Von den vielen seien hier erwähnt:

Wer noch Tipps für mich hat, immer her damit. Die Mailadresse steht zum Beispiel im Impressum.

To be continiued…