@lisanet Bist du eigentlich mit deinen Tests soweit durch? Zumindest mit MarkEdit? Oder hast du dir vielleicht auch mal Typora angeschaut?
Ich bin zumindest mit MarkEdit durch.
Fazit für mich zu MarkEdit:
- ich finde es gut in der Source-Ansicht zu schreiben (mehr dazu unten)
- es hilft mir, im Sinne einer Kontrolle, rechts daneben die gerenderte Ansicht zu haben.
- MarkEdit startet schnell, ist ohne Seitenleisten oder sonstigen grpoße Menuleisten-Icons, was ich fürs Schreiben gut finde, da es den Fokus auf dem Text lässt
- Die Export-Funktion nach HTML habe ich mir mittlerweile hinsichtich des Styles angepasst, die Konvertierung in ein PDF ist nach wie vor suboptimal (wegen der Seitenumbrüche mit Trennung von Überschrift und Absatz).
Was ich aber bei dem Test mit MarkEdit gemerkt habe, ist eigentlich was anderes. Mich hat da ein YT-Video auf etwas hingestoßen, warum ich Markdown eigentlich überhaupt nutze und warum ich im Source-Code schreibe
Ich nutze Markdown eigentlich nur für die Dokumentation von source code, wie z.B. für das README eines github-Projektes. Und für Notizen auf remote Rechnern (2 x NAS, 1 x Hardware-Recoder und 1 x Homebridge) um dort individualiserte Änderungen an der Standard-Konfig festzuhalten, so dass ich die auch irgendwann mal nachvollziehen kann. Markdown dabei aus dem einzigen Grund, dass es in "nano" (meinem bevorzugten Editor in der shell) wunderbar farbig markiert und ausgezeichnet wird. So ist eben in einem reinen Textdokument, Code einfacher von Prosa zu unterscheiden und Überschriften kommen deutlicher als eben neuer Textabschnitt hervor. Es liest sich also einfach leichter, wenn man sich per ssh einloggt.
Mit der Zeit fand ich es dann ganz schick, wenn ich die Doku zu source Code nicht nur als Markdown-Text ggf. in ein Archiv packe und an jemanden weiter gebe, sondern wenn die Doku als PDF vorliegt. Sieht einfach für Nicht-Markdown-Fans besser aus.
Und so habe ich dann gedacht, das Markdown auch irgendwie nützlich sei, um andere Texte zu schreiben und habe mich in die Themen der Styles versucht einzuarbeiten.
Und hier hat mich das erwähnte YT-Video "aufgeweckt".
Andere Arten von Dokumenten, die ich bisher verfasst habe und auch ab und an weiterhin verfasse, waren bspw Designs für Rezept-Karten, mit screenshots bebilderte Anleitungen, Briefe und früher Schulungsunterlagen, Arbeitsanweisungen etc.
All das habe ich bisher entweder mit Word (früher im Beruf) oder wenn es eher designmäßig war (Rezepte u.dgl) mit Pages gestaltet. Und ehrlich gesagt, da ist es auch deutlich einfacher zu bewerkstelligen.
Für diese Dinge jetzt zu versuchen, das mit einem Markdown-Editor zu erstellen, hat irgendwwas von "Markdon nutzen, des Markdown willens" Warum eine neue Syntax lernen, die noch nicht mal all das abbilden kann, was ich bisher gemacht habe, die mir bei eben diesen Dokumenten keine Vorteile gegenüber Word und Pages bringt, sondern eher Einschränkungen und Kompromisse.
Und da habe ich für mich erkannt, dass Markdown für mich eben einen eingeschränkten Anwendungsbereich abdeckt (remote per ssh, Dokus von source code, github Dokumente) und das sehr gut angepasst an diese Anwendungsbereiche.
Und bei diesen Anwendungsbereichen ist zum einen "nano" für remote genau das richtige und wenn ich ehrlich bin, ist für source code sogar VS Code besser geeignet als MarkEdit. Warum? Weil ich wenn ich in source code arbeite, eh schon in VS Code bin und dort auch die Doku verfassen, sie per git versioniere und in ein repo bringe. Der workflow ist eigentlich deutlich konsistenter als erst in eine andere App zu wechseln.
Okay, für die Erstellung von PDF brauche ich immer noch MarkEdit.
Insoweit werde ich auch nicht weitere Markdown-Editoren testen, da Markdown für mich nur eben die og. Anwendungsfälle betrifft und "komplexere" Apps wie Obisdian, Typora u.dgl. nicht relevant sind und auch gar nicht Word und PAges ersetzen können.
Bevor jemand sagt "das kann man alles mit Markdon machen": kann ja sein, aber geht sowas wirklich in Mardown?
Hier noch das YT-Video
