@chuck-confluent I'm afraid that I don't know Asciidoctor-PDF so I don't know if this suggestion makes sense but if this were a webpage you could specify a CSS rule that did nothing for errors (since you presumably don't want to highlight those). Perhaps you can do something similar here?

Other options:

1. You could subclass the JSON lexer and edit the brace matching rule to not highlight unmatched braces as errors.

2. Contact the Asciidoctor-PDF people and see if there's some way it can recognise the code in these slides as a contiguous block.

Hope something there helps!

@pyrmont Oddly, I think @chuck-confluent has the right idea about the desired behaviour of lexers: our goal is not to highlight all errors, but to make the user's input look nice. I know it can be complex, but I think it's a reasonable goal to be able to highlight partial JSON files.

Thanks all for responding! Unfortunately asciidoctor treats codeblocks as indivisible units that are meant to fit on one page. If the block is big enough, it will nicely break to a second page, but in a way I can't control.

Since there's a CSS rule that suppresses error highlighting, I suspect it's also possible in asciidoctor pdf. I'll ask over there.

@chuck-confluent It's definitely the case that checking syntactical correctness is a non-goal of Rouge so @jneen is right to say that the JSON lexer could be made to support your use case in a way that wouldn't be inconsistent with Rouge's philosophical approach.

I'd need to test it against your example but it might be the case that simply adding a rule for closing braces here to the :root state would fix the issue:

I think the CSS rule (or equivalent) is the fastest route for your circumstance but if that doesn't work out, let us know.

Thanks, I've got an issue asking for help over on the asciidoctor github asciidoctor/asciidoctor#3605