highlight.js kills line numbering

[wirepatch]

Using the default »pygments« highlighter allows for coexistence of highlighting and line numbering honoring the linenumbering attribute of e.g. <programlisting> elements. However using non-default verbatim-syntax-highlighter="highlight.js" works well but no line numbers show up regardless of setting or not setting the linenumbering attribute.

BTW: Having line numbering activated by default IMHO collides with current Docbook default behavior of line numbering being de-activated. In my document instances ~95% of all programlisting> elements are small snippets where line numbering would be distracting. So I would have to add <programlisting linenumbering="unnumbered">. Is there a transformation parameter allowing to set line numbering off by default?

[ndw]

Thanks for the report. There are several parameters related to verbatim style, but having just looked again, I'm not sure they're documented very well. 😞 The easiest thing is probably to set $verbatim-style-default to plain. You could also set $verbatim-number-minlines to a large number, but I'm not sure you can (easily) override that in markup.

I'll take another look. I confess, I've been annoyed by the fact that line numbering is distracting in short snippets too. But I'm also annoyed if short and long snippets are formatted differently, and I'm not sure how to solve both those things simultaneously!

[ndw]

One problem is that highlight.js doesn't do line numbers. Line numbers have to be added after synax highlighting (otherwise the presence of the numbers would confuse the parser for the syntax highlighter) so if you want to use in-browser highlighting, you need in-browser line numbering as well.

I'll try to improve the documentation in this area.

[wirepatch]

Stupid me! I was inferring line numbers being provided separately i.e. in a table column rather than being part of a <pre><code>... block. Then obviously line numbers will interfere with highlight.js's scripts. Reverting to pygments.

[ndw]

The table column trick kind-of, sort-of works. I have sometimes wondered if it could be implemented more cleanly with modern CSS. The problem with that approach, however, is that the alignment between numbers and lines depends on both columns having the same spacing. Font changes or an inline graphic can make that fail and the result is really ugly.

It isn't possible to put the column numbers and lines on the same row (with tr/td markup) because of the same parsing problem. I suppose some JavaScript run after the highlighting finishes might be able to add line numbers. Not sure what hook you could use for that, however.

[ndw]

There is an after:highlight hook for highlight.js. That might be a fun afternoon of hacking sometime. But I'm not promising to make it a priority! :-)

[wirepatch]

The highlightjs-line-numbers.js plugin extends highlight.js providing CSS styleable line numbers, see here.

So far I could not (yet) figure out how to mix listings with and without line numbers since the beast is being configured on page level. I've filed a related issue

[ndw]

A quick skim of the source suggests that adding 'nohljsln' to the class attribute would disable it.

[wirepatch]

Thanks for the report. There are several parameters related to verbatim style, but having just looked again, I'm not sure they're documented very well. 😞 The easiest thing is probably to set $verbatim-style-default to plain. You could also set $verbatim-number-minlines to a large number, but I'm not sure you can (easily) override that in markup.

I'll take another look. I confess, I've been annoyed by the fact that line numbering is distracting in short snippets too. But I'm also annoyed if short and long snippets are formatted differently, and I'm not sure how to solve both those things simultaneously!

Docbook offers the optional linenumbering attribute allowing authors to mix plain and line number annotated listings. A question being left is about the transformation default in absence of linenumbering: I do advocate for unnumbered rather than current default numbered.

[ndw]

I'm somewhat reluctant to change defaults*. An unknown number of users may be relying on the default behavior and it might be easy to miss the change. But I will at least try to make it easier to change the default.

• Which isn't the same as saying I never do, of course, but this would potentially change a lot of documents...

[wirepatch]

Fair enough. But you may as well consider people like myself making the transition from the older (or shall I still say current ?) set of style sheets implementing the unnumbered default.

For myself its not a big deal either crafting a script changing the sources accordingly or taking advantage of the parameter you inferred for setting the default explicitly.

[ndw]

That's a point. I didn't realize at the time that I was changing a default from there.

[ndw]

I have something working, but it's all a bit of a hack. I'm going to think about how maybe things could be restructured so this is easier.

[wirepatch]

👍👍