Subscript and strikethrough compatibility

[chillbram]

Description

I was working on an extension to supersede the sup-sub extensions, which haven't been updated for 5+ years and don't support Commonmark v2. These render subscript and superscript when delimiting text with ~ and ^ respectively.

I got everything working, however when testing compatibility I ran into troubles when using both the sub tag (~) and the official strikethrough extension from this package (~, ~~). As this extension also supports strikethrough with just one tilde, an error is thrown due to the now ambiguous rendering rules.

When disabling support for single tilde strikethrough, the simple use cases can now be fixed. However, nested tags still cause trouble (e.g. x~sub~~strikedsub~~~ which should show x<sub>sub~~strikedsub~~</sub>, but instead show x<sub>sub</sub><sub>strikedsub</sub>~~). I had a look at how you guys implemented emphasis (*, ** and _, __) which has the same ambiguity problem and that solution of combining two rules into one seems like the only way to prevent similar issues.

Example

Just thinking out loud, here are some options to allow both sub tags and strikethrough to work together:

1. Strikethrough no longer supports the single tilde (~). This would technically break the Github Flavoured Markdown spec and also cause backwards compatibility problems.
2. We add a configuration option to allow users to set the behaviour of option 1. This would give users the freedom to knowingly break the spec to instead gain simultaneous sub and striketrough support. This is much better with regards to backwards compatibility and expected behaviour. This does not support combining strikethrough and sub tags.
3. Sub (and less relevant sup) get implemented into this package. This still requires a decision for either option 1 or 2, but allows us to also implement a similar delimiter length logic as emphasis. It does, however, implement the (albeit quite frequently used) ^ and ~ characters which are in neither the Commonmark nor the GFM spec.

Option 3 would seem ideal to me as it would allow solving the nested problem, although I would understand if supporting something outside cmark or gfm is something you're not willing to do. Option 2 would still be great as it would at least support the basic usage of both extensions.

If any of these options are agreeable, I'd be willing to draft a PR to implement it.

Did this project help you today? Did it make you happy in any way?

Thanks for all the great work on this package :)