Require double-tilde for strikethrough #33
Conversation
|
I'm a bit uncertain if we should change the default or introduce an option for this. It is a breaking change and many people are used to the single-tilde strikethrough but on the other hand having too many option is annoying too. I wish we had enabled this from the beginning. |
|
Let's try it and see if it breaks anything. |
The current dev version of commonmark has disabled single tilde for strikethrough: r-lib/commonmark#33 Using double-tilde will make it consistent with Pandoc's Markdown (where single-tilde is for subscripts).
|
I ran revdep checks and found that it would break a shiny test (all other revdeps are fine). I've submitted a PR to shiny: rstudio/shiny#4144 Let's see if they will merge it. This is indeed a breaking change, and we can provide an option instead, but I don't like too many options, either. |
* Use double-tilde for strikethrough in Markdown tests The current dev version of commonmark has disabled single tilde for strikethrough: r-lib/commonmark#33 Using double-tilde will make it consistent with Pandoc's Markdown (where single-tilde is for subscripts). * Skip tests if commonmark is outdated * Revert "Skip tests if commonmark is outdated" This reverts commit 97bee20. --------- Co-authored-by: Carson Sievert <[email protected]>
|
The shiny PR has been merged. commonmark needs to wait for the next CRAN release of shiny before its new CRAN release (unless we add an option like |
|
This now means that the single tilde does not survive the round trip (as discussed in an earlier attempt to enforce the double tilde: #31 (comment)). Is there something we can do to prevent this? |
|
Oh I didn't realize that you had already tried to do what I did. Good question, and I don't know the answer. In the long run, personally I feel it may be a better idea to detach this R package from GFM, because Github clearly doesn't have interest in catering to the needs of anyone outside Github. From github/cmark-gfm#71 (comment)
I totally understand why they wanted to keep single-tilde, but this legacy really makes no sense outside Github. By "detaching", I don't mean that we completely ignore GFM's future changes (I guess they would be relatively minor anyway), but applying patches the other way around. That is, instead of applying our patches to GFM's codebase, we apply GFM's patches to our codebase. Of course, this may require more maintenance effort... If we dare to deviate from GFM, the round trip problem may be solved by introducing the subscript syntax formally in our own spec, although I have no idea how hard the C implementation would be. |
That's a good question. I would be willing to spend a little time digging into it. I would imagine it wouldn't be too dissimilar to the patch for the footnotes, considering there already is a mechanism to explicitly enforce the double tilde/single tilde. |
|
I played around with it this afternoon and was able to get something working by duplicating the I'm not sure how to format it as a patch, tho. |
|
Awesome! Perhaps send a PR and we can discuss the possibility of turning that into a maintainable patch from there? |
In Pandoc's Markdown, single tilde is for subscripts, e.g.,
H~2~O. GFM allows for both~and~~for strikethroughs, which I think is a really bad idea (cf jgm's first pain: https://johnmacfarlane.net/beyond-markdown.html).