Markdown support

[MHOOO]

I wonder, would you be interested in markdown support?
I was thinking of applying a markdown renderer to text fields if the user chooses a new „markdown“ cell format. What do you think?

If you like the idea, how would you approach the implementation?

[paulfitz]

Yes, we're interested in markdown and rich text (see #67). There is a primitive version of markdown support available via a custom widget:

https://docs.getgrist.com/u5rgvdX4V2G9/Markdown-Example/m/fork

Native support would be a lot cleaner.

One question that I'd ask early is how would embedded media (images, animations) be handled, is that in scope for what you are thinking about or not? It can be an awkward corner where markdown gets ugly. Grist has an attachment column where each cell can have any number of attachments, so perhaps that kind of column could be a good "back end" for markdown that has an easy way to refer to images without messy absolute urls?

[paulfitz]

@dsagal saw this thread and mentioned he had an old experimental branch lying around that might help - I pushed it here https://github.com/gristlabs/grist-core/compare/markdown-cells (thanks Dmitry!)

[dumblob]

I see a huge risk here in future additions to this functionality. I guarantee that customers will come and will make such an enormous pressure that you'll have to implement it in one way or another. It starts with tables, then with interactive tables, additional styling, interactive media etc. Been there, done that.

All in all this rapidly converges to general complex input as discussed in #161 .

So my approach would be two fold (both at the same time):

1. Either leave cells as plain text as GitHub does (and maybe add a preview pane or widget following cell focus) or leave everything as plain text but with some very minor "automated" formatting without hiding any formatting characters - i.e. **bold** will be rendered as **bold** (note the asterisk stayed as if it was only plain text) - same for italics, and titles (probably nothing else as it would break the plain text - e.g. any indentation, font size etc. is undesirable).

2. Take the seamless widget support path (that overlaps with Native form support #37 (comment) ) and there you can go wild with much more than just CommonMark.

   Otherwise the gap between widgets and cell types would increase rapidly over time without any seamless way to bridge them. Therefore my proposal of validators (but I don't claim this is the only way to avoid the gap).

[tayflo]

For reference, I guess this issue could be closed, as in-cell Markdown is now supported (292c894).

I however note that, as mentionned in the docs, the current implementation does not currently handle media (those were mentioned right above by @paulfitz), neither custom HTLM.

On the same topic, see also #1161 and the proposal document in it, which exposes the reasoning behind limited support of the Markdown specification for now.