Using micromark-extension-definition-list does not work if micromark-extension-gfm-table is used

[elbakerino]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

(latest) remark v14.0.2, remark-gfm v3.0.1, remark-definition-list v1.2.0, remark-rehype v10.1.0

Link to runnable example

https://stackblitz.com/edit/typescript-yj7hye?file=index.ts,index.html

Steps to reproduce

Using unified with remark-gfm and remark-definition-list, compiling with rehype.

It does not matter what is used first: remarkGfm or remarkDefinitionList.

The output of remark looks correct, but not the HTML when using unified.

The example contains one gfm with gfm-table plugin (1:1 copy from repo) and one without it, when gfm-table is not used, it works correct.

---

as not possible to select:

Package manager: NPM v8

Build and bundle tools: none, plain ESM

Expected behavior

No impact of micromark-extension-gfm-table when using the definition list syntax:

First Term
: This is the definition of the first term.

Second Term
: This is one definition of the second term.
: This is another definition of the second term.

Like GitHub, e.g. just not handling it:

First Term
: This is the definition of the first term.

Second Term
: This is one definition of the second term.
: This is another definition of the second term.

---

This HTML is expected:

<dl>
<dt>First Term</dt>
<dd>This is the definition of the first term.
</dd>
<dt>Second Term</dt>
<dd>This is one definition of the second term.
</dd>
<dd>This is another definition of the second term.
</dd>
</dl>

Actual behavior

When using micromark-extension-gfm-table it forces, without that plugin it defaults to be compiled to HTML:

<p>First Term
: This is the definition of the first term.</p>
<p>Second Term
: This is one definition of the second term.
: This is another definition of the second term.</p>

Whereas GitHub creates:

<p>First Term<br>
: This is the definition of the first term.</p>
<p>Second Term<br>
: This is one definition of the second term.<br>
: This is another definition of the second term.</p>

Runtime

Node v14

Package manager

Other (please specify in steps to reproduce)

OS

Windows, Linux

Build and bundle tools

Other (please specify in steps to reproduce)

[wooorm]

What does this have to do with this extension?

[wooorm]

Press the “Update all to latest” (refresh wheel) above the dependencies.
That makes it work for me.

[elbakerino]

When not using this extension it works as expected, after quite a bit of debugging none other changes than disabling this plugin worked.

Thus the three examples in the stackblitz.

[elbakerino]

Updated dependencies

[wooorm]

OK I found your request rather confusing, but you’re right that there is a problem. Here’s a reduced case:

import { micromark } from "micromark";
import { gfmTable, gfmTableHtml } from "micromark-extension-gfm-table";
import { defList, defListHtml } from "micromark-extension-definition-list";

const markdown = `a
: b

| c |
| - |
`;

const output = micromark(markdown, {
  extensions: [defList, gfmTable],
  htmlExtensions: [defListHtml, gfmTableHtml],
});

console.log(output);

Passing gfmTable (or not) changes the definition list.
Or, the other way around: using defList, does not work if gfmTable is passed.

Have you though about treating this issue the other way around: what if this is something in defList?

[elbakerino]

First wanted to open it in gfm - but then dug deeper and found the relation to this extension here. Can only describe it as easy as it is to understand what is happening where. I'm a new developer of micromark plugins thus the internals are (still?!) a bit complex to grasp after a few hours migrating from markdown-it.

Yes - there maybe something missing in defList.

See the "expected behaviour", GitHub is handling table-detection (or parsing or whatever) otherwise than the plugin - (or may have something completely else for that).

Thus I'm assuming, when making this gfm-table plugin to behave like GitHub tables, it would fix it also, when this doesn't fix it of course than the other extension need to be adjusted as well.

Otherwise - i'm still searching for the part in the gfm spec. - shouldn't the general gfm plugin include something to behave like GitHub?

i've changed the "expected behaviour" to:

• include the GitHub HTML
• clearify that the gfm-table plugin forces the (faulty) HTML
• clearify that without the gfm-table plugin it defaults to the (faulty) HTML

[elbakerino]

Didn't found anything in GFM spec related to ": as line feed" - the different <br/> comes more from the general "soft break to <br/>" handling of GitHub.

Thus my current guess is that when the gfm-table plugin doesn't "force" a paragraph, the defList plugin will just work fine.

If there isn't something like "forcing nodes" at all available/implemented, I'll of course move this issue to the defList plugin.

[wooorm]

GFM spec

GFM does not support definition lists

forcing nodes

This extension does not “force” paragraphs.

---

gfm-table plugin to behave like GitHub tables

This extension behaves like GitHub. If not, that’s a bug. Can you prove a case, without definition lists, where that isn’t the case?

[wooorm]

Friendly ping! :)

[elbakerino]

Sorry needed a while to get back to it.

Thanks for your confirmations, so I didn't need to check in that direction.

After further debugging I've found that the issue seems to be with some reformatting of blanks, when the gfmTable module is used.

When using gfmTable + defList the spaces are changed.

For example pandoc/markdown extra php requires three spaces after the colon and before the content.

The defList plugin changes 1 space to 3 spaces, but with gfm this is changed back again.

I don't know if the gfmTable plugin shouldn't do something it does with spaces, or that defList shouldn't rely/change those like currently done.

But even when using 3 spaces in MarkDown source, together with the gfmTable plugin the lists don't work: stackblitz demo.

Example

I've created a stackblitz demo shows all variants.

Initial Spaces: 1

md_1 uses gfm + defList, the blanks stay at 1

# Definition List

First Term
: This is the definition of the first term.

Second Term
: This is one definition of the second term.
: This is another definition of the second term.

md_2 uses defList, the blanks go to 3

# Definition List

First Term
:   This is the definition of the first term.

Second Term
:   This is one definition of the second term.
:   This is another definition of the second term.

md_3 uses gfm, the blanks stay at 1

# Definition List

First Term
: This is the definition of the first term.

Second Term
: This is one definition of the second term.
: This is another definition of the second term.

Initial Spaces: 3

md_4 uses gfm + defList, the blanks are already at 3, they stay at 3

# Definition List

First Term
:   This is the definition of the first term.

Second Term
:   This is one definition of the second term.
:   This is another definition of the second term.

md_5 uses gfm, the blanks are already at 3, they stay at 3

# Definition List

First Term
:   This is the definition of the first term.

Second Term
:   This is one definition of the second term.
:   This is another definition of the second term.

md_6 uses defList, the blanks are already at 3, they stay at 3

# Definition List

First Term
:   This is the definition of the first term.

Second Term
:   This is one definition of the second term.
:   This is another definition of the second term.

[wooorm]

with some reformatting of blanks

I think you’re observing something, but your conclusion is incorrect.
The conclusion I believe is:

• If everything works, definition lists are indented as 3 spaces (md_2, md_4, md_6)
• If it doesn’t work, indentation stays as-is (md_1, md_3, md_5)

But see my reproduction above: #8 (comment). This isn’t about reformatting. It’s about parsing correctly or not. GFM + deflist doesn’t work. In HTML that means that no <dl>s are generated. In markdown it means that indentation isn’t generated.

Reiterating my earlier question:

Have you though about treating this issue the other way around: what if this is something in defList?

Have you tried asking there?

[binyamin]

@elbakerino Does it work using micromark-extension-definition-list@v1.3.0?
See wataru-chocola/micromark-extension-definition-list#72 (comment)

[elbakerino]

Yes the upgrade fixed it and defLists are now working together with gfm!