Posted by abelsromero on Sep 15, 2017; 6:15pm
URL: https://discuss.asciidoctor.org/Different-behaviour-of-literal-blocks-depending-on-definition-way-tp5912.html

According to documentation a literal block can be defined in three ways

1. Indenting the first line of a paragraph by one or more spaces
2. Applying the literal attribute to a paragraph or block
3. Using the literal block delimiter (.... )

ref: http://asciidoctor.org/docs/user-manual/#literal-text-and-blocks

But I have seen that when using the second and third options the block does not continue the previous content (example below). This seems odd to me and forces me always to back-track and relate it with a `+`.

Let’s say I have something like this:

. Step 1

 $ nice magic command here

. Step 2

….
$ nice magic command also \
but this is a \
 multiline example
….

The first block is included as part of the numbered element and is properly indented. However in the second case the block is not, so I have to add a + before it.
I suspect this may have something to do with this sentence in the documentation “When you want an entire block of text to be literal and would prefer not to indent it, set the literal attribute on top of the element.”
But honestly I don’t get why the way of declaration should affect how the block relates to precedent elements.

Also I have seen that when adding a subs on top (e.g. [subs=”+attributes”]), it behaves as options 2 and 3 always.

So then, why is that? Is option 1 current behavior a bug or a hidden shortcut?

PS: I know I can use option 1 for multi-line also, but I find the delimited way much more expressive and easy to spot in longer and more complex documents.