Pandoc's built-in BBCode writer supports them, but as far as I can tell no other writers do. check-in: d3554cf3b6 user: Sand tags: trunk

The parser eats up to one newline, so we need to add one as insulation, in case the code block itself starts with a newline.

This also adds a newline before the [/code]. This doesn't affect the HTML rendering, and it looks better as BBCode. check-in: 4f5f8f6879 user: Sand tags: trunk

This is similar to what the built-in BBCode writer does for "spoiler" and certain other classes:
https://github.com/jgm/pandoc/blob/568dab14533940ecee16824097400f1eabf13869/src/Text/Pandoc/Writers/BBCode.hs#L769

The "mark" class is what you get from the <mark> element in HTML input, so it's right and natural that it should become [highlight].

The "spoiler" class is only a convention of the Pandoc BBCode writer, but it seems reasonable.

I'm deferring the decision of whether to support "size", "color", and possibly "bgcolor" attributes for [size], [color], and [bgcolor]. The built-in BBCode writer supports "size" and "color", but I don't know if there's a settled convention for the meaning of those attributes. check-in: 1d3d94eaad user: Sand tags: trunk

The HTML tags become raw attributes that then cannot be converted into BBCode:

[WARNING] Scripting warning at tasvideos_forum.lua line 374 column 1: not rendered: "RawBlock (Format \"html\") \"<pre>\\nThis is `[frames]100[/frames]`{=tasvideos_forum} faster than `[movie]1234[/movie]`{=tasvideos_forum}.\\n</pre>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 374 column 1: not rendered: "RawBlock (Format \"html\") \"<pre>\\n```{=tasvideos_forum}\\n[note]\\nMore details are in [post=1234]this post[/post].\\n[/note]\\n```\\n</pre>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 374 column 1: not rendered: "RawBlock (Format \"html\") \"<dl>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 374 column 1: not rendered: "RawBlock (Format \"html\") \"<dt>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 695 column 1: not rendered: "RawInline (Format \"html\") \"<code>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 695 column 1: not rendered: "RawInline (Format \"html\") \"</code>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 374 column 1: not rendered: "RawBlock (Format \"html\") \"</dt>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 374 column 1: not rendered: "RawBlock (Format \"html\") \"<dd>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 695 column 1: not rendered: "RawInline (Format \"html\") \"<a href=\\\"https://en.wikipedia.org/wiki/Data_URI_scheme\\\">\""
[WARNING] Scripting warning at tasvideos_forum.lua line 695 column 1: not rendered: "RawInline (Format \"html\") \"</a>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 695 column 1: not rendered: "RawInline (Format \"html\") \"<a href=\\\"https://pandoc.org/MANUAL.html#option--embed-resources[\\\">\""
[WARNING] Scripting warning at tasvideos_forum.lua line 695 column 1: not rendered: "RawInline (Format \"html\") \"<code>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 695 column 1: not rendered: "RawInline (Format \"html\") \"</code>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 695 column 1: not rendered: "RawInline (Format \"html\") \"</a>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 374 column 1: not rendered: "RawBlock (Format \"html\") \"</dd>\""
[WARNING] Scripting warning at tasvideos_forum.lua line 374 column 1: not rendered: "RawBlock (Format \"html\") \"</dl>\""

The <pre> we can remove by indenting the block. The <a> and <code> can be replaced with Markdown, since the Fossil parser interprets Markdown within HTML. (Like the markdown_in_html_blocks extension of Pandoc.)

But I cannot think of a way to replace the <dl> definition list. This means that README.md itself renders better if you go from Markdown to HTML to TASVideos:

pandoc -f markdown -t html README.md | pandoc -f html -t tasvideos_forum.lua

than if you go from Markdown to TASVideos directly:

pandoc -f markdown -t tasvideos_forum.lua README.md

This causes the browser to download the file, not display its contents, even if the web server serves it with a MIME type of text/something, as might be configured in the mimetypes setting. check-in: 4c5b057076 user: Sand tags: trunk

Rather than show the file listing, provide a link that immediately downloads tasvideos_forum.lua.

The "name" URL query parameter is equivalent to the final URL path component:

https://fossil-scm.org/home/file/www/aboutcgi.wiki?ci=c64f28d26c7fd701

With Fossil, terms of PATH_INFO beyond the webpage name are converted into the "name" query parameter. Hence, the following two URLs mean exactly the same thing to Fossil:

1. https://fossil-scm.org/home/info/c14ecc43
2. https://fossil-scm.org/home/info?name=c14ecc43

So the old link could have been /file/tasvideos_forum.lua rather than /file?name=tasvideos_forum.lua. Similarly, instead of /raw/tasvideos_forum.lua?ci=trunk, the new link could be /raw?name=tasvideos_forum.lua&ci=trunk&at=tasvideos_forum.lua, but in that case the "at" parameter would be necessary, to avoid the browser downloading the file with the filename "raw". check-in: fe1acb5669 user: Sand tags: trunk

I had been using pandoc.scaffolding.Writer for the sake of its handling of metadata and template rendering, implemented in the runWriter function:
https://github.com/jgm/pandoc/blob/3.8.3/pandoc-lua-engine/src/Text/Pandoc/Lua/Writer/Scaffolding.hs#L145

But this doesn't work as smoothly as you would like when you're not using all the rest of the pandoc.scaffolding.Writer machinery, in particular the Writer.Block and Writer.Inline tables. The scaffolding Writer renders templates using its own blockListToCustom and inlineListToCustom functions:
https://github.com/jgm/pandoc/blob/3.8.3/pandoc-lua-engine/src/Text/Pandoc/Lua/Writer/Scaffolding.hs#L158-L159
These functions essentially do what the calling Writer.Blocks or Writer.Inlines does: look up the Writer.Block or Writer.Inline function for each element and call it. But it bypasses the actual Writer.Block and Writer.Inline tables, which means you cannot override the use of blockListToCustom and inlineListToCustom.

Therefore you would have to wire up Writer.Inline.Str functions and all the rest, and write them to return a string/Doc rather than yielding tokens like the existing element handlers do. Besides being an annoyance, the way inlineListToCustom essentially glues strings together means that we would potentially have the same failure to properly escape URL-like strings (in templates) that the whole "yielding tokens" design was put in place to fix.

Even without pandoc.scaffolding.Writer, might it be possible to support templates? Reimplementing the logic of runWriter within the Lua writer's Writer function is not that bad with the help of pandoc.template.meta_to_context and pandoc.template.apply.
https://pandoc.org/lua-filters.html#pandoc.template.meta_to_context
https://pandoc.org/lua-filters.html#pandoc.template.apply
But pandoc.template.meta_to_context still wants you to provide string/Doc-returning blocks_writer and inlines_writer functions, which means you still have the fundamental escaping issue. And doing a standalone output with a template seems to want you to do more work constructing a title block, table of contents, and things like that, so I'm going to leave templates alone for now. check-in: d170e9dd3f user: Sand tags: trunk

pandoc.utils.to_simple_table would do this for us, but it would additionally throw out other information that we can represent in BBCode, such as row headings, and multiple table bodies with their own headings. check-in: df5cb745cd user: Sand tags: trunk

Otherwise the filename:lineno doesn't appear with the stack trace.
https://github.com/jgm/pandoc/issues/11406 check-in: 9230a98b7e user: Sand tags: trunk

pandoc.mediabag.fetch returns 2 values, so in the success case the assertion was evaluating to the mime_type, and then the assertion message rather than the file data. check-in: 6cdeacd605 user: Sand tags: trunk