How do I read an error statement?

[bwklein]

What is this telling me? Where should I look in the .adoc file to figure out what to fix?

Error: unable to render full document: failed to render document elements: error while rendering section: template: section 1:3:41: executing "section 1" at <renderElements $ctx .Elements>: error calling renderElements: error while rendering section: template: section 2-6:2:35: executing "section 2-6" at <renderElements $ctx .Elements>: error calling renderElements: unable to render ordered list: template: ordered list:5:3: executing "ordered list" at <renderElements $ctx $item.Elements>: error calling renderElements: unable to render a list block: unsupported type of element: types.OrderedListItem

[xcoulon]

@bwklein the problems seems to be with nested list items but I agree with you, the message lacks information about the location in the document :(

[xcoulon]

@bwklein if you could manage to narrow the portion of your document which causes troubles, I could take a look at the bug.

[bwklein]

Its a huge document, is there any information in the error to tell me what part to isolate?

…

On Sun, Feb 28, 2021, 09:33 Xavier Coulon ***@***.***> wrote: @bwklein <https://github.com/bwklein> if you could manage to narrow the portion of your document which causes troubles, I could take a look at the bug. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#830 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4LF7ULY6F3RT54ZKYI3JLTBJ46RANCNFSM4YLG5BAQ> .

[xcoulon]

The problem is that the error did not happen during the parsing, in which case we could have some information. But instead, the problem occurs during the rendering, and the "AST" does not retain the elements' location in the document (yet).

However, of you're running libasciidoc from the command line, then you could use the --log=debug flag to see if you get more information about the portion that causes the troubles.

[bwklein]

Here is the source .adoc file and the debug output.
I am looking through the log too, to try to figure out what is happening.

user-manual.zip

[bwklein]

Note: I am currently building this document with a Ruby Asciidoctor setup, I am testing to see if we can migrate to your package instead. It currently takes about 8 minutes to build a Hugo site and the majority of that time is processing about 100 adoc files.

[xcoulon]

nice! so,are you integrating the library into Hugo, then?

[bwklein]

Yes, that's the goal. Call it with the external helpers.

…

On Sun, Feb 28, 2021, 13:36 Xavier Coulon ***@***.***> wrote: nice! so,are you integrating the library into Hugo, then? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#830 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4LF7RQHYC65AM4KVME2O3TBKZO3ANCNFSM4YLG5BAQ> .

[bwklein]

@xcoulon does the log file in #830 (comment) tell you anything about what might be going wrong?

[xcoulon]

@bwklein sorry, I didn't have time to look at it yet :(
Let me give it a look now

[xcoulon]

ok, so here's what I found: in the "Creating Complex Geometry / Trusses" section, you have use a list item continutation after the image::pyro-ui-toolbar-views.png[] block to join the next list item:

. Click the *2D View* tab
. On the toolbar, click the *Reset to Front* option.
+
image::pyro-ui-toolbar-views.png[]
+
. On the drawing toolbar, select the *Slab Obstruction Tool* (image:pyro-ui-icon-slab.png[]).
(...)

if you remove the + character on line 3160, it works with libasciidoc (the same removal is also needed on line 3188). For now, Libasciidoc does not handle the case where the "continued element" is a list item. Instead, it expects something like a paragraph, a delimited block, etc.

Please note that from what I could see, Asciidoctor produces the same output with or without the list item continuation (+)

[xcoulon]

I've opened the #837 issue to fix that

[bwklein]

Excellent, I will look at that. That syntax is there because we want the image associated with the bullet and not in a separate block, breaking the list above and below it.
Having said that, it might not make any difference in the final output, so I will verify and resolve as needed.

Now, what did you look at in the log to find this? How can I figure it out for myself next time?

[xcoulon]

I believe it's the + character after the image that needs to be removed: the + character above the image:: macro works and should associate the image with the current bullet.

I did not look at the logs, I tried to narrow the doc (removing half of it, keeping the part that broke) until I could locate the portion that caused the troubles. So, it was empirical :| But granted, the logs should be more explicit about the source of the problem

[bwklein]

Yep, I removed the trailing + and it builds without error.