Bug: $convertFromMarkdownString followed by $convertToMarkdownString yields different markdown.

[orelbn]

Starting and ending spaces are preserved when converting paragraph nodes to Markdown, but spaces are trimmed when converting from Markdown.

My use case: I am trying to detect changes by checking the saved markdown value (calling convertToMarkdown on editor content) versus the current markdown value (calling convertFromMarkdown to get the editor content followed by calls to convertToMarkdown to check the markdown value of the current content)

Lexical version: 0.16.0

Steps To Reproduce

Playground:

1. Add whitespace to the end or start of paragraph node.
   
2. Press convert from markdown
   
3. Press convert from markdown again.
4. The content is different.
   

The current behavior

• Trims trailing and starting spaces when creating paragraph nodes using convertFrom but does not trim spaces when converting paragraph nodes to markdown string.

The expected behavior

• Trim spaces in both cases or do not trim in both cases.

[vadimkantorov]

Related discussion on change detection: #6312

[vadimkantorov]

I also wonder to what extent is the editor state <> markdown conversion complete: e.g. can it (at least vias some option) export centered image as a combination of some HTML div tag and style attribute and markdown's ![alt](imageurl...) inside?

[orelbn]

I also wonder to what extent is the editor state <> markdown conversion complete: e.g. can it (at least vias some option) export centered image as a combination of some HTML div tag and style attribute and markdown's ![alt](imageurl...) inside?

I'm not exactly sure what you mean by export centred image. Do you mean export state as a markdown string that can be transformed back to a centred image?

From the playground, there are some limitations to exporting and importing images from Markdown. For example, if you add a caption to an image, that is not saved if you press the convert from Markdown button. I would assume you can write custom transformers to handle that; however, it might be a bit complex.

[vadimkantorov]

Yeah, I mean transforming

an image block which is aligned to center to sth like:

<div align="center">

![custom caption](https://www.google.fr/images/branding/googlelogo/1x/googlelogo_light_color_272x92dp.png)

</div>

rendered in GFM:

Regarding the custom caption - it just exports here as alt. For a proper preservation of custom caption, maybe it's best to export like this and let the Markdown handle the transformation of the image to figure/figcaption with a caption... Of course there would be some compromises when exporting to Markdown between preserving markdown-ness to max versus preserving visual (and thus using more HTML), but for frequent and simple formatting, maybe it's worth to use a bit of HTML

Or maybe it could be exported as

<div align="center">

![custom caption](https://www.google.fr/images/branding/googlelogo/1x/googlelogo_light_color_272x92dp.png)
custom caption

</div>

with duplication of "custom caption" text. Rendered:

custom caption

but even exporting the caption as image alt would be better than nothing

[vadimkantorov]

I would assume you can write custom transformers to handle that; however, it might be a bit complex.

How should one go about doing this? This would be quite frequent: export to markdown some nodes (e.g. color-highlighted text or large font) which are not natively supported by markdown but some minimal html be required to preserve either semantics or visual. This is perfectly legitimate to want to have this sometimes (as typically markdown is then rendered by renderers supporting some html tags). Can this be handled by the current transformers model? Is there anywhere an example of doing this? E.g. is there a general tree visitor model? At least going from the editor state tree to markdown should be relatively easy to write. Then being able to parse back to editor state some limited markdown+html combination is also a useful usecase (e.g. parsing in figure+figcaption+img as a single Image node)

Would it be best for Lexical to change to some third-party mature/flexible/extensible Markdown parser/generator?