With some code blocks, the highlighter might produce a <span> element that "spans" multiple lines. When that happens, the tableize_code method will generate HTML that nests <div>s inside the mutli-line <span>.
This PR addresses the issue by detecting these multi-line spans and splitting them, so that each span lives on its own line. That way, tableize_code can't mess up the formatting.
With this fix in place, the above codeblock now looks like this:
This may not be the best way to accomplish the goal of having correct formatting, for a few reasons:
I've violated the cardinal rule: Never parse HTML with regexes. That said, we're looking for a very specific pattern, so maybe it's ok here?
The regex for finding the start pattern uses negative lookahead. In addition to being pretty deep in the bag of tricks, it can also result in relatively slow performance. I ran this code against my blog of 212 posts (after deleting the code highlighting cache) and didn't notice a significant difference in generation time, but YMMV.
Both Rouge and Pygments have an option to generate their own line numbers. It might be better to lean on those features. However, the resulting markup is different for each of them, and it would be harder to accomplish the goal of being able to mark lines in code blocks, which is a lot of what tableize_code is doing.
Note that I pulled the span-splitting code into its own class to make it easier to test. I included a higher-level test of the formatter itself as well. If the extra class isn't desirable, I can merge the implementation back in. But if you like this approach, there's some opportunity to refactor out some of the other work being done in the Renderer.
With some code blocks, the highlighter might produce a
<span>
element that "spans" multiple lines. When that happens, thetableize_code
method will generate HTML that nests<div>
s inside the mutli-line<span>
.With the current code, the result of this:
is this:
This PR addresses the issue by detecting these multi-line spans and splitting them, so that each span lives on its own line. That way,
tableize_code
can't mess up the formatting.With this fix in place, the above codeblock now looks like this:
This may not be the best way to accomplish the goal of having correct formatting, for a few reasons:
Both Rouge and Pygments have an option to generate their own line numbers. It might be better to lean on those features. However, the resulting markup is different for each of them, and it would be harder to accomplish the goal of being able to mark lines in code blocks, which is a lot of what
tableize_code
is doing.Note that I pulled the span-splitting code into its own class to make it easier to test. I included a higher-level test of the formatter itself as well. If the extra class isn't desirable, I can merge the implementation back in. But if you like this approach, there's some opportunity to refactor out some of the other work being done in the
Renderer
.