You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(a) verwendet Codeblöcke mit einer bestimmten Auszeichnung. Dadurch wird das Include "sicher" (es können nicht "versehentlich" Dateien eingebunden werden), aber es ist aufwändig und wird in keiner Markdown-Preview so verlinkt, dass man das Sub-Dokument anklicken kann.
(b) verwendet Divs, um per Filter die Dokumente einzubinden. Insgesamt finde ich diese Variante schöner als die Codeblöcke, aber "klickbar" werden die verlinkten Dokumente in der Preview immer noch nicht.
In (c) verwende ich stattdessen lokale Markdown-Links auf die Sub-Dokumente, um sie dann per Filter einzubinden. Vorteil: In der Preview kann man auf den Link klicken und kommt zum Dokument. Nachteil: Ein Link ist ein Inline-Typ, der mit einem Dokument (Liste von Block-Elementen) ersetzt werden soll. Das passt dann semantisch und syntaktisch nur, wenn man den umgebenden Block mit ersetzt - schützt aber leider nicht davor, beispielsweise in einem Stichpunkt einen solchen Link auf ein zu inkludierendes Dokument unterzubringen.
Wenn man die Idee aus (b) weiter verfolgt und den Filter in (c) um ein umgebendes Div ergänzt, hätte man eine saubere Lösung. Die Typen würden wieder passen (das Div kann vom Filter erkannt und durch die Liste der Blocks des Dokuments ersetzt werden), es wäre im Markdown gut les- und erkennbar und würde vor Fehlerkennungen bzw. ungewünschten Einbindungen seitens des Filters schützen, und in der Preview erhält man einen anklickbaren Link auf das Sub-Dokument.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Es wäre spannend, eine Art Hauptdokument (Markdown) zu haben, welches auf Sub-Dokumente für die einzelnen Kapitel o.ä. (Markdown) verlinkt.
Es gibt afaik drei Filter, die das bewerkstelligen: (a) lua-filters/include-files, (b) pandoc-include-doc, und (c) mein eigenes filters/include_mdfiles.lua.
(a) verwendet Codeblöcke mit einer bestimmten Auszeichnung. Dadurch wird das Include "sicher" (es können nicht "versehentlich" Dateien eingebunden werden), aber es ist aufwändig und wird in keiner Markdown-Preview so verlinkt, dass man das Sub-Dokument anklicken kann.
(b) verwendet Divs, um per Filter die Dokumente einzubinden. Insgesamt finde ich diese Variante schöner als die Codeblöcke, aber "klickbar" werden die verlinkten Dokumente in der Preview immer noch nicht.
In (c) verwende ich stattdessen lokale Markdown-Links auf die Sub-Dokumente, um sie dann per Filter einzubinden. Vorteil: In der Preview kann man auf den Link klicken und kommt zum Dokument. Nachteil: Ein Link ist ein
Inline
-Typ, der mit einem Dokument (Liste vonBlock
-Elementen) ersetzt werden soll. Das passt dann semantisch und syntaktisch nur, wenn man den umgebenden Block mit ersetzt - schützt aber leider nicht davor, beispielsweise in einem Stichpunkt einen solchen Link auf ein zu inkludierendes Dokument unterzubringen.Wenn man die Idee aus (b) weiter verfolgt und den Filter in (c) um ein umgebendes
Div
ergänzt, hätte man eine saubere Lösung. Die Typen würden wieder passen (dasDiv
kann vom Filter erkannt und durch die Liste derBlock
s des Dokuments ersetzt werden), es wäre im Markdown gut les- und erkennbar und würde vor Fehlerkennungen bzw. ungewünschten Einbindungen seitens des Filters schützen, und in der Preview erhält man einen anklickbaren Link auf das Sub-Dokument.Edit: Links können Attribute haben - man könnte einem Link auch eine eigene Klasse geben, um vom Filter beachtet zu werden. (https://pandoc.org/MANUAL.html#extension-link_attributes)
Auch relevant für https://github.com/cagix/pandoc-thesis und insbesondere #27.
Beta Was this translation helpful? Give feedback.
All reactions