Use GFM Markdown instead of CommonMark for CodeMirror editor

[leverageinventions]

Check for existing issues

• Completed

Describe the feature

I would like Acode's CodeMirror 6 Markdown editor to use the GFM-compatible Markdown language provided by @codemirror/lang-markdown, instead of the current CommonMark-based configuration.

Problem

Acode's Markdown preview supports syntax such as strikethrough (~~text~~), but the CodeMirror editor does not recognize it as Markdown syntax.

For example:

~~This text is struck through~~

is currently treated by the editor as generic content, rather than producing CodeMirror's strikethrough syntax tag.

This means a theme cannot style Markdown strikethrough using CodeMirror's tags.strikethrough, even though the same Markdown syntax is rendered correctly in Acode's Markdown preview.

I confirmed this behavior in Acode 1.13.5: changing a theme rule for t.strikethrough has no effect, while applying a rule to t.content affects the entire ~~text~~ sequence.

Proposed change

Acode already uses CodeMirror 6 and already has the required Markdown packages. No new Markdown parser should be necessary.

The relevant CodeMirror Markdown API provides two language configurations:

• commonmarkLanguage — strict CommonMark
• markdownLanguage — the extended/GFM Markdown language

The current Markdown language registration ultimately loads Markdown with:

m.markdown()

The CodeMirror API documents that markdown() uses CommonMark as its default base language.

The proposed change is therefore to load Markdown using the existing GFM language:

- m.markdown()
+ m.markdown({ base: m.markdownLanguage })

In the current CodeMirror language-data registration, the relevant code is:

LanguageDescription.of({
  name: "Markdown",
  extensions: ["md", "markdown", "mkd"],
  load() {
    return import("@codemirror/lang-markdown").then(m => m.markdown())
  }
})

Changing it to:

LanguageDescription.of({
  name: "Markdown",
  extensions: ["md", "markdown", "mkd"],
  load() {
    return import("@codemirror/lang-markdown").then(m =>
      m.markdown({ base: m.markdownLanguage })
    )
  }
})

should make the editor use CodeMirror's existing GFM-compatible Markdown language.

Acode version

This request is specifically based on the current Acode stable release:

• Acode 1.13.5
• Commit bcd3dd5
• CodeMirror 6 editor

Acode 1.13.5 already includes the relevant CodeMirror Markdown packages, so this appears to be a configuration change rather than a request to add a new dependency.

Expected result

After switching the Markdown base language to markdownLanguage, Markdown files should be parsed using the extended/GFM syntax already provided by CodeMirror.

For example:

~~Strikethrough~~

- [ ] Unchecked task
- [x] Checked task

| Column 1 | Column 2 |
|----------|----------|
| A        | B        |

should be recognized by the editor as the corresponding Markdown/GFM syntax instead of falling back to generic content where the current CommonMark parser does not recognize the syntax.

The immediate benefit is that ~~text~~ would produce the strikethrough syntax tag, allowing Acode themes to style it normally:

createRule([t.strikethrough], {
  textDecoration: "line-through",
})

Why use GFM?

This would also make the Markdown editing experience more consistent with the Markdown syntax commonly encountered in GitHub and other GFM-compatible environments.

The important point is that this does not require Acode to implement strikethrough, tables, or other GFM features individually. CodeMirror already provides the extended Markdown language; Acode would simply need to use that language instead of the default CommonMark base.

Technical references

CodeMirror @codemirror/lang-markdown provides:

commonmarkLanguage
markdownLanguage

and supports configuring the Markdown parser with:

markdown({ base: markdownLanguage })

The Markdown language registration in @codemirror/language-data currently calls:

m.markdown()

which is the part that should be changed to use the existing markdownLanguage.

No mockup is necessary because this is a parser/language configuration change rather than a UI change.

If applicable, add mockups / screenshots to help present your vision of the feature

No response