It is weird that div.docbook code has white-space: normal even within pre, resulting in

instead of

(source: https://nixos.org/nixos/nix-pills/working-derivation.html)

Oh gush.

Do I and we really need to study a book on DocBook to make multi-lines.

If txt as is - is a way more handy, practical and works. And works a way better then DocBook, maybe we use txt, until someone makes DocBook work, and then convert txt's to DocBook.

Because seems like now we have both at the same time. And I not touched example right under changes (in "Enough of nix-repl") - because it presents formatted code block content, and it is txt example.

Or I need to also read a book to format code. Ok.

@jtojnar

I can make it multi-line by inserting line-breaks <sbr/>.
But sbr not encountered once, at this point, in the whole source code.

So should I do that? Or I need more research and do something else.

At this point I not found a better way for DocBook then to spam <sbr/>.

And this is the best professional suggestions found so far:

Chapter 27. Program listings

You can turn off interpretation of characters that would be recognized as XML markup by enclosing the text in a CDATA section.

(aka "disable the DocBook parsing for code blocks")

OR

Formatting listings

Formatting a program listing for HTML output is best handled by CSS.

(aka "if you use a DocBook to get HTML - avoid DocBook formatting in code blocks, and use CSS directly")

And it is a source "DocBook XSL: The Complete Guide, Fourth Edition": http://www.sagehill.net/docbookxsl/ProgramListings.html

TXT definitely works much worse than DocBook – it does not format the screen dump, nor does it distinguish between the user input and output.

The line breaks are there in the DocBook, you just need to fix the CSS (see the second screenshot above). Something like the following should work:

div.docbook pre code {
    white-space: pre;
}

Ok. Thank you. I really do not know CSS.

I would do my best, when I get back to this one.

I don't think so, the existing code is well structured and semantically nice. New submissions don't have to be so complicated, but there is not a good reason to undo it for the existing stuff. I'd be interested in PR to fix the whitespace handling.