Separate custom node handlers for block and inline

[knuesel]

Description

This addresses #6940 by storing custom block and inline handlers in seperate tables. This way it is possible for the same class name (content-visible) to have one handler for divs and another for spans.

Currently this PR doesn't add a handler for Spans, so they don't get a custom node wrapper, but they still get a working content-hidden treatment, like code blocks. Without this PR, conditional spans cause an error.

If desired, I can add custom nodes for inlines (to wrap conditional spans), and wrap conditional code blocks using the existing ConditionalBlock.

I'll be happy to add some tests and documentation if the general idea is approved, and after it's decided what to do about custom nodes for conditional spans and code blocks.

Checklist

I have (if applicable):

• filed a contributor agreement.
• referenced the GitHub issue this PR closes
• updated the appropriate changelog

[cscheid]

(Let me just start by saying I'm very impressed that you were willing and able to dig in this part of the code!)

[cscheid]

A few stylistic requests:

Lua code is supposed to be snake_case. We're slowly improving our codebase (which as you will certainly have experienced is wildly inconsistent). However, we're trying to not make matters worse with new commits. namedHandlers -> handlers is an improvement, but can you make byAstName into by_ast_name?

[knuesel]

Thanks! I've renamed the field to by_ast_name.

[cscheid]

This looks very good. There's one small renaming I would want to do: table is a Lua built-in, and using it as a local name is asking for future trouble. In addition, what you're passing there is a key, and not a table, so I'd use key instead. But I don't want to ask you for yet another change, so I'm going to merge as is and make the tiny fix myself.

Thanks again. Looking to the future, since I seem to recall you want conditional spans.

Tests: we don't have great infrastructure for testing our Lua codebase in isolation (because it all runs inside Pandoc). We do much better with end-to-end render tests, and those tend to cover basic features like this one. It's not ideal, but it's better than nothing.

With that said, for document-level features, we will 100% want tests that cover expected behavior. You'll find a number of those test documents in our tests/docs subdirectory. Specifically, you'll probably want to use the in-document testing we have in YAML under _quarto: tests:. Hopefully that's enough for you to go on, but please reach out if you need more assistance.

[cderv]

Thanks @knuesel !

Should #6940 be closed by this PR ?

Just in case it should have been (github closing keyword did not worked here)

[knuesel]

Good point for the table name (don't hesitate to ask for as many changes as you want next time, I don't mind!).

Regarding conditional spans: I think this PR was all I needed for my projects: it's enough to get [...]{.content-visible ...} working.

Thanks for the tips on tests. For the future of conditional nodes I was wondering if you eventually want custom nodes for all of them. Currently content-visible is working with divs, code blocks and now also spans, but only the divs get wrapped in a ConditionalBlock. We could wrap code blocks in those too, and define a new custom node type (with name ConditionalInline I guess) to wrap spans. But maybe it's better to wait until someone actually needs it.

@cderv yes thanks for the reminder, it's closed now.

[cscheid]

Regarding conditional spans: I think this PR was all I needed for my projects: it's enough to get [...]{.content-visible ...} working.

Ok. This is great, I thought we would have needed additional code! In that case we should 100% add document-level tests with expected outputs. Would you be willing to add some?

But maybe it's better to wait until someone actually needs it.

Agreed. It's not even clear to me that we need ConditionalBlock. I wrote that in part to test the (at the time new) AST infrastructure.

[knuesel]

Sure, I'll prepare some tests.