Re: Different behaviour of literal blocks depending on definition way
Posted by
mojavelinux on
Oct 28, 2018; 10:02am
URL: https://discuss.asciidoctor.org/Different-behaviour-of-literal-blocks-depending-on-definition-way-tp5912p6555.html
Option 1 is a shorthand in AsciiDoc that traces back to AsciiDoc Py. Technically, it's not a literal block, but rather a literal paragraph. It's gets a little bit of special treatment.
I agree that for anything more than a single line, the block form is preferred. I tend to use the literal paragraph for terminal commands only.
Cheers,
-Dan
On Fri, Sep 15, 2017 at 12:15 PM abelsromero [via Asciidoctor :: Discussion] <
[hidden email]> wrote:
According to documentation a literal block can be defined in three ways
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.
--