Anfang August stand hier der Beitrag darüber, warum ich mir eine App gebaut habe: weil kein Programm zu meinem Schreiben passte und ich irgendwann müde war, den Weg zwischen Ordnung, Text und Satz jedes Mal von Hand zu gehen. Damals war Schreibprojekte bei Fassung 1.3.0.

Vier Wochen später steht sie bei 1.12.0, und das ist mehr geworden als eine Reihe kleiner Verbesserungen. Es gibt einen roten Faden: Die App hört auf, nur die Verwaltung meiner Texte zu sein, und fängt an, beim Schreiben dabei zu sein.

Der größte Schritt in diese Richtung ist der Planer.

Der Text hat eine Reihenfolge. Der Ordner nicht.

Ich schreibe viel, und fast nie fange ich mit einer fertigen Gliederung an. Die Struktur wird mir erst nach und nach klar. Ich beginne mit einer groben Vorstellung, und dann merke ich beim Schreiben, dass zwei Abschnitte eigentlich einer sind. Dass ein Nebengedanke ein eigenes Kapitel braucht. Dass die Reihenfolge, die im Kopf plausibel klang, auf dem Papier nicht trägt. Das ist kein Planungsfehler, das ist der Vorgang: Die Gliederung entsteht im Schreiben und ändert sich bis zuletzt.

Ein Text, dessen Struktur sich dauernd bewegt, wohnt aber in einem Ordner, dem Struktur vollkommen gleichgültig ist.

Bei allem, was länger als ein paar Seiten ist, sieht mein Projektordner ungefähr so aus: eine Hauptdatei, ein Ordner includes/, darin ein Dutzend .tex-Dateien mit Namen wie kap03.tex. Die einzige Stelle, an der die Reihenfolge des Dokuments steht, ist ein Block aus \input-Zeilen in der Hauptdatei.

Das funktioniert, und es hat drei Probleme.

Ein Kapitel zu verschieben heißt, Zeilen zu verschieben. In einer Datei, in der daneben die Präambel-Einbindung, das Titelblatt und das Literaturverzeichnis stehen. Man macht es einmal falsch, baut, sucht den Fehler, macht es richtig.

Die Struktur ist nicht sichtbar. \input{includes/kap03} sagt nichts darüber, was in Kapitel 3 passiert. Der Finder sagt es auch nicht. Ich wusste das immer nur, solange ich am Text saß — und nach zwei Wochen Pause nicht mehr.

Und man sieht nicht, wo man steht. Welcher Abschnitt ist fertig, welcher ein Entwurf, welcher nur eine Überschrift mit einer Idee darunter? Diese Information hatte ich nirgends. Ich hatte sie in Notizdateien, in Kommentaren im Quelltext, auf Zetteln.

Der Planer

Der Bereich „Planer“ (⌘6) hält einen Baum aus Karten. Jede Karte hat einen Titel, eine Kurzfassung, eine Notiz für mich selbst, einen Status (Idee, Entwurf, Überarbeitung, Fertig) und ein Wortziel. Aus der Reihenfolge der Karten ergibt sich die Reihenfolge des Dokuments.

Der Planer: Kartenbaum als Gliederung, Status je Karte, Umfang gegen Wortziel
Der Planer: Gliederung, Status je Karte, Umfang gegen Wortziel

Es gibt schon eine Gliederungsansicht in der App — die Spalte rechts im Editor, die die Überschriften des Quelltextes anzeigt und beim Klick dorthin springt. Der Planer ist ihr Gegenstück: Die Gliederung liest den Quelltext, der Planer schreibt ihn. Und er tut es auch dann, wenn es noch keine Zeile Text gibt.

Das ist der Teil, der mir am meisten hilft. Ich kann die Struktur umbauen, während der Text wächst, ohne im Quelltext zu operieren: eine Karte an eine andere Stelle ziehen, zwei zusammenlegen, eine Stufe tiefer rücken. Das Dokument folgt der Anordnung, nicht umgekehrt. Was früher eine kleine Operation an der Hauptdatei war, für die ich erst den Kopf frei haben musste, ist jetzt eine Bewegung, die ich nebenbei mache — und weil sie nichts kostet, probiere ich Umstellungen überhaupt erst aus, statt sie mir vorzunehmen und dann sein zu lassen.

„Karte“ und nicht „Kapitel“

Der Typ heißt Karte, und das ist keine Wortklauberei. Ein Roman staffelt Teil → Kapitel → Szene. Ein Bericht staffelt Abschnitt → Unterabschnitt. Ein Aufsatz bleibt flach. Hätte ich „Kapitel“ gebaut, hätte ich für den Rest eine Ausnahme gebraucht — und Ausnahmen sind der Anfang davon, dass ein Werkzeug nur noch für den einen Fall taugt, für den man es zuerst gebaut hat.

Deshalb ist der Planer auch für jedes Dokument da. Keine Vorlage ist ausgenommen, LaTeX und Markdown sind gleichermaßen dabei, und es gibt nichts freizuschalten.

Teildateien sind freiwillig

Das war die zweite Entscheidung, und im Nachhinein die wichtigere. Eine Karte kann mit einer Datei verbunden sein — muss aber nicht. Hat keine Karte eine Datei, rührt der Planer die Hauptdatei überhaupt nicht an. Dann ist er ein Notizbrett, auf dem ich eine Struktur ausprobiere, bevor ich weiß, ob ich sie will.

Das ist kein Übergangszustand, den man später „richtig“ macht. Das ist ein vollwertiger Betriebszustand, und ich benutze ihn öfter als den anderen.

Drei Sichten auf denselben Stand

Gliederung, Korkbrett und Tabelle zeigen dieselben Karten. Der Aufklappzustand gilt überall, und die zuletzt gewählte Sicht steht beim nächsten Start wieder da.

Der Planer als Korkbrett: eine Karte je Abschnitt, mit Kurzfassung und Status als Farbe am Rand
Das Korkbrett: eine Karte je Abschnitt, Kurzfassung sichtbar, Status als Farbe am Rand

Im Korkbrett steht die Kurzfassung auf der Karte — das ist die Sicht für die Frage „worum geht es hier eigentlich“. Die Tabelle stellt Titel, Status, Wörter, Ziel, Datei und Kurzfassung nebeneinander; das ist die Sicht für „wie weit bin ich“.

Der Planer als Tabelle: Titel, Status, Wörter, Ziel, Datei und Kurzfassung nebeneinander
Die Tabelle: Titel, Status, Wörter, Ziel und Datei nebeneinander

Die Tabelle sortiert bewusst nicht, und daran habe ich länger gesessen, als es aussieht. Eine Tabelle mit klickbaren Spaltenköpfen ist auf dem Mac so selbstverständlich, dass ihr Fehlen wie ein Versäumnis wirkt. Aber die Reihenfolge der Zeilen ist hier die Reihenfolge des Dokuments — und ⌃⌘↑ zum Hochschieben einer Karte würde nach einer Sortierung nach Wortzahl etwas anderes meinen als das, was dasteht. Lieber eine Tabelle, die weniger kann, als eine, die in einem von fünf Fällen lügt.

Die Karte

Das Kartenblatt mit Titel, Kurzfassung, Notiz, Status, Wortziel und der verbundenen Teildatei
Das Kartenblatt: Titel, Kurzfassung, Notiz, Status, Wortziel und die Datei

Ein Doppelklick öffnet sie. Unten steht die Verbindung zur Datei: anlegen, im Editor öffnen oder wieder lösen. Hat jemand die Datei im Finder gelöscht, sagt die Karte es.

Und wenn aus einer Karte eine Teildatei wird, richtet sich die Überschrift im Gerüst nach Dokumentklasse und Kartentiefe: In scrbook und scrreprt beginnt die oberste Reihe bei \chapter, sonst bei \section, je Stufe tiefer eine Ebene weiter. Bei Markdown zählt allein die Tiefe. Das klingt nach einer Kleinigkeit, aber die Alternative ist, dass jede neue Datei mit einer Überschrift beginnt, die man erst von Hand richtigstellt — und das tut man dreimal und dann nicht mehr.

Aus einem vorhandenen Dokument

Der Planer wäre nur die halbe Miete, wenn er nur für neue Projekte taugte. Meine langen Texte gab es ja schon.

„Aus Quelltext übernehmen“ macht aus den Überschriften Karten — gestaffelt relativ zur kleinsten vorkommenden Ebene, damit ein Aufsatz mit \section genauso richtig herauskommt wie ein Buch mit \part.

Das Blatt „Aus Quelltext übernehmen“ mit dem Schalter für die Einbindungen
„Aus Quelltext übernehmen“ mit dem Schalter für die Einbindungen

In der ersten Fassung las das nur die Hauptdatei — und bei einem Projekt mit ausgelagerten Kapiteln stehen dort genau null Überschriften. Es kamen null Karten heraus. Das war die Funktion, die genau bei den Dokumenten versagte, für die sie gedacht war.

Seit 1.11.0 folgt sie der Einbindungskette: Bei LaTeX werden \input und \include verfolgt, rekursiv und mit Zyklenschutz; die Überschriften erscheinen an der Stelle der Einbindung. Bei Markdown, wo es kein \input gibt, zählen die Dateien des bestehenden Plans — genau die, die pandoc beim Bauen an die Hauptdatei hängt.

Und die Karten bleiben dabei verbunden: Die erste Überschrift jeder eingebundenen Datei behält deren Pfad, sodass Wortstände, Umsortieren und die Anzeige fehlender Dateien sofort greifen. Eine Datei ohne Überschrift und eine, die sich nicht lesen lässt, werden zur Karte mit dem Dateinamen. Nichts fällt still weg — das war mir wichtiger als ein aufgeräumtes Ergebnis.

Das Übernehmen liest dabei nur. Am Dokument ändert sich nichts. Ein Werkzeug, das beim ersten Ausprobieren an einem gewachsenen Manuskript herumschreibt, probiert man kein zweites Mal aus.

Und wieder zurück ins Dokument

Der heikelste Teil. Der Planer muss irgendwann in die Hauptdatei schreiben, sonst ist er Dekoration. Aber die Hauptdatei gehört mir, nicht ihm.

Die Lösung ist unspektakulär und genau deswegen richtig: Bei LaTeX gehört dem Planer ein \input-Block zwischen zwei Marken. Alles außerhalb bleibt, wie ich es gesetzt habe. Bei Markdown schreibt er gar nichts ins Dokument — beim Bauen übergibt die App die Dateien einfach gemeinsam an pandoc, ein Gegenstück zu \input braucht Markdown damit nicht.

Und geschrieben wird nur, wenn sich die Dateifolge geändert hat. Ein neuer Titel auf einer Karte, ein Status von „Entwurf“ auf „Fertig“, eine Notiz — das alles geht das Dokument nichts an und erzeugt deshalb auch keine Änderung darin. Sonst hätte ich bei jedem Klick im Planer einen Eintrag in git status und einen ausgelösten Auto-Bau.

Was er bewusst nicht tut

Er legt Teildateien an, löscht aber keine. Er merkt nicht, wenn eine Datei umbenannt wird. Er vergibt nie \part. Und eine Karte, deren Datei jemand im Finder gelöscht hat, meldet er zwar — lässt sie aber im Bau stehen: Einen Abschnitt still wegzulassen wäre schlimmer als ein Fehler, der sagt, was fehlt.

Das ist der Unterschied zwischen einem Werkzeug, dem ich einen fertigen Text anvertraue, und einem, dem ich hinterherräume.

Was sonst dazugekommen ist

Der Planer war der große Brocken. Daneben sind vier Dinge entstanden, die alle demselben Muster folgen: Fragen beantworten, die ich mir vorher von Hand beantwortet habe.

Finden (⌘7) liest das ganze Projekt und beantwortet vier Fragen — alle \label und \ref (ein Verweis ins Leere wird gemeldet, eine Marke, auf die nichts zeigt, als Hinweis), die figure- und table-Umgebungen samt der Bilder, die niemand einbindet, die Aufgaben aus % TODO, FIXME, XXX und OFFEN — dazu Suchen und Ersetzen über das ganze Projekt.

Der Bereich „Finden“: Marken und Verweise über das Projekt, mit gemeldetem offenem Verweis
Finden: Marken und Verweise über das Projekt hinweg

Stil (⌘8) rechnet, es urteilt nicht: wie viele Sätze, wie lang im Schnitt, welche die längsten sind, welche Wörter sich häufen und wie viele Füllwörter darunter sind. Die Schwelle für „langer Satz“ lässt sich verstellen, weil für Erzählendes eine andere gilt als für Sachtexte. Ich wollte ausdrücklich keine Lesbarkeitsnote und keine grünen Häkchen — ich wollte die Zahlen und die Entscheidung selbst behalten.

Der Bereich „Stil“: Satzbau, lange Sätze und Wortgebrauch
Stil: Satzbau, lange Sätze, Wortgebrauch — gezählt, nicht bewertet

Der Assistent ist eine einklappbare Spalte rechts im Editor, die mit einem lokal laufenden Ollama spricht. Kein Dienst im Netz, kein Schlüssel, nichts verlässt diesen Rechner. Zwei Regeln waren mir dabei wichtig: Er darf in den Quelltext schreiben, aber erst nach Bestätigung — es entsteht immer erst ein Vorschlag mit angezeigtem Unterschied, und übernommen wird er auf Klick. Und geschrieben wird in den Editor, nicht auf die Platte: ⌘Z nimmt es zurück. Was er überhaupt zu sehen bekommt, bestimmen vier Schalter — markierter Text, ganze Datei, Umgebung der Cursorstelle, Angaben zum Projekt. Was aus ist, geht nicht mit.

Editor mit Markdown-Hervorhebung, Bausteinleiste und der Assistenzspalte rechts
Der Assistent sitzt neben dem Text und spricht mit einem lokalen Ollama

Fassungen je Datei. Auf Knopfdruck den Stand einer Datei festhalten, ihn später ansehen, vergleichen oder zurückholen. Das ergänzt Git, statt es zu ersetzen: Git meint das ganze Projekt, eine Fassung genau eine Datei. Aus zwei Ständen baut latexdiff auf Wunsch ein PDF, in dem die Änderungen markiert stehen.

Was ich dabei gelernt habe

Der Planer ist die erste Funktion, die dem Schreiben nützt und nicht dem Verwalten. Alles, was ich in den ersten Fassungen gebaut habe, hat mir Arbeit abgenommen, die vor und nach dem Text liegt: Ordner anlegen, wiederfinden, bauen, Fehler suchen. Der Planer ist der erste Teil, den ich benutze, während ich schreibe. Und das merkt man daran, wie schnell er Meinungen provoziert — bei jeder anderen Funktion war mir nach zwei Tagen egal, wie sie aussieht.

Die schwierigste Frage war nicht, was er kann, sondern wann er schreiben darf. Ein Werkzeug, das die Hauptdatei anfasst, muss sich das verdienen. Deshalb der Block zwischen zwei Marken, deshalb „liest nur“ beim Übernehmen, deshalb das Schreiben nur bei geänderter Dateifolge. Drei Entscheidungen, die man in der Oberfläche nicht sieht — und die darüber entscheiden, ob ich der App ein Manuskript gebe oder nicht.

Und Grenzen aufzuschreiben ist Teil der Arbeit. Die Liste der Dinge, die die App bewusst nicht tut, ist inzwischen fast so lang wie die Funktionsliste. Das ist kein schlechtes Zeichen. Jeder Punkt darauf ist eine Stelle, an der ich mich entschieden habe, statt eine Einstellung zu bauen.


Schreibprojekte ist eine native macOS-App (SwiftUI, macOS 15 oder neuer) für Schreibprojekte in LaTeX und Markdown auf Basis der DIN-5008-KOMA-Script-Vorlagen. Fassung 1.12.0. Die Bildschirmfotos zeigen einen Demo-Bestand, keine echten Projekte. Was die App im Einzelnen kann — und was bewusst nicht —, steht auf der Seite zur App.