Chained or nest admonition blocks not processed properly

[gdamore]

The following snippet (from nng_options.5.adoc) is not processed properly by libasciidoc.

In particular, I have several admonition blocks inside a description list item. This seems to confuse the libasciidoc parser, that winds up just putting them out inline (including with the + on a blank line). asciidoctor processes it correctly.

The entire source file for this is at https://github.com/nanomsg/nng/blob/master/docs/man/nng_options.5.adoc

(I was trying to build a Go program to process the files automatically in this directory -- initial results are mostly promising, and its a lot (orders of magnitude) faster than asciidoctor.)

I'm not familiar enough with your parser to suggest any immediate fix, but this will be a show stopper for me.

[[NNG_OPT_REMADDR]]
((`NNG_OPT_REMADDR`))::
(xref:nng_sockaddr.5.adoc[`nng_sockaddr`])
This read-only option may be used on dialers and connected pipes, and
represents the address of a remote peer.
Not all transports support this option.

[[NNG_OPT_SENDBUF]]
((`NNG_OPT_SENDBUF`))::
(((send, buffer)))
(((buffer, send)))
(`int`)
This is the depth of the socket send buffer as a number of messages.
Messages sent by an application may be buffered by the socket until a
transport is ready to accept them for delivery.
This value must be an integer between 0 and 8192, inclusive.
+
NOTE: Not all protocols support buffering sent messages;
generally multicast protocols like xref:nng_pub.7.adoc[_pub_] will
simply discard messages when they cannot be delivered immediately.

[[NNG_OPT_SENDFD]]
((`NNG_OPT_SENDFD`))::
(((poll)))
(((select)))
(((send, polling)))
(`int`)
This read-only option is used to obtain an integer file descriptor suitable
for use with
http://pubs.opengroup.org/onlinepubs/7908799/xsh/poll.html[`poll()`],
http://pubs.opengroup.org/onlinepubs/7908799/xsh/select.html[`select()`],
(or on Windows systems
https://msdn.microsoft.com/en-us/library/windows/desktop/ms741669(v=vs.85).aspx[`WSAPoll()`])
and similar functions.
+
This descriptor will be *readable* when the socket is able to accept a
message for sending without blocking.
When the socket is no longer able to accept such messages without blocking,
the descriptor will *not* be readable.
+
IMPORTANT: Applications should never attempt to read or write to the
returned file descriptor; use should be limited to polling system calls only.
+
IMPORTANT: This option is incompatible with
xref:nng_ctx.5.adoc[`nng_ctx`] contexts and should not be used on a socket
where they are in use.
+
TIP: While this option may help applications integrate into existing polling
loops, it is more efficient, and often easier, to use the asynchronous I/O
objects instead.
See xref:nng_aio_alloc.3.adoc[`nng_aio_alloc()`].

[[NNG_OPT_SENDTIMEO]]
((`NNG_OPT_SENDTIMEO`))::
(((send, timeout)))
(((timeout, send)))
(xref:nng_duration.5.adoc[`nng_duration`])
This is the socket send timeout in milliseconds.
When a message cannot be queued for delivery by the socket for this period of
time (such as if send buffers are full), the operation will fail with a
return value of `NNG_ETIMEDOUT`.

[xcoulon]

ok, thanks for reporting this issue @gdamore I will definitely take a look at it.

[xcoulon]

see also #497 for the processing of index terms in the labeled item terms. Eg:

((`NNG_OPT_REMADDR`))::
...

[gdamore]

Haha. I guess my big reference manual has lots of content that catches a lot of corner cases.

Let me know if you want the full doc set. Running libasciidoc and comparing to asciidoctor likely to be informative.

[xcoulon]

Indeed, it's always good to have a large document to catch such corner cases! ;)
I fixed #497 last night, and I will focus on this issue here next.

[gdamore]

Just an FYI, I'm waiting for a resolution on this before I try switching over my tool chain again.

[xcoulon]

Just an FYI, I'm waiting for a resolution on this before I try switching over my tool chain again.

@gdamore yes, I remember this is a stopper for you. I have been working on it and it is almost solved ;)

[xcoulon]

@gdamore after merging #500, the remaining differences between the output of Asciidoctor vs Libasciidoc are a few blanklines added by Asciidoctor, such as:

...
<p>


(<code>int</code>)
This read-only option is used to obtain an integer file descriptor suitable
for use with
...

which are not present in the HTML generated by Libasciidoc:

...
<p>(<code>int</code>)
This read-only option is used to obtain an integer file descriptor suitable
for use with
...

These blank lines do not affect the HTML rendering, AFAICS.

The rest of the generated HTML is the same with both tools. 😀

[gdamore]

Awesome!! I’ll give it a look! Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Xavier Coulon <[email protected]> Sent: Saturday, March 14, 2020 1:19:29 AM To: bytesparadise/libasciidoc <[email protected]> Cc: gdamore <[email protected]>; Mention <[email protected]> Subject: Re: [bytesparadise/libasciidoc] Chained or nest admonition blocks not processed properly (#492) @gdamore<https://github.com/gdamore> after merging #500<#500>, the remaining differences between the output of Asciidoctor vs Libasciidoc are a few blanklines added by Asciidoctor, such as: ... <p> (<code>int</code>) This read-only option is used to obtain an integer file descriptor suitable for use with ... which are not present in the HTML generated by Libasciidoc: ... <p>(<code>int</code>) This read-only option is used to obtain an integer file descriptor suitable for use with ... These blank lines do not affect the HTML rendering, AFAICS. The rest of the generated HTML is the same with both tools. 😀 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#492 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJ4G7KQSLRCK5ED73W56S3RHM4ZDANCNFSM4K7H66VA>.