search

fsprojects / FSharp.Formatting

F# tools for generating documentation (Markdown processor and F# code formatter)
https://fsprojects.github.io/FSharp.Formatting/
Other
465 stars 156 forks source link

Replace custom markdown parser with standard alternative #516

Closed Krzysztof-Cieslak closed 4 years ago

Krzysztof-Cieslak commented 4 years ago

I think F#.Formatting should be more focused on its core functionality - literate programming and generating documentation. Having custom markdown parser is just another bunch of code and it's not supporting some of the more advanced features added by different parsers from .NET community. Additionally, due to obviously limited manpower, it's another thing that no one has time to look at. So, my suggestion would be removing current parser and adding a dependency on Markdig or something like that.

tpetricek commented 4 years ago

I think replacing the parser itself would be pretty reasonable - but it would be nice to keep the nice feature that you get a type you can nicely pattern match on / transform.

A few of my personal projects based on F# Formatting do some sort of transformation of the MarkdownDocument value, or look for certain patterns - and this can really only (reasonably) be done using either a DU or a set of active patterns & matching constructor functions.

wallymathieu commented 4 years ago

Perhaps the markdown parser in fsharp formatting should be made into a separate component so that you can plug in other such components?

Krzysztof-Cieslak commented 4 years ago

@tpetricek if you want to keep this model (https://github.com/fsprojects/FSharp.Formatting/blob/master/src/FSharp.Markdown/Markdown.fs) completely [which is a reasonable requirement, I haven't thought about it] then probably plugging another parser probably lose a lot of value - in my view the potential value would be simplifaction of the whole bunch of code by a single call [per paragraph] to Markdig (or something like that). Markdig exposes its own AST but then we would need to create bunch of APs for matching on it- which would be just different type of complexity.

In such a case, I retract this suggestion