Closed elbakerino closed 1 year ago
What does this have to do with this extension?
Press the “Update all to latest” (refresh wheel) above the dependencies. That makes it work for me.
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.
Updated dependencies
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
?
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
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.
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?
Friendly ping! :)
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.
I've created a stackblitz demo shows all variants.
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.
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.
with some reformatting of blanks
I think you’re observing something, but your conclusion is incorrect. The conclusion I believe is:
But see my reproduction above: https://github.com/micromark/micromark-extension-gfm-table/issues/8#issuecomment-1259314229. 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?
@elbakerino Does it work using micromark-extension-definition-list@v1.3.0
?
See https://github.com/wataru-chocola/micromark-extension-definition-list/issues/72#issuecomment-1362558139
Yes the upgrade fixed it and defLists are now working together with gfm!
Hi! This was closed. Team: If this was fixed, please add phase/solved
. Otherwise, please add one of the no/*
labels.
Hi team! Could you describe why this has been marked as external?
Thanks, — bb
Initial checklist
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
withremark-gfm
andremark-definition-list
, compiling withrehype
.It does not matter what is
use
d first:remarkGfm
orremarkDefinitionList
.The output of
remark
looks correct, but not the HTML when usingunified
.The example contains one
gfm
withgfm-table
plugin (1:1 copy from repo) and one without it, whengfm-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: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:
Actual behavior
When using
micromark-extension-gfm-table
it forces, without that plugin it defaults to be compiled to HTML:Whereas GitHub creates:
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)