Strikethrough by double tildes

[blackst0ne]

We want to migrate from redcarpet to github/cmark.
Unfortunately, we have two major blockers. One of them is strikethrough.

In redcarpet double tildes starts strikethrough while cmark does that with just one tilde.

From redcarpet's readme:

:strikethrough: parse strikethrough, PHP-Markdown style. Two ~ characters mark the start of a strikethrough, e.g. this is ~~good~~ bad.

Is there any chance to update cmark somehow to let it use ~~ instead of ~ (maybe as an option)?

Thank you! 🙂

/cc @kivikakk

[kivikakk]

Hey! 👋 cmark does it with any number of (matched) tildes, e.g.:

~hi~ ~~hello~~ ~~~hey~~~

Produces:

hi hello ~~~hey~~~

Does this help you?

[blackst0ne]

@kivikakk

Sorry if I wasn't clear. 🙂
I meant to parse only double ~

Example:

one~two and three~four

should not produce any strikethrough, but

one~~two and three~~four

should act like it does now:

onetwo and threefour

I understand that you might not be very interested in this feature but it would really help people to migrate from redcarpet to cmark which is wa-a-ay better. 🙂

[kivikakk]

Okay, you're totally clear now 😅 I'm on holiday now for the next week, but when I'm back, I'll investigate if this would be a breaking change (how many people currently use ~…~ across GitHub? what percentage of strikethrough uses look like this?). If not, I'd be happy to make the change. ❤️

[kivikakk]

Unfortunately, it looks like about fully 50% of strikethrough uses on GitHub.com are with a single tilde on either side 😞 I'm sorry, but we'll be unable to make this change.

[foonathan]

The OPs issue seems to be similar to using underscores for italic text_not italic_text. Maybe adding the same rules for ~ would help?

[blackst0ne]

@kivikakk is there any chance to have this proposal as an option?

So on github.com by default it'd be as it is now, but if one wants to use cmark-gfm as a gem, their could use an option to use double tildes. 🙂

[kivikakk]

Ah, of course! There totally is. Would you like to submit a PR? I'd be happy to accept it. Once done we'll need to also get the plumbing for passing the option through in commonmarker, which I'd also be happy to help with.

[blackst0ne]

@kivikakk I'm not familiar with the codebase. Could you give some tips, please? 🙂

[kivikakk]

Unfortunately I'm short on time, so I can't give too much assistance (otherwise I'd do it myself); start by looking over /extensions/strikethrough.c. We use cmark_inline_parser_scan_delimiters to count the number of delimeters when matching an opening strikethrough block; try returning NULL after there if delims < 2. After that, it's just a matter of making it into an option (see /src/cmark.h for existing CMARK_OPT_* defines).

[blackst0ne]

@kivikakk thank you!

Can we keep this issue open then? 🙂

[kivikakk]

Sure thing!

[kivikakk]

I've added CMARK_OPT_STRIKETHROUGH_DOUBLE_TILDE. I'll get this into the Ruby gem shortly. 👍

[kivikakk]

This is done in gjtorikian/commonmarker@1a973ba. Let me know if you need a new commonmarker release to use this!

[blackst0ne]

@kivikakk thank you so much! 👍

[puzrin]

@kivikakk markdown-it/markdown-it#446 existing relaxed spec (allowing single tilda) will conflict with subscript extension (from pandoc, H~2~O). Since CM spec intend to unify markup dialects, it would be nice to get resulution for this collision.

I think superscript/subscript extensions are good enougth and should not be ignored even if you don't plan to enable those on github.

[kivikakk]

Our extension to allow single tilde strikethrough was made to preserve compatibility with the years of content we already had on GitHub.com; we're not going to be able to change that without breaking content; these extensions are for our own use. Anyone is welcome to extend CommonMark for their own use, like we have, but we won't be making any changes here.

[puzrin]

Anyone is welcome to extend CommonMark for their own use, like we have

That's technically correct, but CM intent is to unify dialects nightmare (including extensions). For example, when your doc declared 2 tildes - everything was ok. But after info about 1 tilde appeared in official GFM spec, other developpers (like me) are "forced" to fix compatibility (and that's impossible without breaking something else).

At first glance, i would suggest several solutions:

• Since GFM spec tends to become de-facto standard, restrict strikethrough description with 2 tildes (as it was before in your docs), and declare the rest as "legacy". That will signal people to use 2 tildes only, and avoid the rest.
• Existing syntax looks too relaxed. I'm sure it can be reduced after inspecting your old documents.

[kivikakk]

For example, when your doc declared 2 tildas - everything was ok. But after info about 1 tilda appeared

I'm a bit confused. The GFM spec, based on CommonMark, begun supporting 1 or more tilde: https://github.github.com/gfm/#strikethrough-extension-

Unfortunately I no longer have time to work on this myself (my responsibilities at work have changed), but I'll pass along this issue link to the correct team.

I understand that the intent of CM is to unify the dialects, but we've taken as much care as we have to implement the extensions we needed on top of CM without affecting core CommonMark compatibility. We have not made and do not intend to make any attempt to unify with other dialects or extensions.

[puzrin]

I can't find link to previous GFM docs (before CM-based spec), but it declared 2 tilde only for strikethrough.

When someone read new GFM spec, he does not understand, that single-tilde and any-tilde cases are for legacy docs. That's considered as "MUST be supported". And now we have conflict with another well-known extension, subscript.

In ideal world :) after CM core spec done, there are plans to unify popular extensions. And current "unofficial" collision between strikethrough/subscript will become "official". I suggest to prevent this pain, because it's should not be difficult. You could add to spec something like "2 tildes should be used, other combinations are supported for legacy docs and should be avoided in new ones"