Open csicar opened 2 months ago
Hey hey!
The whole point of directives is that they are all supported even when unknown.
So that you can write markdown with directives, and then GitHub can show that markdown, even if it doesn’t understand what my-custom-video
means. Or other tools that don’t understand it, like markdown formatter, can still process it.
As an author, you can choose to turn this character into a plain colon: Liebe Mitarbeiter\:innen
.
Or, you can use the asterisk as the gender star, I personally see it more often: https://en.wikipedia.org/wiki/Gender_star. Asterisks are also used in markdown, so you might have to escape it too.
I do think the 1st alternative you mention is quite viable for several systems. Such as if you’d make GH comments, where authors are only expected to write known directives, and not expected to write unknown directives.
Thank you for the quick response!
I'd still argue, that the 1st alternative has the problem of the canonical representation: I.e.: how could github find out how to represent the unknown directive as :innen[]
vs :innen
The whole point of directives is that they are all supported even when unknown.
I agree, especially for the formatting use case. For other use-cases on the other hand, like rendering markdown, I'd want the parser to behave differently, which could be done by adding an option like allowDirectives: string[]
to the directives parser
If a tool supports unknown directives when rendering, like GH in this example, it would display the component. Just like how GH shows frontmatter data as a table. It doesn't understand what the keys and values mean but it can still display it. So it doesn't differentiate between with and without []. It always shows that component.
Initial checklist
Problem
When the markdown contains a
:
, but that is not part of a directive, it is still parsed as one. E.g. in german, there is a style of gendering that uses:
as part of a wordThis gets parsed as a directive
:innen[]
Solution
Allow the library user to specify what directive names should be accepted as part of the parsing and which should be skipped.
Alternatives
I see two alternatives:
:innen
or:innen[]
just from the AST\w:\w
as a directive. I think this is undesirable because it changes the parsing in a non-backward-compatible way and only fixes this specific problem