Strikethrough text support

[pwener]

Hello! Your lib does not support the text strikethrough. The ~strikethrough~ mark is commonly used. What do you think? I could implement this.

[gettalong]

There is a strikethrough syntax for the GFM parser. As for the kramdown parser, this can only be done for the next major version because it breaks documents. I don't know yet when the next major version will be released.

As with all such requests, I will close this issue and move it to the "Feature Requests" project for tracking.

[thomcc]

Couldn't this be added compatibly by only turning it on if an option is enabled?

[gettalong]

@thomcc No, since then there would be at least two different kramdown formats and one would have to know which to use to get the correct result.

The best way, if this is needed now, is to subclass the kramdown parser and add the strikethrough support.

[thomcc]

Yeah, fair enough. Any chance that the stance on the timeline here has changed? I'm willing to provide the patch implementing this, of course.

No worries if not, kramdown is great and I don't use this that much (and this is the only lacking feature I've noticed), but the extension has become pretty common.

[gettalong]

@thomcc To be honest I'm rather reluctant to change the kramdown syntax now due to its widespread use. I'm toying with the idea of providing something similar to parser-gfm, i.e. a differently named syntax which provides those new features.

[thomcc]

Hm, that's a little unfortunate. I do get it though — a lot of people are using kramdown due to it being chosen by something else — this is certainly the case for me. In that case, a sudden update that might cause rendering errors on old pages would be pretty bad. Hm, what a tough position to be in...

Oh well, the kramdown syntax's features are really great, and more than worth the cost of having to type <del> now and then, but it being unable to be extended sounds unfortunate.

[thomcc]

As someone watching from the sidelines (so take it with a grain of salt as I'm far from familiar with most of the concerns you're worrying about, and moreover, haven't seriously written ruby in several years).

My guess is that just making a new syntax under a different name will leave you with the same problem in the future. But that a good solution would be for you to provide some way of specifying a version in the API, and having the parser enable/disable which extensions it understood based on the passed-in version.

This might be a pain to maintain though, and might be in practice not much better than just making it technically be a new syntax, and trying to reuse code under the hood.