Cross-project coordination

[PeterWone]

I maintain the Print project which prints rendered Markdown with support for a variety of extensions eg Mermaid and Katex.

I gave up on the Microsoft internal rendering pipeline because they keep making breaking changes. Consequently I am supporting extensions directly. I think we should coordinate so that your editor and Print use the same conventions for extension, for a good end to end experience.

One small example is for tables. I have two extensions in mind, one of which is best implemented in an editor like yours.

1. We can extend the right-alignment notation |---:| to also permit the characters [0-9$] where a digit means right-align and round to that many decimal places, and $ means right-align, 2 dec places with a currency symbol.
2. If the usee employs Excel syntax I can use the hyperformula library to evaluate formulae for print/preview.

[adamerose]

Does that syntax exist in any existing standards or renderers? It doesn't seem to work in any renderers I try. I think extending markdown notation needs to start with a popular product or standard like GFM, rather than in end user extensions like this one where the result would just be a fragmented ecosystem and people writing a custom markdown dialect that doesn't render properly in other renderers.

Also my extension is just embedding CKEditor5 in a VSCode webview, I don't implement the parsing and rendering, so this would need to happen upstream.

[PeterWone]

Does that syntax exist in any existing standards or renderers?

No.

I think extending markdown notation needs to start with a popular product or standard like GFM

Popular with whom? The context is VS Code users. Print is the only maintained printing tool for VS Code. I get 3000 installs every week.

rather than in end user extensions like this one where the result would just be a fragmented ecosystem and people writing a custom markdown dialect that doesn't render properly in other renderers.

This is why I wanted cooperative development. Make it a save option.

Also my extension is just embedding CKEditor5 in a VSCode webview, I don't implement the parsing and rendering, so this would need to happen upstream.

Yes, I saw that. I've been looking at their API and samples, pondering how to customise serialisation.

Incidentally, your editor clashes with diff, which really needs a line-based editor to work properly. To repro, edit a md file and click on it in the git pane to launch diff view. Both sides show the WYSIWYG editor, which doesn't suit diff. I'm not sure how to fix that because really it's on the caller rather than the called editor. If you have a setting for whether to default to text or WYSIWYG that would solve it (haven't looked yet).

[adamerose]

your editor clashes with diff,

I just published 0.7.9 which makes this editor no longer the default, so it shouldn't break diff view anymore (unless you manually set it as your default editor again).

Popular with whom? The context is VS Code users. .

Markdown users. I like being able to copy paste markdown source between various tools and having it work consistently, like between different text editors, GitHub issues, StackOverflow, etc.

Make it a save option.

Then once you enable the optional custom notation, you're no longer writing standard markdown. If I added a table with your currency syntax to my README.md it would no longer properly render on my GitHub project page, right? I don't like the idea of .md files in my project only being viewable by a certain IDE / extension.

I ran into this with Obsidian where as you start installing more and more plugins your notes are no longer really markdown and not portable. Here are 4 plugins that implement extended table features similar to what you described, but they're all incompatible and all made up their own syntax. https://github.com/pistacchio/obsidian-enhanced-tables https://github.com/tgrosinger/advanced-tables-obsidian https://github.com/NicoNekoru/obsidan-advanced-table-xt https://github.com/aidenlx/table-extended

In general, I think the more features you want in a WYSIWYG editor the more it makes sense to base it on HTML or JSON data rather than Markdown, which is actually what CKEditor5 does by default. The big benefit of markdown over HTML is the simplicity and portability, which you lose once you start adding much custom syntax.

[PeterWone]

Some observations.

• Standard Markdown doesn't define tables at all.
• John Gruber doesn't agree with you: "Different sites (and people) have different needs. No one syntax would make all happy."
• While I don't totally disagree about the value of standardisation, insisting on it stifles innovation.
• If one really wants something like this, most of the major dialects are open source and there's nothing stopping us from contributing to them.

It would have been smart for the Obsidian people to do that. I probably will, after I'm satisfied with my implementation.

Different things matter to different people. For me, the value of Markdown is that it is amenable to line-based version control and in particular diff tools. I'm trying to bring to bear on documentation the kind of collaboration tools I've always had for code.

Don't worry I'm not trying to sell you on the idea. If it's not something you want to do ... it's a free world, or at least the OSS part is. Besides, I think you may be right about using another format for tables. Once they become non-trivial Markdown notation doesn't work well. I should probably use a fenced block and some Json and give up on editing it as text. The question I must now ponder is how to reconcile that with line-based diff.

[adamerose]

I support the idea, and if anyone develops a CKE5 plugin to support this extended syntax I would be open to adding it to this extension - I just know that as a user I would be hesitant to starting using that syntax until it is supported by most markdown tools, and I think that would require it be added to a standard like GFM with some project or company to proliferate it.

It would have been smart for the Obsidian people to do that. I probably will, after I'm satisfied with my implementation.

Yeah, I think creating a spec detailing a list of potential extended markdown features and recommended syntax for them would be valuable. It's a good point that standard markdown didn't even have tables and GFM extended it. Now it seems like your mission is basically another level of GFM with more features.

It would also be good to compile a list of existing attempts to extend markdown. Obsidian plugins was the main one to come to my mind but I'm sure there are others. There's also some discussion here about WYSIWYG editors and markdown: https://www.github.com/orgs/TriliumNext/discussions/24

[PeterWone]

You know, back on your point of expressing tabular data as JSON, if the serialisation was indented, trivial with JSON stringify, it would lend itself very well to diffing. It would also be very long. You could also have a header section separate from the data, with as much metadata as you need, then put the data in an array of arrays.

I'm starting to think that things that mangle the reading flow of the document ought to be in referenced files. This has engineering benefits too. If they're served by an embedded webserver (which is how Print works) I can get the special handling out of the markdown processor and have separate renderers for difference kinds of resource. For a lot of things, you'd just use an IMG element (because you can't put a css class on the markdown syntax). For things that don't yield SVG or a bitmap, a fenced block could provide a unified way to reference an external resource.

```external
workspace.resource/path/to/my-table.some-custom-file-ext

The file ext is the cue for mime-type and processing.

For the case of our hypothetical Json table definition, the extension MJT (markdown json table) would make the embedded webserver produce an HTML table with all the alignment and such and return it as text/html. Since this is all requested by the browser I guess I have to replace the fenced block with a placeholder div and have some script make the requests and replace the placeholders.