Unable to express anger in ASCII without using a backslash escape, interpreted as quote by Markdown.

[Cloudwalk9]

Your use case

What would you like to do?

Express anger to my friends using ASCII emotes, such as >:( >:[ >:c and others

Why would you like to do it?

Because I'm mad.

How would you like to achieve it?

Requiring a space between the '>' and the quoted text. Discord does this fwiw

Have you considered any alternatives?

Flipping my anger the other way, ):< ]:<

Additional context

:(

[t3chguy]

Requiring a space between the '>' and the quoted text. Discord does this fwiw

We use an external markdown specification called CommonMark so that you don't have to learn a new dialect for each product you use

https://spec.commonmark.org/dingus/

There is another open issue about switching to a different dialect but it suggests GFM which has the same behaviour.

Running a bespoke/modified dialect would be a lot of extra work for very little gain and with a lot of added user-facing confusion.

[anoadragon453]

Personally, I've seen different friends hit this bug many a time - they're used to other chat apps which don't create a block quote when typing >x, like Telegram and Discord. Telegram doesn't support block quotes, Discord will only create one if a space is added afterwards.

But due to Discord's live markdown preview, this surprise is experienced before a message is sent.

2022-01-24.23-52-40.mp4

which saves one from finding out after having sent a message. (this is tracked at element-hq/element-meta#1569).

Regardless of WYSIWYG functionality though, the same argument can be made for strikethrough. Users expect ~~this syntax~~ to work (element-hq/element-meta#529). We're also still lacking a way to send inline spoilers (element-hq/element-meta#869).

I disagree that a custom dialogue would be little gain, as it would allow us to support the above syntax. I'm also unconvinced that it would be too much work to support. Other chat apps do it -- why can't Element?

markdown-it is a markdown parser with support for plugins for custom syntax. discord-markdown is a from-scratch library that tries to mimic discord's markdown syntax.

[t3chguy]

The issue ends up being parity matching between all the platforms, right now we already have 3 different dialects but in theory just using stock commonmark makes it easier to match between them. Having to mimic the extensions for both serialising and deserializing across all 3 platforms adds a lot of load to maintain. Also Discord has 10x the employees

[anoadragon453]

Parity in syntax between platforms is indeed something that has been a problem in the past. Though, did the difficultly in implementation lie in the conversion between text and HTML, or in implementing the rendering? If the latter, then that's a separate problem from commonmark vs. GFM etc.

If it is down to the markdown renderer, then much like the spread of matrix-rust-sdk, could we not maintain a single rust library which takes in text and spits out HTML (and vice versa) and use that across all three platforms?

[t3chguy]

HTML Rendering implementation is an entirely different topic, the Matrix spec has a set of suggested tags to support and those are all supported in Web, with partial support elsewhere.

The main difficulty was a stable MD -> HTML -> MD solution which was consistent between the platforms. Just checked, Android has finally moved to stock CommonMark too now, from their MarkedJS-in-Android hell from yesteryear

could we not maintain a single rust library which takes in text and spits out HTML

Yes, probably, but then also need to maintain our own documentation which we are awful at. We currently just point people at the stock CommonMark docs.

[anoadragon453]

Thank you for the context. The task in indeed not trivial, but I think we've reached a possible way forward if someone is willing to put in the work:

1. Create and achieve consensus upon a custom markdown syntax that will be used across all Element clients (not all Matrix clients). Keeping in mind that the syntax could be extended/modified in the future.
2. Use/create a portable library with the desired superset of commonmark syntax that can be used across all Element client platforms (currently iOS, Android, Web/Electron).
3. Do the work to implement that library in all three platforms (perhaps behind a labs flag initially).
4. Enable the library by default across all 3 clients.

This comes with the burden of maintaining a new library. But it also comes with the benefit of introducing syntactic features as the chat ecosystem continues to evolve, as well as maintaining parity across all 3 platforms going forwards.

[t3chguy]

I think maintaining good documentation and maybe a tool like Dingus too will be important.

[ShadowJonathan]

element-hq/element-meta#330 is relevant here, as commonmark enforces this exact behaviour.

I'm wholly in support for the new syntactical approach btw, if i can help with that, please let me know 👍

[t3chguy]

You can use /plain or disable MD in Preferences

[ashkitten]

You can use /plain or disable MD in Preferences

i don't really consider this a good option. i run up against this inconvenience almost daily and it's always a bit of an "ugh element" moment with me and my friends. given that no other chat app (discord, slack, zulip, ...) has this issue, i find it pretty frustrating that the official answer is that it's intended behavior...

[anoadragon453]

Indeed. Plus it means the rest of your message won't be interpreted as markdown, which is often undesirable.

I think a reasonable alternative would be requiring require a space after the > to intend a quote, e.g. > quote vs. >_>.

[t3chguy]

I think a reasonable alternative would be requiring require a space after the > to intend a quote, e.g. > quote vs. >_>.

We won't be maintaining our own markdown dialect, I suggest adding comments to element-hq/element-meta#330 that you would like to pick a markdown dialect which only treats blockquotes as > with a determinate space after the gt