A better mechanism for extending, toggling, option-ing, adapting, adjusting …

[kivikakk]

It's become clear to me that Comrak's options and formatting systems are struggling under the weight of what we'd all like it to do slightly differently. Some examples:

• AST
  • Add new node types.
• Parsing
  • Disable built-in parsing rules, block and inline.
  • Add new parsing rules, block and inline.
  • Add new post-processing rules.
• Formatting
  • Include (or omit) certain attributes in HTML tags for certain node types.
  • Completely change how certain node types are formatted, while retaining the built-in behaviour for others.

I'd like to add to this list to get an idea of where extensibility is actually called for, in order to work out how to provide it in Comrak's internal design with more orthogonality than the current "add another field to an options struct and sprinkle conditionals everywhere" design. Maintaining performance is a key consideration.

If anyone has anything to add to this list, or design suggestions for ways to achieve this goal, please comment!

Refs: #268, #261, #259, #258, #253, #251, #246, #244, #208, #204, #180, #164, #149, #137, #136, #133, #132, #130, #129, #52, #48, #40, #23, etc.

[YJDoc2]

Hey, may I post a tldr-type comment that outline each of the issue/pr you have mentioned, so to have a better overview of all stuff? Or would it be too noisy to have that giant-ish comment?

[kivikakk]

If you feel like that'd help, by all means feel free! I think a giant-ish comment is totally fine.

[kivikakk]

We got builders, and frankly I think this is now Good Enough.