mirror of
https://github.com/xoofx/markdig.git
synced 2026-02-03 21:36:36 +00:00
Converting to Markdown #24
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @giacomocariello on GitHub (Jun 21, 2016).
I'm trying to develop an alternative renderer which should produce exactly the same content as the file input. I'm wondering what's the easiest way to represent inter-block whitespace. If every block kept slicing info (start, offset), it would be easier to derive whitespace info.
Could you give me some hint on what could be the best approach?
@xoofx commented on GitHub (Jun 21, 2016):
I'm glad that you would like to add this, as I wanted to do it but didn't have enough time!
The general idea I had was to:
Markdown.Normalize()methodToMarkdownRendererToMarkdownObjectRendererfor each block/inlinesRegarding the inter-block, you cannot rely on the info (start, offset), because the syntax tree could be built by code without a parser. You basically need to have a few rendering options (per block type..etc. it will depend. Typically options like cutting paragraph to a certain width of characters...etc.) and a default behaviour for the spaces we should be CommonMark compliant depending on the block types, so that we can reparse the document and get exactly the same HTML rendering.
So a PR for this would be much welcome! You can start by the core parsers, and progressively we could extend it to all supported extensions.
Let me know if you are interested!
@giacomocariello commented on GitHub (Jun 21, 2016):
Hi Alexandre,
my plan was to add a MarkdownRenderer to allow full or partial normalization, where "partial" would mean that, depending on the renderer configuration, some rendering options may be enforced or may only be considered if no parser info is available. I suppose accessing stringslice info for all the blocks, where available, would allow me to offer this kind of flexibility.
WDYT?
At the moment I've already started writing a simple POC which subclasses TextRendererBase and reimplements core block and inline renderers, just to make some practice.
@xoofx commented on GitHub (Jun 21, 2016):
I would prefer first to focus on a plain normalize that doesn't use the original source document but only the syntax tree.
Let me know your progress, you can open a PR on a fork and I can comment as soon as you feel it starts to be reviewable (even for early direction)
@madskristensen commented on GitHub (Jun 21, 2016):
Can the normalizer take options that lets the caller specify indent size (2 spaces instead of 4 for instance)?
@giacomocariello commented on GitHub (Jun 21, 2016):
Sure.
@xoofx commented on GitHub (Jun 25, 2016):
@giacomocariello do you have a fork with already some code? as I would like to implement this feature asap for MarkdownEditor, otherwise I may start it directly in a new markdig branch, let me know!
@xoofx commented on GitHub (Oct 24, 2017):
Closing this issue as it is now tracked by #155