lume VS pandoc

Deno also has a tooling ecosystem around it to enable developers to jumpstart their projects. Fresh is a web framework built for Deno and Lume is their static site generator.

Agreed, it really does need to be sorted out. I guess for me, what would happen if someone created a wrapper around Pandoc in NodeJS and published it to NPM... would that package need to inherit the GPL licence? I'd say yes otherwise the very purpose of GPL is undermined and closed-source projects could bypass the licence terms with ease. Now let's say that someone creates a Lume plugin that imports that NPM package so users can convert their assets at build time into more permanent versions, like DOCX to PDF. Should this plugin inherit the package's GPL licence? Now let's say someone uses that Lume plugin in their site. Does that site then need to inherit the plugin's GPL licence? Ambiguity in the first instance creates a chain of ambiguity down the line. This kind of thing is so prevalent on NPM too, just search for git wrappers. Git doesn't even have a runtime exception like GCC does.

Try lume (https://lume.land/)

My vote goes to https://lume.land

lume.land is my most favorite static site generator, but I was not able to figure out how to use code_highlight plugin.

$ mkdir lume-example $ cd lume-example $ lume init Use Typescript for the configuration file? [y/N] y How do you want to import lume? Type a number: 1 import lume from "lume/mod.ts" 2 import lume from "https://deno.land/x/lume/mod.ts" 3 import lume from "https:/deno.land/x/[email protected]/mod.ts" [1] Do you want to import plugins? Type the plugins you want to use separated by comma. All available options: - attributes https://lumeland.github.io/plugins/attributes/ - base_path https://lumeland.github.io/plugins/base_path/ - bundler https://lumeland.github.io/plugins/bundler/ - code_highlight https://lumeland.github.io/plugins/code_highlight/ - date https://lumeland.github.io/plugins/date/ - eta https://lumeland.github.io/plugins/eta/ - inline https://lumeland.github.io/plugins/inline/ - jsx https://lumeland.github.io/plugins/jsx/ - liquid https://lumeland.github.io/plugins/liquid/ - modify_urls https://lumeland.github.io/plugins/modify_urls/ - on_demand https://lumeland.github.io/plugins/on_demand/ - postcss https://lumeland.github.io/plugins/postcss/ - pug https://lumeland.github.io/plugins/pug/ - relative_urls https://lumeland.github.io/plugins/relative_urls/ - resolve_urls https://lumeland.github.io/plugins/resolve_urls/ - slugify_urls https://lumeland.github.io/plugins/slugify_urls/ - svgo https://lumeland.github.io/plugins/svgo/ - terser https://lumeland.github.io/plugins/terser/ Example: postcss, terser, base_path Created a config file _config.ts Do you want to configure VS Code? [y/N] y VS Code configured

My main authoring tool is then Emacs Markdown Mode (https://jblevins.org/projects/markdown-mode/). For data entry, it comes with some bells and whistles similar to org-mode, like C-c C-l for inserting links etc.

I seldom export my notes for external usage, but if it is the case, I use lowdown (https://kristaps.bsd.lv/lowdown/) which also comes with some nice output targets (among the more unusual are Groff and Terminal). Of cource pandoc (https://pandoc.org/) does a very good job here, too.

This is one of those things that the ever-amazing pandoc (https://pandoc.org/) does very well, on top of supporting virtually every other document format.

Folks feel the same way about Markdown versus LaTeX: why use something significantly more complicated where a looser, human-readable grammar works better?

For any other situations, I use https://pandoc.org/, or, generate a Word doc scriptomatically.

pandoc toolchain pour builder une version confortable/imprimable en phase de travail (ePub, pdf, docx, html)

Congrats on the launch, I guess, but there are so many free options that I can't think of a situation where paying $0.25 per document would be justified...? Just to name a few:

Back in the days, I used to use XSL-FO [0] and it was okay. It was not very precise but it rarely if ever broke, and was perfectly integrated with an XML/XSLT solution. Yeah, this was a long time ago.

Last month I used html-to-pdfmake [1] and it's also not very precise and more fragile, but very efficient and fast.

Yet another approach would be to pro grammatically generate .rtf files (for example) and use Pandoc [2] to produce PDFs (I have not tried this in production but don't see why it wouldn't work).

[0] https://en.wikipedia.org/wiki/XSL_Formatting_Objects

[1] https://www.npmjs.com/package/html-to-pdfmake

[2] https://pandoc.org/

Others have mentioned static site generators. I like Hakyll [1] because it can tightly integrate with Pandoc [2] and allows you to develop custom solutions if your needs ever grow.

[1]: https://jaspervdj.be/hakyll/

[2]: https://pandoc.org/

Have you compared it with a conversion by pandoc (https://pandoc.org/)?

I have used it to kickstart a blogging project that I wish to come back to soon. The Lua inter-op for custom readers, writers and filters is great but I wish there was more editor integration and even perhaps an official IDE/editor with built-in debugging features (probably something already do-able with Emacs but I haven't checked). The only blocker for my project is no support for "ChunkedDoc" for Lua filters [1] which forces me to write more code and a complicated Makefile.

[1]: https://github.com/jgm/pandoc/issues/9061