asciidoctor-lists
asciidoctor-lists copied to clipboard
Hide empty section not empty when present items have no caption
When elements for the lists are present in the document but do not have a caption, the "hide_empty_section" option does not work properly. It will display an empty list (heading but no entries) but will not be empty (and thus removed).
This is kind of "double bad" because there is no list (even though there are items relevant to the list) but the section is also not hidden (even though it appears empty).
We produce documents using this extension and I've seen a couple reports about this recently from my users.
== First heading
Some text
== Second heading
|===
|A |table
|With |Data
|===
== Third heading
list-of::table[]
[... same code as above but with table caption]
== First heading
Some text
== Second heading
.Now with caption!
|===
|A |table
|With |Data
|===
== Third heading
list-of::table[]
I think the list should show "something" even when there is no caption present, maybe something like "Unnamed table"? Maybe also a warning in the console that the extension has detected that items that are relevant are present but do not have a caption.
Btw. the current implementation also leads to this output in verbose mode because the ID that is generated for the uncaptioned elements here is not known to the converter and it gets confused when trying to prcess the xrefs generated by the extension.
(Outputting the
references_asciidoc
during generation shows that this ID comes from the extension).
EDIT: Trying to figure out where the IDs are generated but I think this happens during the final processing after the extension ran.
The problem stems from this check: https://github.com/Alwinator/asciidoctor-lists/blob/main/lib/asciidoctor-lists/extensions.rb#L47 that has no "else" condition for when an element is present but has no caption or title.
@r0ckarong As you correctly figured out the extension first replaces the list-of-elements with random UUIDs (or an element id if set). Then later in the TreeProcessor they are replaced with the actual lists. It is impossible to implement it otherwise because the lists are not always at the end of the document and at the moment when rendering a list, the whole document is not processed yet.
And you are right about your edge case. It would be great if you could create a pull request with the bug fix and a test for your issue! I will merge it once it is done! :)