Wrapped lines are numbered in source blocks with very long lines

[robertpanzer]

When having very long lines in a source block that are wrapped, the wrapped lines are also numbered, so that the last lines are not numbered.

When you render this document:

= Test
:source-highlighter: coderay

[source,xml,numbered]
----
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
...
</project>
----

the project element is wrapped over 4 lines, so that the last 3 lines are not getting any line numbers.

Tried both with coderay and with pygments.

[mojavelinux]

This problem is related to line numbering. There are few things going on here. First, the nowrap option is not honored in this scenario. So if you add %nowrap to the listing, you still get this problem (at least for CodeRay). Second, if the nowrap option is fixed, unfortunately, I don't see how the line numbers can know about where the wraps occur. In that case, I think you have to switch to coderay-linenums-mode: inline. Finally, that introduces a new problem that the wrapped lines bleed into the line number gutter.

You almost have to use nowrap when you use line numbers, and we need to make sure it is honored.

[mojavelinux]

To clarify, the focus of this issue is to get the nowrap option to work when using table-based line numbers. I don't know what else we can do address it. I guess down the road we could switch to using individual table rows for each line number and corresponding line of source code, but that would be a major change to the HTML and stylesheet.

[mojavelinux]

It appears this is a general problem with source highlighting libraries. The authors of those libraries often recommend disabling line wrapping when using line numbers.

[mojavelinux]

We should probably document this as well.

[mojavelinux]

I'd even consider automatically enabling nowrap when line numbers are on. That might save people a lot of hassle.

[Rajind]

@mojavelinux I think enabling nowrap option automatically will be much better. BTW is there any workaround this until this is fixed.

[Rajind]

@mojavelinux Just figured out what you meant. So this works for now. Hope for a fix in next milestone. :-)

[mojavelinux]

Correct. One way to fix it is to use the inline linenums mode. The other way to fix it is to apply a patch to the stylesheet that sets the white-space: pre on the nested <pre> element.

[owenh000]

One of the important advantages of line numbering, in my opinion, is that it allows content to be wrapped while still showing the reader where the original line breaks were. With regular wrapping, line breaks are added as required and the user may not be sure where the real line breaks actually were (an important detail in some cases). Alternatives include adding icons for where the real line breaks are or disabling wrapping, but neither of these work as nicely as line numbering. Just my thoughts—

Here is the workaround that Dan mentioned in the previous comment, as I understand it. When added to a docinfo.html, the following CSS disables wrapping and enables horizontal scrolling for a syntax-highlighted source block with line numbering enabled. This is currently the best option for me because it allows me to still use the coderay-linenums-mode: table mode which allows the reader to copy/paste from the source block without getting all the line numbers also. (As far as I can tell, there is no easy way to get decent line numbers with wrapping, as commented above).

table.CodeRay { display: block; overflow-x: auto; }
td.code > pre { white-space: pre; }

If all line lengths are kept below the wrapped length, the Asciidoctor-PDF --attribute source-highlighter=rouge option can be used to also have line numbering for the PDF output. Wrapped lines will still "bleed into the line number gutter" there as mentioned above.

[mojavelinux]

It turns out, there was a bug in the CodeRay stylesheet with linenums in table mode. The nested <pre> was not inheriting the pre setting. Now it should work like Pygments.

I also documented in the user manual that you must set *-linenums-mode to inline when wrapping is enabled on preformatted blocks. This is a shortcoming of the source highlighters. The problem needs to be fixed there as this is outside of Asciidoctor's control.