Questions regarding PR's

[TRIAEIOU]

Hi,

I perfectly understand and respect the arguments against extending the Markdown syntax so I wanted to before submitting any PR's:

1. A modification of wooorm's gfmStrikethrough code generalizing it so that it can be configured for other non-complex span-style syntax (e.g. ^superscript^ and ==highlight==) (https://github.com/TRIAEIOU/mdast-hast-extension-emphasis-factory)
2. Addition of a noNonRenderedNewlines option (or similar name) to micromark (i.e. output becomes <h1>heading</h1><p>something</p><p>something else</p> rather than <h1>heading</h1>\n<p>something</p>\n<p>something else</p> (https://github.com/TRIAEIOU/micromark/tree/noNonRenderedNewlines).

Cheers

[wooorm]

Thanks for raising in a discussion :)

1. If possible, this could be useful for micromark core and GFM strikethrough.
   So perhaps we can make this one factory, that gets different markers and different token types, to parse whatever?

• So *, _ (1) is emphasis
• * and _ (2) is strong,
• ~ (1 or 2), (2 only w/ option) is delete.
• etc?
  Which is used once, but configured?

2. 😬 I’m not so sure about this. Why? Why not make a nice unified plugin, as it’s such a nice place to do these things? I imagine that it is really tough to get right? There was a similar PR recently to pulldown (Add "no-backline" feature pulldown-cmark/pulldown-cmark#603) which was closed and I’d kinda agree?

[TRIAEIOU]

No problem, if I can contribute in any way then all the better!

1. I think all the non-complex span style syntax, in the core, GFM and additional extensions should be implementable with something like this (but I may be wrong). It would have the benefits of a reduced code base and easier extension creation (there are a lot of non-GFM additions that are fairly commonly used). However one will run into this problem; so for a factory-style solution to be integrated into core micromark it might be worth modifying mdast-util-phrasing to use the mdast PhrasingContentMap or similar (which, if I understand correctly, can be extended) edit: don't know what I was thinking, that is a type, not an instance, but regardless, I think it would be great if there was one definition of phrasing content rather than several different ones.

2. For performance reasons I guessed it would be faster to implement it directly in micromark where the newlines were inserted rather than "quasi-parsing it again" or going through hast-to-html extensions, especially as it seems to take less than 10 lines of code (excluding documentation). (I have no idea what the overhead to using the Unified chain is compared to using the lower level functions). The reason for wanting to remove the newlines in my case is that the project I am using micromark/hast-from-html/hast-to-mdast/mdast-to-markdown for is html-based (so I convert from html to markdown, edit and then convert back) and at least one of the editors in that project doesn't handle unnecessary newlines very well.

Cheers

[wooorm]

additional extensions should be implementable with something like this (but I may be wrong

Yep!

---

and at least one of the editors in that project doesn't handle unnecessary newlines very well.

This seems like a giant bug in that editor, if it doesn‘t support HTML, as most HTML on the internet has line breaks? It seems extremely weird for an editor not to support that?

[TRIAEIOU]

This seems like a giant bug in that editor, if it doesn‘t support HTML, as most HTML on the internet has line breaks? It seems extremely weird for an editor not to support that?

Well, it's an edge thing, it's a secondary editor on a secondary platform that converts <br> to \n without first striping non-rendered \n when opening and then all \n to <br> when closing - resulting in preexisting non-rendered \n being converted to <br>, but you are correct, it is a bug.