Is there anyone feeling that Pandoc is ever increasingly bloated? I have used Lua filters a decade ago [1] and the current documentation is nothing like my memories. I'm not even sure that how much of Lua scripts remain compatible across different Pandoc versions.
With a tagline of "a universal document converter" it is almost a guarantee to become a complicated program but how much of it is being used for any single conversion?
Two more examples:
Rclone is "bloated" but it needs to be in order to fulfill its purpose.
ZFS is "bloated" because it combines volumes and filesystems but breaking the Unix philosophy also enables a different kind of synergy and simplicity elsewhere.
A universal document converter is expected to expand via adding support for additional formats---that's okay (same for your other examples). I'm much more worried about the widening scope of the project.
We use it for seven years and it still runs fine when we update Pandoc - we usually always update things. I don’t remember anything about the docs, so not sure what changed.
Lua filters for Pandoc have been around for a quite a while. What’s newer is Pandoc’s ability to be used in web browsers. There’s a bit more about this and a general rundown of Pandoc in my recent article for LWN:
Look at flag --standalone. At least for html output pandoc seems to be able to handle something that feels like partial pandoc input in practice and produce html output that behaves like a snippet.
Pandoc AST - format called "native" - parses faster than pandoc markdown.
I liked the Lua filters for solving issues on DOCX stuff for Markdown to Docx.
For PDF stuff I haven't needed much Lua filters since switching to WeasyPrint for the PDF engine.
Is there anyone feeling that Pandoc is ever increasingly bloated? I have used Lua filters a decade ago [1] and the current documentation is nothing like my memories. I'm not even sure that how much of Lua scripts remain compatible across different Pandoc versions.
[1] https://github.com/mearie/mearie.github.io/blob/source/res/w...
With a tagline of "a universal document converter" it is almost a guarantee to become a complicated program but how much of it is being used for any single conversion?
Two more examples:
Rclone is "bloated" but it needs to be in order to fulfill its purpose.
ZFS is "bloated" because it combines volumes and filesystems but breaking the Unix philosophy also enables a different kind of synergy and simplicity elsewhere.
"bloat" just means "any feature I am not personally using therefore I deem as useless and pointless".
A universal document converter is expected to expand via adding support for additional formats---that's okay (same for your other examples). I'm much more worried about the widening scope of the project.
We use it for seven years and it still runs fine when we update Pandoc - we usually always update things. I don’t remember anything about the docs, so not sure what changed.
I might be worried if it wasn't pandoc. It's always been bulletproof for me.
Lua filters for Pandoc have been around for a quite a while. What’s newer is Pandoc’s ability to be used in web browsers. There’s a bit more about this and a general rundown of Pandoc in my recent article for LWN:
https://lwn.net/Articles/1064692/
I've always wondered if pandoc can be made reactive. Say markdown to Pandoc AST.
If one changes something, a quick update to the AST would happen incrementally.
Now with all these llm I might actually see if it can be done.
Look at flag --standalone. At least for html output pandoc seems to be able to handle something that feels like partial pandoc input in practice and produce html output that behaves like a snippet.
Pandoc AST - format called "native" - parses faster than pandoc markdown.