Feedback zur Podcastepisode FOCUS ON: Linux 140 zu Org-Tools

Update 2024-12-23: Aspekte für kollaboratives Arbeiten ergänzt

Der Podcast "FOCUS ON: Linux" (keine mir bekannte Homepage) brachte am 2024-12-19 eine Episode zu "Org-Tools" (vermutlich kurz für "Organisationstools").

Die Shownotes dazu findet man unter anderem unter podigee.io.

Für mch war die Episode insofern sehr spannend, weil ich wieder mal viel über die Anforderungen von Menschen lernen durfte, die sie an ihre PIM-Tools stellen. Sowas finde ich immer sehr aufschlussreich.

Ich habe allerdings auch einige Dinge auszusetzen beziehungsweise Falschinformation zu korrigieren.

Die drei Protagonisten scheinen allerdings keine Experten auf dem Gebiet zu sein und erzählten eigentlich nur von ihren persönlichen Erfahrungen über die Jahre. Leider gingen sie nicht allzu sehr in die Details ihrer jeweiligen Geschichte ein. Es wurden beispielsweise nur OneNote, Evernote und Joplin als Tools genannt, die sie in der Vergangenheit genutzt haben und mittlerweile nicht mehr nutzen. Ebenso fehlte mir der tiefere Grund, weshalb diese Tools für sie nicht mehr passend erschienen. Schade, denn hier gäbe es viel zu lernen.

Leider scheint auch logseq kein Tool gewesen zu sein, dass sie sich näher angesehen haben. Schade, denn das fand ich bei meinen Tests eigentlich viel besser als andere erwähnte Tools.

Wie dem auch sei, alle drei sind - wie so viele - beim aktuellen Hype namens Obsidian gelandet. Und wie so oft in meiner Erfahrung scheinen die drei Protagonisten wiederum der Meinung zu sein, dass Obsidian ihre letzte Station der Reise sein wird.

Aus meiner Erfahrung heraus mit so vielen Hypes der vergangenen Jahrzehnte kann ich hier locker aus der Hüfte behaupten, dass sie hier falsch liegen werden. Besonders deswegen, weil Obsidian keine freie Software ist, sondern ein von einer kommerziellen Firma bereitgestelltes Werkzeug darstellt. Das kann ein beliebiges Problem darstellen. Vom Abgang vom Freemium-Konzept, über Cloud-Zwang bis hin zur Einstellung des Produkts ist hier alles möglich.

Ich schreibe schon seit einiger Zeit an einem ausführlicheren Artikel, der vermutlich den Titel tragen wird: "The Lock-in Effect of Non-Free Solutions Using Open File Formats, e.g., Obsidian". Wenn ich den Artikel fertig habe, verlinke ich ihn hier an dieser Stelle.

Ein oft geäußertes Argument wurde auch hier wiederholt: Obsidian speichert seine Daten lokal in Markdown-Dateien und deshalb ist man hier auf der sicheren Seite, was Migration und Zukunftssicherheit betrifft.

Ich stimme insofern zu, dass ein offenes, textbasiertes Speicherformat besser als so viele andere Lösungen wie beispielsweise OneNote sind.

Allerdings wird es so sein, dass wenn man mit einem großen Datenbestand eine Migration vornehmen muss, sich zahlreiche Probleme ergeben. Obsidian speichert nicht in Markdown. Obsidian speichert in einem auf Markdown basiertem Format, das sehr viele Erweiterungen beinhaltet, die sich nicht direkt in einem anderen Tool abbilden lassen. Insofern hat man hier ohne großem Migrationsaufwand (oder DIY-Nachprogrammieren von diversen Obsidian-Features) Datenverlust zu befürchten.

Es wurde - teils leider süffisant belächelt - Emacs Org-mode als obskures Tool erwähnt, das man schon mal wo gehört hat aber das bislang nicht passend erschienen ist. Aufgrund der vielen falschen Dinge, die in dem Zusammenhang erwähnt wurden, kann ich behaupten, dass die Protagonisten sich noch nicht ernsthaft mit Emacs Org-mode auseinandergesetzt haben.

Nun, hier kann ich durch etwas mehr Hintergrundwissen zur Aufklärung beitragen.

Es fängt schon mal mit der Behauptung an, dass Emacs ein Konsolentool ist. Das stimmt insofern, dass man den Emacs sehr wohl in einer Text-only Variante mittels emacs -nw starten und benutzen kann.

Da ich niemanden kennenlernen konnte, der das auch tatsächlich hauptsächlich so nutzt, ist es leider ein sehr irreführend falsches Argument: der Emacs wird zumeist als grafisches Programm betrieben, das auch die Darstellung von Bilderinhalten beherrscht. Es gibt viele Menschen, die den Emacs als PDF-Betrachter und -Annotierer verwenden. (Es gibt sogar Leute, die im Emacs Musik komponieren und Videos schneiden und andere obskure Use-cases damit verwirlichen.) Demnach also alles andere als ein nur-Text-Tool in der Konsole.

Emacs ist kein klassisches Softwaretool, sondern stellt meiner Meinung nach eine Sonderform dar. Im Prinzip ist der Emacs eine Plattform, auf dem Code in Form von Elisp (Emacs Lisp) ausgeführt wird. Ob das nun ein Spiel, ein Editor, ein Outliner, ein PDF-Betrachter oder sonstwas ist.

Ich bin der tiefsten Überzeugung, dass genau die drei Protagonisten vom Podcast mit Org-mode langfristig sehr, sehr glücklich sein könnten.

Im Podcast wurde auch mehrfach Ressentiment gegenüber Tools ausgedrückt, die alles auf einmal wollen. Stattdessen wird von den Protagonisten ein Konzept verfolgt, das viele oft als auch Unix-Philosophie bezeichnen: "Mache nur eine Sache und mache sie gut." (in Kürzestform)

Dem stimme ich im allgemeinen unbedingt zu.

Allerdings mache ich beim Emacs eine Ausnahme von dieser Regel und ich kann das glaube ich auch gut begründen. Der Emacs besitzt klarerweise Texteditorfähigkeiten. Jedoch ist das bei weitem nicht die wesentlichste Eigenschaft. Wenn man möchte, kann Emacs sich um deine E-Mails kümmern, ihn als ziemlich perfekte Oberfläche für git verwenden, deinen Dateimanager in den Schatten stellen, du kannst damit alle Arten von Sourcecode einbetten und ausführen (und damit sowas wie Ansible ersetzen oder Literate programming auf Speed implementieren), du kannst damit im Web browsen, du kannst damit spielen, tausende andere Dinge erledigen und natürlich auch deine Termine, Todos, deine Projekte und dein Wissensmanagement verwalten.

Das Gute daran ist: man muss es nicht.

Man kann den Emacs für die simple todo.txt-Methode verwenden oder aber auch ein Projektmanagement mit tausenden von Tasks gestalten, die seinesgleichen sucht. Dabei wählt man selbst aus, was man nun im Emacs machen möchte und was nicht. Die Funktionalität, die man nicht verwendet, steht einem dabei auch nicht im Weg und lenkt von der Arbeit ab. Starte einfach und simpel.

Insofern sehe ich dem Emacs durchaus in der Linie der Unix-Philosophie, weil es nur eine Plattform darstellt, auf der man genau nach dem Unix-Prinzipien unabhängige und sehr gut kommunizierende Tools laufen hat, die man untereinander verbinden kann, wenn man möchte.

Soweit ich mich erinnere, hat der Emacs für wirklich alle im Podcast genannten Anforderungen inklusive aller anderen erwähnten Tools ein oder mehrere Angebote für euch. Man kann sie alle in Emacs abbilden, muss aber nicht. Danke maximaler Offenheit integriert sich Emacs als auch Org-mode wunderbar in sehr viele andere Workflows. Beispielsweise habe ich auch viele DIY-Prozesse mit Schnittstellen zu Jira, Confluence, GNONE Evolution (E-Mail), mein Mailsetup generell, ... im Einsatz. Viel Spaß bei Obsidian, wenn man auf irgendwelche add-ons angewiesen ist, die sonst niemand verwendet oder die verwaisen.

Emacs ist ein Selbstbaukasten, wo man sich aus den Bausteinen seine Lösungen selbst zusammensetzt. Und das genau in der Form, wie man es braucht. Das ist auch ein potentieller Kritikpunkt: Man braucht Selbstdisziplin, den Punkt zu finden, wo man aufhört, an seinem System zu bauen. Allerdings: wenn man mal seine Workflows mit Emacs abgebildet hat, dann hat man sehr, sehr viele Jahre einen tollen Nutzen und kann sich mit dem erworbenen Wissen auch selbst sehr gut helfen.

Beispielsweise habe ich einen relativ simplen Workflow implementiert, der ausgewählte Sub-Hierarchien von meinem Org-mode im logseq meiner Frau sichtbar macht. Und das ganz ohne Hilfe von einer KI. ;-)

Disclaimer: Ich habe Orgdown als Begriff für die Syntax von Org-mode versucht zu etablieren, da ich zu oft Zeuge von sinnlosen Diskussionen war, wo Menschen von unterschiedlichen Dingen (Syntax vs. Implementierung) gesprochen haben, ohne es zu merken. Ich nutze diesen Vorteil und nenne hier "Orgdown", wenn ich mich auf die Syntax von der Elisp-Implementierung in Org-mode beziehe.

Mal etwas Provokantes: Markdown ist als Syntaxsprache inkonsistent, unnötig schwer zu lernen und zu tippen. Das sind Dinge, die ich als schlecht empfinde. Daher ist aus meiner Sicht das marktbeherrschende Markdown eine an sich schlechte Lösung.

Im Gegensatz dazu ist Orgdown (entstand übrigens AFAIR im gleichen Jahr wie Markdown) konsistent, viel einfacher zu lernen als auch mit der Hand zu tippen.

Das hat auch seinen Ursprung darin, dass Markdown in seiner ursprünglichen Form eine (schlecht designte) Minimalvariante war. Spätere Anwendungen brauchten dann mehr Syntaxelemente, die in der ursprünglichen Definition fehlten. Dazu gehören Tabellen, Fußnoten und so weiter. Diese Anwendungen erweiterten damit Markdown auf ihre eigene Art und Weise. Damit ergab sich ein fürchterlicher Zoo von sich großteils widersprechenden Markdown-Flavors, die dafür sorgen, dass die Gefahr von Datenverlust bei Konvertierungen recht hoch ist.

Markdown ist also fast nie Markdown.

Auch Obsidian hat zahlreiche Syntaxelemente erfunden. Viele Obsidian-Add-Ons erweitern diese um weitere Elemente. Ohne viel Handarbeit bekommt man das nicht in ein anderes System konvertiert. Pandoc hilft aber auch das kennt "nur" eine handvoll Markdown-Dialekte.

Bei Orgdown ist es so, dass das Original die weitaus umfangreichste Syntaxelementsammlung darstellt. Alle anderen Tools, die Orgdown verwenden, implementieren eine echte Untermenge davon. Dadurch ist in der Praxis Orgdown (obwohl es noch an einer formalen Definition mangelt) das wesentlich bessere Format, wenn man auf Datenaustausch setzt.

Ich sage gleich dazu: logseq verwendet optional ebenfalls Orgdown, hat aber aus verschiedenen Gründen eine sehr eigenwillige Art, die Syntax einzusetzen: alles ist eine Überschrift. Das hat Vorteile (überall kann man Meta-Daten hinzufügen oder Links setzen) und Nachteile (Weiterverwendung außerhalb von logseq).

Im Podcast kam die heutzutage wichtige Anforderung vor, mobil auf sein Wissensmanagement zugreifen zu wollen. Die Protagonisten sprachen hier von Versuchen, via Termux einen Emasc zum Laufen zu bringen. Sorry, das ist der vollkommen falsche und auch unnötig komplizierter Ansatz.

Es gibt mittlerweile Emacs als native App auch unter Android. Allerdings würde ich auch das mangels ordentlicher Hardware-Tastatur nicht wirklich empfehlen. (Setups mit Android im Desktop Mode und entsprechendem Bildschirmplatz und ordentlicher Eingabegeräte mal ausgenommen.)

Der wesentlich klügere Ansatz ist, dass man erkennt, dass seine Daten in Form von Orgdown-Dateien mit Mitteln wie Syncthing zwischen den Rechnern synchron gehalten werden.

Einschub: Sowas wie Syncthing sollte man auch für Markdown verwenden, um die im Podcast erwähnten seltsamen Konfliktdatenverluste zu verhindern. Es ist mir schleierhaft, weshalb heutzutage selbst fähige Techniker:innen auf proprietäre Cloud-Lösungen setzen.

Wenn man nun mit Tools wie Synching seine Orgdown-Dateien auch am Android-Handy hat (Apple blockiert Lösungen wie Syncthing aus politischen Gründen, weil ... Apple halt), dann braucht es nur eine App, die mit Orgdown-Dateien umgehen kann. Das muss nicht der Emacs sein. Beispielsweise kann das unter anderem auch orgzly-revived sein. Die braucht auch nicht den kompletten Funktionsumfang einer Emacs Org-mode Implementierung. Unterwegs möchte ich beispielsweise nur Dinge recherchieren (read-only) und neue Dinge festhalten (mobile capture; write). Das vereinfacht die Sache gewaltig.

Problem gelöst. Ganz ohne Frickelei mit Termux oder solch seltsamen Konstrukten. Ich weiß: Techniker verrennen sich da gerne mal am Anfang. Geht mir oft genug gleich. ;-)

Etwas, wo Org-mode aktuell meines Wissens einen Punkt hat, wo es kein ordentliches Angebot gibt, ist kollaboratives Arbeiten. Damit meine ich, dass an den gleichen Orgdown-Daten zur selben Zeit von mehr als einem Gerät aus gearbeitet wird.

Da Orgdown simple Textdateien sind, kann man alle Workflows anwenden, wo beispielsweise eine Versionsverwaltung wie git für Koordination und Konfliktmanagement ausreichend ist. Das funktioniert allerdings nur schlecht, wenn sich die bearbeiteten Teile direkt überschneiden.

Hier haben Cloud-basierte Lösungen einen Vorteil, wenn man die Nachteile akzeptieren kann.

Ich empfehle den Protagonisten (und auch allen Zuhörer:innen) von dem Podcast, sich die FOCUS ON: Linux Episode 70 "Emacspinkie" anzuhören. Da wird Vieles erklärt. Disclaimer: ich war da ebenfalls einer der Gäste.

Leser:innen meiner Seite wissen, dass ich unter PIM als auch Emacs sehr viele Artikeln zum Thema Selbstorganisation online habe. Nicht zuletzt gibt's von mir auch etliche Videos, Workshops, Lehrveranstaltungen, Radiobeiträge zu dem Thema.

Viel Spaß beim Entdecken und bitte lest auch meine Tipps zur richtigen Werkzeugwahl. Da sind das optionale Vermeiden langfristiger lock-in-Effekte bereits mitaufgelistet.