Project Goal/Roadmap? Potential Collaboration or known fork about markdownfmt HOT 4 OPEN

To me, I believe all of this, generally fits the purpose of this project, so the formatting of markdown from Goldmark parsed data. 🤗

With the Goldmark "options" pattern we can give users the option to chose how things should look like if we have a different use case.

I especially love your ideas as it's something people already do:

• https://github.com/13rac1/goldmark-meta

For example, https://github.com/13rac1/goldmark-meta is something I handle outside of this project (meta is sometimes called front-matter) you can see it here in my project using markdownfmt. Would be totally nice to handle here indeed.

However, it might be not easy to edit it via editors, so you can specify text line width to be ensured. It also makes sure words are together, so it will ensure the wanted line length as you wish.

In terms of line width, I literally wanted the same thing, see this: #15
I even started implementing this (the refactoring we did recently was triggered by this 🤦🏽 ), but then I realized that IDEs already have tools for that (!). It's called line-wrapping. For example, I could set it in IntelliJ products. I am pretty sure you can configure vim, emacs as well, and others. It would be worth first to double-check this, but if still needed, we can definitely add such an option, IMO.

All of these are my own opinions. Let's see what @Kunde21 says. More contributors/maintainers = better IMO and I feel our goals align.

Great job on those extensions @13rac1 btw! I surprised you did not do mono repo for those though 🤔

from markdownfmt.

A couple thoughts:

1. Happy New Year to you both! I hope in this coming year we're able to take this tool from "experimental fork" to "extendable ecosystem."

2. Right now, we're controlling (hard-coding) the parsing options here. That limits the ability for @13rac1 to plug in those extensions. But that shouldn't require a fork or an integration at this level. I'm looking at the goldmark API and it has a lot of forethought around modifying the parser and renderer, which we could plug into directly. We'll want to move a lot of the helper functions in main.go down into markdownfmt package, then figure out a clean API for using renderer.Option and especially render.WithNodeRenderers to intercept the rendering of node types created by the extension. We might even want to move from the type switch variant to using node.Kind() to route rendering of the node. Still thinking on the best way to approach it.

from markdownfmt.

@13rac1 @bwplotka - Created a quick idea as to how we can use the existing extension/option setup to add parsing/rendering options. #32

from markdownfmt.

Is that blocking us here? I believe @karelbilek added some option handling recently?

from markdownfmt.