Christian Clason

I'll think about. We can't guard against _every_ misconfiguration; nothing official recommends or even suggests lazy-loading, so it's on users (or whatever content creators) to push their features responsibly.

We'll revisit this for the (completely rewritten) 1.0 release. Until then, the pinned issue is the best documentation.

The documentation is hopelessly outdated and will have to be completely rewritten for 1.0 anyway, so I'm not sure it's worth polishing this up now.

Thanks, I added it.

There is one for direct parents, but that's it.

Thank you for this! This is very valuable information to collect, and a massive gap in our documentation. Much as it pains me to write this, this will be (hopefully)...

> Currently the built in comment module is using the commentstring option as is, and does not assume anything about the format of it. I understand that this is intended,...

The point is (and this was discussed _at length_) that the mapping is documented to act depending on whether a line matches `commentstring`. This change would break that.

And 20 lines of documentation. The current limitations were the price to get it included at all; anything beyond the bare minimum was deemed out of scope for bundling.

If it's reasonably straightforward to document understandably and -- crucially -- works for every commentstring (yes, even COBOL) then I don't mind. Having support for multi-valued commentstrings would be interesting...