Hi Dan, I interpret the spec slightly differently.
An admonition block is: [NOTE] ======== some stuff ======== but [NOTE] note contents etc etc is not an admonition block, its an admonition paragraph, see http://www.methods.co.nz/asciidoc/userguide.html#X28 If it were a block it would terminate the list, but since its a paragraph, and the first one after the list item, it will be included in the list without needing list continuation +s, see http://www.methods.co.nz/asciidoc/userguide.html#X64 list behaviour. Both asciidoc and asciidoctor do this correctly, ie they do not terminate the list. With asciidoc blank lines are ignored, other than separating things like paragraphs when they cannot be otherwise distinguished. But the [NOTE] allows the admonition paragraph to be distinguished, so the blank line between the list item and the admonition paragraph should have no effect, which is the case in asciidoc but in asciidoctor it triggers differing layouts. I do not have a strong opinion on indenting the admonition paragraph or not, but I think doing something different based on the blank line is wrong, and even if it was right it is too subtle. Cheers Lex On 2 December 2014 at 17:21, Dan Allen <[email protected]> wrote: > What you are describing is expected behavior of AsciiDoc (the syntax). I'll > explain why this is the case by citing the AsciiDoc "specification" rules as > I interpreted them when implementing Asciidoctor. > > --- > > Rule #1: A block attribute line is a block terminator > > [NOTE] represents a block attribute line. Thus, regardless of whether you > have a blank line before the block attribute line, this terminates the > previous block and starts a new one. > > Rule #2: Block content must be adjoined to a list item using a list > continuation line. > > [NOTE] creates an admonition block, which is block content. In order to > block content to a list item, you must use a list continuation line (a line > that only contains a `+`). > > --- > > To get the behavior you are after, you need to write the AsciiDoc as follows > (added lines in bold). > > [source,asciidoc] > ---- > = Behaviour of `NOTE` blocks in lists > > Here is some text > [NOTE] > Note A (will be separate from "Here is some text") > > Here is some more text > > [NOTE] > Note B (blank line preceding definition) > > Here is a list > > * item 1 > > ** subitem 1 > + > [NOTE] > Note 1 (will be adjoined to subitem 1) > > * item 2 > > ** subitem 2 > + > [NOTE] > Note 2 (will be adjoined to subitem 2) > > * item 3 > + > [NOTE] > Note 3 (will be adjoined to item 3) > > * item 4 > + > [NOTE] > Note 4 (will be adjoined to item 4) > ---- > > If AsciiDoc Python doesn't implement this correctly in some cases, then it's > not being consistent with its own rules. You shouldn't rely on that > behavior. You should always use list continuation lines to adjoin complex > content. > > Cheers, > > -Dan > > On Mon, Dec 1, 2014 at 4:50 AM, j. van den hoff > <[email protected]> wrote: >> >> I've stumbled about the following minor difference in behaviour between >> both processors. consider the following input: >> >> 8<--------------------------------------------------- >> = Behaviour of `NOTE` blocks in lists >> >> Here is some text >> [NOTE] >> Note A (no blank line preceding definition) >> >> Here is some more text >> >> [NOTE] >> Note B (blank line preceding definition) >> >> Here is a list >> >> * item 1 >> >> ** subitem 1 >> [NOTE] >> Note 1 (no blank line preceding definition) >> >> * item 2 >> >> ** subitem 2 >> >> [NOTE] >> Note 2 (blank line preceding definition) >> >> * item 3 >> [NOTE] >> Note 3 (no blank line preceding definition) >> >> * item 4 >> >> [NOTE] >> Note 4 (no blank line preceding definition) >> 8<--------------------------------------------------- >> >> when processed with `asciidoc' all notes are aligned identically >> independent of whether there is a blank line preceding the definition of the >> Note or not. with `asciidoctor' notes embedded in lists are indented _if_ >> there is no blank line preceding the definition. this happens consistently >> in html as well as pdf formatted output. >> >> question: which behavior might be considered more "correct" (one can argue >> for both, of course). >> >> thx/joerg >> >> -- >> Using Opera's revolutionary email client: http://www.opera.com/mail/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "asciidoc" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/asciidoc. >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Dan Allen | http://google.com/profiles/dan.j.allen > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/asciidoc. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
