In the last 2 days we have written the markdown parser for redaktor.
For now it is supporting
- Headers (and nesting)
- Emphasis (italics, strong, combined, strikethrough)
- List and Tasklist
- Images
- Tables
- Quote, code and hr
- Links
- AP Mentions
?
What is the minimal syntax we need to support for the examples like
{
"content": "I *really* like strawberries!",
"mediaType": "text/markdown"
}
E. g. here in discourse you can upload a variety of filetypes and it handles embedding by an extended Markdown syntax. The same if you add Emoji or Dates.
They seem to arrive from the Generic directives/plugins syntax - this is a thread which contains 7 full years and is very long and hard to read.
Is there a summary somewhere?
And wouldn’t it be simpler to have ActivityPub as a Generic Directive like
:as[{"id": "idValue", "type": "Event", …}]
?
(see /widgets-preview for live example, but colors and typo are not exactly adjusted yet …)
A sensible minimum might be CommonMark. This covers the basis that is used in many different flavors. For instance here’s Github-flavored Markdown spec, that highlights where extensions were made.
In terms of extensions I would look at what some popular apps support with which you want to maintain copy/paste compatibility. Don’t know if Discourse is a good example here, though, as it comes with a lot of customizations. The image scaling thing is nice, but I haven’t found it elsewhere yet.
A compatibility with a bunch of code forges might be nice, but on the other hand Redaktor is not really targeted to a technical audience (just guessing). Furthermore code forges also vary widely in extension support. Like Gitea with their Go parser supports a lot of stuff, like Mermaid diagrams and - I believe - table format extensions.
You might look at Lemmy and SocialHome and such, and seek compatibility across existing fedi apps, if you don’t have that already (seem likely with the above implemented).
Table and Image extensions for a CMS-like app (sorry, I forgot the acronym we came up with… was it Federated Information Management?, … no) seem good nice-to-have extensions (e.g. table with colspan / rowspan).
Yes, it supports CommonMark with the Github-flavored Markdown spec. yet.
While src/MD does the parsings text/md ↔ html [or] text/md ↔ virtual DOM (dojo)
the directory src/MD/gfm
is Github-flavored Markdown (“gfm”) …
ActivityPub mentions are transformed with links in the core …
That was easy.
What’s not supported yet is any emoji/reactions stuff yet. This is because it is a very vital discussion in the team. And it affects the soul.
Because an Emoji is quite the opposite of what redaktor wants to achieve.
We want to encourage to express feelings in depth and through stories.
An Emoji wants to generalise feelings for the click of a button.
Maybe an icon is very fine to express meaning but not generalise feeling.
We just want to think about the general way for “reactions” in redaktor first …
However, re. compatibility, yes: It is fully compatible to diaspora/pluspora, the markdown addon for friendica and socialhome (will look at Lemmy now …)
not really targeted to a technical audience
Of course it has a visual editor with a button menu as primary editing feature.
Table and Image extensions for a CMS-like
I mean, it has it anyway.
You can create a page where you use any of the 138 widgets and all ActivityPub types …
But content in text/markdown federates and so if “plain services” like mastodon does not support it, then 2 * maybe are not disturbing but e.g. a Table can be hard to read, alone due to line length …
So, the question is really just about parsing it from plain text as in
Section 3.3 of the spec.
I agree. It is an important subject. What I noticed is that not all apps support the same names for emoji, which is confusing. Think it is important to go with most consistent set there (I don’t know what’s the convention, maybe the Unicode CLDR Short Name)
I saw a really appealing table format the other day, but darned if I know where that was… information overload 
Proposed some format in the past myself, but this was better.
