Ich habe vor ein paar Wochen angefangen, ein bisschen vorzustellen, wie man als totaler Anfänger und Nicht-Nerd sinnvolle Dinge mit Git anstellen kann. Dazu kam dann die Empfehlung, einfach nicht mehr mit so etwas wie Word zu schreiben. Was sonst? Hier eine erste Idee: MultiMarkdown.
Nochmal auf die Schnelle: Warum nicht Word? Einmal, weil die Verarbeitung großer Dokumente in einem Office-Programm einfach ein monströser Schmerz ist und mitunter ein Tanz auf dem Vulkan, was die Stabilität und Bewahrung des Arbeitsstandes angeht. Und schließlich: Was ihr schreibt, ist Text. Text ist etwas großartiges, denn jeder und alles, was irgendwie Text verstehen oder verarbeiten kann, kann mit Text etwas anfangen, wenn er, sie, es an den eigentlichen Text kommt. Erinnern sich die Mac-User an die Umstellung von iWork ’09 auf das neue iWork? Alte Dokumente importiert, und schon gab es kein Zurück mehr. Oder die Migration zu .docx – was war das für ein Schmerz. Text ist in einem proprietären Dateiformat nicht gut aufgehoben. Er verbraucht mehr Speicher, er kann nicht inkrementell gespeichert, gelesen, gesichtert, versioniert und verglichen werden. Und er ist so nicht archivierbar. Mal so zum generellen Verständnis: Textdateien der allerersten Unix-Systeme sind heute noch ohne jede weitere Softwareinstallationen auf allen aktuellen Computern lesbar (sofern die Medien noch lesbar sind). Versucht das mal mit Word-Texten aus Versionen, die 10 Jahre alt sind.
Text als Text zu speichern und zu verarbeiten macht Sinn. Ich will nicht sagen, dass man ihn so ausdrucken muss – setzen und formatieren kann man Texte selbstverständlich mit Word, InDesign, LaTeX, mit was auch immer. Die Kernbotschaft ist nur: Solange nichts fertig ist, ist es sinnvoll, ohne Formatierung und alles zu arbeiten (da gibt’s auch eine ganze Menge Produktivitätsforschung zum ablenkungsfreien Schreiben).
Und wenn man Text als Text speichert, wird er Zeichen für Zeichen vergleichbar. Und darin liegt eine Menge Macht, Eure Texte zu schützen, verbessern und vielfältiger nutzbar zu machen – und die Freiheit, zu experimentieren. Wie man die ersten Schritte macht, diese Freiheit zu erreichen, habe ich hier beschrieben.
Für den Moment will ich der Einfachheit halber im reinen Text bleiben – mein erster Tipp für das fokussierte, archivier- und versionierbare Schreiben ist Markdown. Für Blogger ist Markdown nichts Neues, die meisten Blog-Systeme und CMS erlauben, Text direkt in Markdown zu schreiben und damit zu formatieren (Ein guter Überblick über Markdown und die Schreiweise auf die Schnelle hier. Ein genereller Überblick beim “Erfinder”: John Gruber). Für Wissenschaftler_innen essenziell ist es, gleich den Schritt zu MultiMarkdown zu machen – einerseits ist MultiMarkdown in der Lage, direkt in alle populären und unpopulären Dateiformate konvertierbar zu sein. Das Wichtigste ist aber die Erweiterung um Markdown um Dinge wie Fußnoten (mehr zu Multimarkdown hier).
Im Grunde ist Markdown absolut einfach zu schreiben: Einfach schreiben! Wer es einfach und leichtgewichtig mag, nimmt einen Texteditor wie Textwrangler, Textmate oder Sublime. Für die meisten, die von Word oder etwas anderem kommen, ist etwas mit Vorschau vielleicht besser – Multimarkdown-Composer kann das, der wunderbare kostenlose Crossplattform-Editor Atom kann das und mein Lieblings-Textprogramm Scrivener kann es auch.
So, und wie geht das nun?
Das wichtigste zuerst: Einfach losschreiben ist immer gut. Am Ende jedes Absatzes einmal auf Return macht die Sache nicht unbedingt schlechter. Aber erst zwei Returns machen einen echten Umbruch. Soll ein einzelner Return erzwungen werdenhart betrachtet werden, muss man zuvor zwei Leerzeichen tippen. Manchmal will man ja fett, kursiv oder beides schreiben: Entsprechende Passagen fasst man mit * oder _ ein:
*kursiv* und _kursiv_ **fett** und __fett__ ***fettkursiv*** und ___fettkursiv___
werden interpretiert als kursiv, fett und fettkursiv.
Manche Absätze sind etwas besonderes: Voran die Überschriften. Eine Überschrift beginnt mit einer Raute und einem Leerzeichen. Die Anzahl der Rauten entspricht der Ordnungsebene – und die Nummerierung wird bei der Bildschirm- / Druckansicht automatisch hergestellt.
# Überschrift erster Ordnung ## Überschrift zweiter Ordnung
Die erste und zweite Ordnungsebene sind besonders – es gibt hier eine alternative Schreibweise:
Überschrift erster Ordnung ========================== Überschrift zweiter Ordnung ---------------------------
Aufzählungen gehen entweder mit den Zeichen +, – oder *, um eine ungeordnete Liste zu erhalten, oder mit beliebigen Zahlen und einem Punkt direkt dahinter (es können, aber müssen nicht die richtigen Ordnungsziffern sein – sie werden automatisch berechnet). Die Ebenen kontrolliert man bei Listen mit dem Tabulator: Sieht dann so aus.
* Erste Ebene * Zweite Ebene 1 * Zweite Ebene 2 * Dritte Ebene 1. Nummer 1 3. Nummer 2 4. Nummer 2.1 5. Nummer 2.2 7. Nummer 3
Für Wissenschaftler entscheidend ist ja die Fußnote, und die funktioniert so: Im Text wird dort, wo die Fußnote erscheinen soll, [^erstefussnote] eingesetzt. Hierdurch wird hochgestellt die aktuell gültige Nummer der Fußnote hochgestellt erstellt und gesucht, ob es eine passende Definition gibt. Und die geht so:
[^erstefussnote]: Ein eigener Absatz, der mit den Fußnotenmarker beginnt, gefolgt von einem Doppelpunkt. Als Fußnote wird nun alles bis zum Ende des Absatzes. Erinnung: Zweimal Return tippen.
Erwähnenswert sonst: Ein Bild wird platziert mit ![Bildbezeichnung](Pfad zur Bilddatei). Eine Tabelle wird sinngemäß mit dem Pipe-Symbol | markiert. Die Kopfzeile wird mit einer Zeile Bindesstrichen abgesetzt und ein Doppelpunkt markiert die Textausrichtung. Schreibt ihr zwei Pipes hintereinander, verbindet ihr Zellen:
| Spaltenkopf 1 | Spaltenkopf 2 | Spaltenkopf 3 | |:----| :----:|----:| | linksbündig | zentriert | rechtsbündig | | einzelne Zelle | verbundene Zelle || | verbundene Zelle || einzelne Zelle | | alle drei Zellen verbunden |||
Tja – und das waren auch schon die Grundlagen zum Markdown mit der Multimarkdown-Befehlserweiterung. Probiert es mal aus und versioniert Eure Experimente mal fleißig mit Git bzw. SourceTree. Schaut mal, wie die Änderungsansicht eines Commits in Sourcetree oder Bitbucket aussieht. Ihr seht Zeichen für Zeichen in Grün, was neu ist und in Rot, was ihr gelöscht bzw. verändert habt. Und das geht quasi für immer und für beliebig viele Versionen parallel – so viel, wie ihr Speicher auf der Festplatte und / oder online habt. Und das ist doch mal ein Argument, oder?