Ich habe mir eine App gebaut, weil kein Programm zu meinem Schreiben passte
Ich schreibe privat viel. Artikel, Berichte, Notizen, Briefe, gelegentlich etwas Längeres. Und ich schreibe in Markdown und LaTeX, nicht aus Prinzipientreue, sondern weil beides tut, was ich brauche: reiner Text, der in zehn Jahren noch lesbar ist, eine Versionsverwaltung, die etwas Sinnvolles anzeigt, und ein Satzergebnis, das aussieht wie gesetzt und nicht wie getippt.
Was mir all die Jahre gefehlt hat, war nicht der Editor. Es war alles drumherum.
Das Problem war nie das Schreiben
Ein neues Dokument fängt bei mir nicht mit dem ersten Satz an. Es fängt damit an, dass ich einen Ordner anlege. Dann kopiere ich eine Vorlage hinein. Welche war noch mal die aktuelle? Dann die Präambel dazu, die inzwischen an drei Stellen in leicht verschiedenen Fassungen liegt. Dann ein Makefile, weil ich mir die latexmk-Aufrufe nie merke. Dann trage ich Titel, Untertitel, Autor und Datum von Hand ein, an fünf Stellen im Kopf der Datei. Dann git init. Dann, vielleicht, der erste Satz.
Und danach fängt das eigentliche Problem an: den Überblick behalten.
Woran habe ich zuletzt gearbeitet? Welches Projekt ist fertig, welches ein Fragment? Wo war noch mal der Brief an die Stadtwerke? In welchen Projekten habe ich diese eine Tabellenformatierung benutzt, die ich wiederverwenden wollte? Der Finder beantwortet keine dieser Fragen. Er zeigt mir Ordnernamen und Änderungsdaten, und ein Änderungsdatum ändert sich schon, wenn latexmk einmal durchgelaufen ist.
Ich habe es mit Ordnerstrukturen versucht. Nach Jahr, nach Art, nach Thema. Jedes Schema war nach ein paar Monaten falsch, weil ein Projekt in zwei Schubladen gehörte oder in keine.
Ich habe es mit Namenskonventionen versucht. 2024-03_bericht_typografie. Das funktioniert, solange man es durchhält. Ich habe es nicht durchgehalten.
Dann kamen die Skripte
Irgendwann tat ich, was man als Informatiker eben tut: Ich schrieb mir Skripte.
Ein neues-projekt.sh, das den Ordner anlegt, die Vorlage kopiert und mit sed den Titel einsetzt. Ein bauen.sh, das latexmk mit den richtigen Schaltern aufruft. Ein woerter.sh um texcount. Später ein kleines Ding, das über alle Ordner lief und mir eine Liste ausgab: Name, Datum, Wortzahl.
Es hat funktioniert. Ein paar Monate lang war ich sogar stolz darauf.
Aber Skripte haben eine Eigenschaft, die man erst nach einer Weile bemerkt: Sie beantworten Fragen, die man ihnen im Voraus gestellt hat. Mein Listenskript zeigte mir alles, was ich beim Schreiben des Skripts für wichtig hielt. Als ich wissen wollte, welche Projekte seit dem Sommer keinen Fortschritt mehr gemacht hatten, musste ich das Skript ändern. Als ich Schlagwörter wollte, musste ich mir ein Dateiformat für Schlagwörter ausdenken. Als der Titel eines Projekts sich änderte, wusste das Skript es nicht, weil der Titel im Ordnernamen stand und im \title{} und in meinem Kopf, und alle drei drifteten auseinander.
Dazu kam das Zweite: Ein Skript zeigt einem den Fehler in latexmk als achtzig Zeilen Protokoll, in denen die entscheidende Zeile irgendwo in der Mitte steht. Ich habe mir angewöhnt, | grep -i error anzuhängen. Dann fehlten mir die Warnungen. Also grep -E 'Error|Warning'. Dann waren es wieder zu viele.
Und das Dritte, das schwerste: Ich habe die Skripte nicht gepflegt. Sie lagen in einem Ordner, funktionierten meistens, und wenn eines nicht mehr tat, was es sollte, habe ich die eine Sache eben von Hand gemacht. Nach einem Jahr war die Hälfte davon Archäologie.
Warum keine der fertigen Lösungen passte
Klar habe ich mich umgesehen. Es gibt gute Programme.
Es gibt LaTeX-Editoren, die den Quelltext hervorragend beherrschen, aber für sie ist eine .tex-Datei eine Datei, kein Projekt. Öffnen, bearbeiten, schließen. Was gestern war, wissen sie nicht.
Es gibt Schreibprogramme mit Projektverwaltung, die genau die Ordnung bieten, die mir fehlte, aber sie wollen den Text in ihrem eigenen Format, und was am Ende herauskommt, ist nicht mein Satzspiegel.
Es gibt Markdown-Apps, die schön sind und schnell, aber wenn ich ein Dokument nach DIN 5008 mit KOMA-Script brauche, mit Anschriftfeld für Fensterumschläge, dann hört es dort auf.
Und es gibt allgemeine Notizprogramme, in denen sich alles verwalten lässt, außer der Frage, ob das PDF baut.
Das Muster ist immer dasselbe: Jedes Programm ist für den Teil gut, für den es gedacht war. Mein Arbeitsablauf geht aber quer durch alle drei Teile: Ordnung, Text, Satz. Genau dazwischen fiel er jedes Mal durch.
Also habe ich es selbst gebaut
Schreibprojekte ist eine native macOS-App, und sie ist für genau eine Person gebaut: für mich. Das ist keine Bescheidenheitsfloskel, sondern die Entwurfsentscheidung, aus der alle anderen folgen.
Was das konkret heißt:
Ein Projekt ist ein Ordner, kein Datenbankeintrag. Alles, was ein Projekt ausmacht, liegt im Projektordner selbst, in einer kleinen .schreibprojekt.json neben der Hauptdatei. Kopiere ich den Ordner auf einen anderen Rechner, findet er dort seine Vorlage, seine Gruppe und seine Schlagwörter wieder. Lösche ich die App, bleibt ein ganz normaler, kompilierbarer LaTeX-Ordner übrig. Ich wollte nichts bauen, aus dem ich nicht wieder herauskomme.
Die Vorlagen bleiben gültige Dokumente. Die App schreibt keine Platzhalter wie {{TITEL}} in meine Vorlagen. Sie ersetzt die Argumente vorhandener Makros: aus \title{Titel des Artikels} wird \title{Digitale Souveränität}. Meine Vorlagensammlung bleibt also eine Sammlung fertiger Dokumente, die ich auch ohne die App weiterbenutzen kann. Bei Markdown dasselbe mit den Werten im YAML-Kopf.
Ordnung ohne Ordnerstruktur. Ein Projekt liegt in höchstens einer Gruppe und trägt beliebig viele Schlagwörter. Beides sind eigene, gepflegte Einträge: eine leere Gruppe bleibt stehen, umbenannt wird an einer Stelle. Damit ist das Problem gelöst, an dem meine Ordnerhierarchien immer gescheitert sind: Ein Werkstattbericht kann gleichzeitig „Hochschule“, „Überarbeitung“ und „Recherche“ sein, ohne dass ich mich für eine Schublade entscheiden muss.
Das Protokoll wird gelesen, nicht durchgereicht. Wenn der Bau fehlschlägt, steht die Meldung oben in einer Liste, mit Datei und Zeilennummer, und ein Klick springt an die Stelle im Editor. Das ist die Funktion, die mir die Skripte am meisten schuldig geblieben sind.
Markdown und LaTeX, nicht Markdown oder LaTeX. Manches schreibe ich in Markdown, weil ich schneller vorankomme; anderes in LaTeX, weil ich die Kontrolle brauche. Markdown-Projekte gehen zuerst durch pandoc und dann denselben Weg wie alle anderen. Dadurch bleiben Protokoll, Fehlerliste, Vorschau, Literaturverzeichnis und Auto-Bau überall gleich. Es gibt nicht zwei Hälften der App.
Und ein Editor, weil der Weg nach draußen zu lang war. Anfangs öffnete die App den Quelltext in einem externen Programm. Das war ein Bruch: bauen hier, schreiben dort, Fehlerstelle im Kopf merken und drüben suchen. Jetzt ist der Editor eingebaut, mit Syntaxhervorhebung, Zeilennummern, Suchen und Ersetzen, Vervollständigung für Befehle und Literaturschlüssel und einer Leiste mit den gängigen Bausteinen. Wer lieber sein eigenes Programm benutzt, kann das nach wie vor; ich brauche es nicht mehr.
Und dann die Dinge, die ich vorher gar nicht hatte. Eine Dateiübersicht, die den Projektordner nach Rollen sortiert statt alphabetisch: Hauptdatei, Präambel, Teildateien, Literatur, Bilder. Bilder per Drag & Drop, mitsamt fertigem \includegraphics. Der Git-Stand direkt daneben.
Und ein Schreibverlauf je Projekt und Tag, mit Ziel-Wortzahl und Ziellinie. Das war anfangs eine Spielerei. Es ist die Ansicht, die ich am häufigsten öffne.
Was ich dabei gelernt habe
Ein Werkzeug für eine Person darf Meinungen haben. Ich musste nicht klären, ob jemand lieber Ordnerstrukturen mag. Ich musste keine Einstellung dafür bauen, ob eine Fehlermeldung als Liste oder als Rohtext erscheint. Ich habe die Entscheidung getroffen, die für mich richtig ist, und bin weitergegangen. Das macht die App kleiner und klarer, und in genau dem einen Fall, für den sie gedacht ist, deutlich besser als ein Kompromiss es wäre.
Ohne KI-Unterstützung gäbe es diese App nicht. Ich kann programmieren, aber ich bin kein Profi in Software-Entwicklung. Beruflich befasse ich mich mit anderen Dingen und privat fehlt mir die Zeit, mich tiefer darin einzuarbeiten. Eine native App in SwiftUI ist noch einmal etwas anderes als ein Shell-Skript. Früher war genau an dieser Stelle Schluss: Die Idee stand, die Umsetzung nicht. Für mich zählt das Ergebnis, und dafür ist KI ein Game-Changer. Ich kann mir endlich Werkzeuge bauen, die meinen Vorstellungen entsprechen und mir wirklich helfen, statt mich mit dem zu arrangieren, was es fertig gibt.
Und jetzt?
Ich benutze sie täglich. Das ist der einzige Test, der zählt. Ein neues Projekt sind drei Schritte in einem Assistenten. Der Überblick ist eine Liste, die ich sortieren und filtern kann. Der Fehler im Bau ist ein Klick.
Ob die App für andere taugt, weiß ich nicht. Sie ist auf Deutsch, sie setzt eine TeX-Distribution voraus, sie läuft bewusst ohne App Sandbox, und sie geht davon aus, dass man DIN 5008 und KOMA-Script mag. Das ist eine ziemlich schmale Zielgruppe. Und sie hat Lücken, die ich bewusst gelassen habe: keinen Brief in Markdown, keine Vervollständigung über \input-Ketten hinweg, keinen vollständigen BibTeX-Übersetzer.
Aber das war der Punkt. Ich wollte kein Produkt bauen, das für viele halbwegs passt. Ich wollte ein Werkzeug, das für mich genau passt.
Und das tut es.
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.3.0. Die Bildschirmfotos zeigen einen Demo-Bestand, keine echten Projekte. Was die App im Einzelnen kann, steht auf der Seite zur App.