Improper parsing of strike-through

I think markdown parser in code mirror incorrectly parses strike through.

Given these values:

~~word~~
~~ word~~
~~word ~~
~~ word ~~

Only the first one (without any surrounding spaces) should be striked-through, according to markdown. But in codemirror, they all are.

Markdown has no strike-through, and the GFM spec is entirely silent on this. Which definition are you working from?

I used this as an extension

import {defineLanguageFacet, Language} from '@codemirror/language';
import {commonmarkLanguage, markdown} from '@codemirror/lang-markdown';
import {Strikethrough, Table} from '@lezer/markdown';

function language(parser) {
  const facet = defineLanguageFacet({block: {open: "<!--", close: "-->"}});
  const documentType = parser.nodeSet.types.find(type => type.name === "Document");
  return new Language(facet, parser, documentType);
}

const elements = [Table,  Strikethrough];

const flavouredParser = commonmarkLanguage.parser.configure(elements);

export default [
  markdown({
    base: language(flavouredParser),
    codeLanguages: [],
  }),
];

And it appears it treats ~~ word~~ as strike throught I think.

No I mean do you know where the behavior you’re looking for is specified?

I’m sorry, unfortunately I don’t know :confused:

I just noticed that’s how JetBrains IDE render ~~, and also CommonMark library in PHP, and also Github.

So I would start looking under “CommonMark specification” or “Extended markdown specification”

I would expect that ~~ should work very similarly to **, which means **text** is treated as bold, but **text **/** text** aren’t.

CommonMark does not define strikethrough, and GFM, the ‘spec’ that Github created for their extensions (and which I linked before) doesn’t say anything about in which situations these markers should be ignored.

This patch adds logic similar to what emphasis marks use.

Cool, thank you very much!

Is it released, so that I can start using it immediately?

I’ve tagged @lezer/markdown 1.0.2 with this fix.