Sample lua custom writer fixes (mostly editorial)

[wlupton]

Here are some comments on the v2.14.1 sample lua custom writer. Please let me know if I should create separate issues for any of them.

1. Attribute sorting: attributes(attr) uses pairs(attr), which I believe means that the attribute order is unpredictable (not a problem per se, but annoying if ever comparing the output from multiple runs). Probably it should do whatever the Haskell HTML writer does?

2. Link attributes: Link(s, tgt, tit, attr) ignores the attr argument.

3. Image versus figure: CaptionedImage(src, tit, caption, attr) doesn't check for empty captions. I'm not sure about this one: I did hit it in real life, but it's possible that it was caused by a lua filter fiddling with the caption.

4. Unintentional head global? Table(caption, aligns, widths, headers, rows) can update a global head variable that doesn't appear to be declared or used anywhere. Probably it can just be removed?

[jgm]

PRs would be welcome for any of these!

[wlupton]

Of course :).

What would be the preferred resolution for item 1 (attribute ordering)? Could you possibly briefly summarize what the Haskell HTML writer does?

[tarleb]

Attribute ordering would require changes to the way `Attr` values are handled in the custom writer. Currently, attributes are converted into an (unordered) Lua table, and there is no way to recover attribute order. I'd suggest to open a separate issue for this. It might become easier to change once the new Lua marshalling methods are in place (#7191).

[wlupton]

Thanks. I'll create a separate issue (#7489).

[wlupton]

PR #7493 addresses items 2-4 plus fixes another small problem that I noticed when making the changes (the table caption wasn't escaped).

Comparing the built-in HTML writer with the updated sample.lua I noticed:

• The writer needs to handle attribute data- prefixes, so it has to know the standard attributes for each element. This could be hard-coded in the lua or could a utility function supply this info?
• The built-in writer is outputting some aria- attributes (these relate to accessibility?)
• sample.lua uses a mixture of single and double quotes. Not a problem, but mildly annoying! Personally I prefer single quotes in code, which makes it easier to use double quotes in output: would this be acceptable?
• sample.lua doesn't usually put a space before /> following an attribute value, whereas the built-in writer usually (always?) does. Again not a problem, but consistency would be nice? (Personally I prefer not to output such spaces.)
• sample.lua is a little more liberal with newlines. This really isn't a problem!

I mention all the above just to solicit some thoughts on whether it's worth trying to make sample.lua generate the same output as the built-in HTML writer (maybe ignoring unquoted whitespace). If it did then this could be validated on some test documents, which might help to keep it up to date.

[wlupton]

PR #7493 notes the single/double quote inconsistency and I've offered to push some more updates. Note that there are some related comments (some of which overlap) in #6729 and I'll take those into account too.

Something else to check is that everything is escaped where necessary. I fixed one such case (table captions) but I suspect that there may be more.

[mb21]

Should we close this issue in favour of more specific ones or new PRs?

[wlupton]

I can take an action to capture any outstanding items in new issues, potentially with PRs, at which point we can close this.

[tarleb]

I've update sample.lua to use single quotes for strings, which I believe was the last point without a separate issue. Personally I'd consider aria attributes out of scope for the custom writer.