You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fyi, Github announced last year that their markdown support would be based on CommonMark. (Not sure of the current status.) Their flavor is likely the md lingua franca (so it's worth supporting). And their own transition from their own parser to one based on commonmark might have produced some open-source corpus or tool that could help you as well.
Because I have very large markdown files that stall during editing (and I often have ~40 files open), I was hoping for markdown parser that supported incremental changes, to better handle the eclipse model of incremental compilation/resource changes. No such luck, AFAICT. And working in Haskell? Sigh.
That said, +1 to whatever helps you move forward with the project.
The only issue with it is that it must be installed.
On the other hand, the Java implementation of CommonMark from Atlassian is still actively developed and supported, too, and does not need any external installation. Having that engine in the plugin would be a nice fallback for users who do not want to install pandoc (yet).
Proposal is to remove support for the CommonMark, MarkdownJ, Pegdown & TxtMark converters from Fluentmark.
Pandoc is the currently preferred markdown converter. Pandoc is actively developed & supported. Not clear if the other converters are as widely used.
If there are reasons to retain any of the legacy converters, please explain in a comment.
The text was updated successfully, but these errors were encountered: