"Markdown" support in chat

The basics like bold, italics, underlined and strikethrough should be enough.

1 Like

Update: We implemented a bit markdown in desktop.
Also I made a pull request for adding the ‘specs’ for our markdown support to the interface repo https://github.com/deltachat/interface/pull/20


Please implement in the Android version


We plan to ultimately do message formatting in the core.
For now the markdown support was removed from desktop again because there were a few bugs with it.


Markdown has no specification and there are lots of flavours and different libraries that parse complicated cases differently because even the CommonMark “standard” does not specify every case.

If we want to support rich text, the most compatible way is to compose the message using WYSIWYG or markdown on the client and send HTML mail after that. Unlike markdown, HTML mail is readable in existing email clients. So a way to add this feature is to add HTML mail parsing to the core first, so it does not remove basic formatting, but transforms it into some machine readable format that can be displayed in the UI without doing the parsing there.

Markdown is even readable in text form, so we don’t absolutely need HTML in my opinion, though it certainly could be a nice addition to also send html, to make people using traditional mail clients happy.
(probably while making cubans mad :smile: )


Markdown is even readable in text form

It is human-readable, but not machine-readable, because it is ambiguous. Sending markdown along with text/html is ok, but if you receive text/plain, it should not be parsed as markdown on receiver side.

foo ***bar **baz * foo is not parsed by this forum (it displays foo ***bar **baz * foo), same for CommonMark, but pandoc converts it to <p>foo <em><strong>bar </strong>baz </em> foo</p> (when not in CommonMark mode). And there are lots of cases where you want to just type literal * and escaping rules for * differ among implementations too. You can’t just escape everything, because it will be unreadable in plaintext, and the longer the text, the higher the chance that some unescaped * will be treated as a closing symbol. Add unicode character classification to the mix, with differences in how punctuation characters and so on are dectected depending on the version of unicode supported. pandoc has round-trip test for markdown disabled for this reason, and it is very difficult to make it work: pandoc/test/Tests/Readers/Markdown.hs at 57e29610ac3332807ac1ee897bc02b65236a7be3 · jgm/pandoc · GitHub

Also try typing some math in skype and see how annoying this markdown (or whatever markup they use) parsing is.


Even without a standard specification, I would personally be ok with just some basic Markdown support, which is much better than nothing.
I mostly only use bold, italic, bold+italic, bullet list, numbered list, and quote. For longer (chat) posts, also H3-H5.

1 Like

I like the way Pix-Art Messenger does it, it display the text in bold, italic, etc. but also shows the marks used, for example:
this is **bold** and _italic_


BTW even WhatsApp has some basic kinda-markdown support: ```text``` becomes monospace, ~text~ means strikethrough, text is italics and text is bold. They also show the marks (but only in grey) and format it while typing, like @adbenitez described, but when it is received the marks are hidden.

Not saying we should go this way (e.g. it sounds like lots of ui work on each platform, more that just showing some HTML from the core), I just wanted to mention it.

1 Like

My person thinks that giving possibility for links []() and marking quotes > are somehow also standards in use of text editors, not “harmful” and broad known if displayed as plane text.

Much success with all good undertakings, not founded in either dislike nor craving, good master Simon. (Maybe dokuwikis syntax is an inspiration, as given to use it, working with plane text for store)

1 Like

There is some progress on this, desktop currently uses the new message parser, which already has the bases for markdown support. the new file of what we plan to support is in the repo of the new message-parser which is written in rust.



Not sure if overseen, maybe quote “>” is of interest as well, and imbedding attachment pic, if such is useful.

Seems very complicated to implement for the time being. Maybe something for the far future.

Understandable, good Master Simon, thought on pics. Yet in regard of quote “>”, isn’t it not merely email standard and already used by DC in some ways.