Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove support for legacy converters. #30

Closed
grosenberg opened this issue Aug 24, 2018 · 2 comments
Closed

Remove support for legacy converters. #30

grosenberg opened this issue Aug 24, 2018 · 2 comments
Assignees
Labels

Comments

@grosenberg
Copy link
Owner

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.

@wti
Copy link

wti commented Sep 2, 2018

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.

@grosenberg grosenberg self-assigned this Sep 2, 2018
@JanecekPetr
Copy link

Obviously, pandoc is nice because it supports CommonMark, too.

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants