Three backtick block parsing is way too strict compared to other messengers, making element comparatively annoying to use

[ell1e]

Description

Three backtick block parsing is too strict compared to other messengers, making element comparatively annoying to use in coding channels when sharing snippets. It just feels like element goes out of its way to make exchanging code snippets hard for the sake of wanting me to teach markdown, instead of just getting out of the way of painless conversation. Here are a few examples where the strictness is problematic:

Example 1

Input:

hello this is my code example: ```
test code line 1
test code line 2```

Telegram: ✔️

Discord: ✔️

Element: 👎

Example 2

Input:

```
test code line 1
test code line 2``` < see my code here

Telegram: ✔️

Discord: ✔️

Element: 👎

Example 3

Input:

more code:
```test code line 1
test code line 2```

(Note: I realize this one flies in the face of having the programming language specified in the first line. However, even this can be made to work without breaking legitimate markdown by just assuming anything with a space char or brackets or semicolons on the first line likely doesn't use the first line to specify a programming language. And this example happens more often for me than you'd think when not paying attention)

Telegram: ✔️

Discord: ✔️

Element: 👎

Steps to reproduce

Steps to reproduce:

• Connect to matrix using Element
• Copy the input for any of the examples above, make sure it copies as you see it (GitHub appears to like to insert empty lines in between which you will need to take out again)
• Paste example into Element chat bar and hit send

Describe how what happens differs from what you expected:

As written above, when just exchanging some snippets really quick in a discussion I don't want to be judged as if I'm writing a readme, and this works in all other messengers. As messy and non-standard as this is, I think the user intent of all examples is very clear and this is a real annoyance in conversation. So I think all of these examples should work in element.

There woud also IMHO be no need to make these work in more complex scenarios, like inside a quote or an indented block. But at least the super plain examples like in an otherwise unformatted message as above should work.

Version information

• Platform: web
• Browser: Firefox Nightly
• OS: Fedora Linux
• URL: app.element.io

Tickets #4674 and element-hq/element-meta#330 might be connected to fixing this.

[t3chguy]

This is just how https://spec.commonmark.org/dingus/ works.
The only solution would be to change Markdown dialects.

[ell1e]

@t3chguy I think a good solution might be to expand the currently used parser to handle this, might e.g. also work nicely with a pre-parser that only detects and finds and reformats these special cases. Switching the entire dialect possibly impacting lots of other things doesn't really seem like it's a good approach, unless the other changes that would bring also are beneficial of course.

[t3chguy]

That would mean running a custom dialect which is not going to happen due to maintainability and interoperability

[ell1e]

If I had to guess, I would assume custom parser tweaks that is what all these other messengers are doing. And interoperability in what sense? Right now Element seems to be doing a worse job at that in practice by not recognizing things that work in almost all others. And what exactly do I gain if a really complicated markdown readme pastes perfectly fine as-is, but the short snippet stuff I actually type in daily use doesn't work? I think adhering perfectly to some widely shared variant down to every detail might be overrated in this context

[t3chguy]

Ever more reason to switch to something like GFM rather than making our own thing which is hard to maintain exactly between all the platforms and still won't match anything else exactly

[ell1e]

GitHub doesn't seem to pass the examples above. So if GFM means it matches GitHub's behavior exactly then it won't do anything useful to solve this issue, so I'm not sure why you'd bring it up in that case. Edit: i saw the talks about switching to it and of course if that did solve it that'd be cool. but otherwise some custom work would still be necessary. The interesting question is probably with what parser that'd be the easiest to do.

Edit 2: I'm also realizing I was possibly unclear above. When I wrote the following:

I think adhering perfectly to some widely shared variant down to every detail might be overrated in this context

... I was referring to the entirety of the standard, especially things that are relevant for documentation, READMEs, and not at all for chat, you know like the nesting behavior of multiple lists inside each other, complicated indents being resolved right, stuff like that. I did not refer to the examples of this ticket, like the short weird corner cases people actually abuse and use in practice in modern messengers. Those should in my opinion definitely work - but those don't seem to match the "classic" more strict markdown standards too well. So that is why I think just trying to shoehorn in a documentation/readme-oriented markdown lib with zero adjustments may never do this justice. I might be wrong though, just a feeling.

[t3chguy]

Closing in favour of element-hq/element-meta#330 as the general markdown bug

[ell1e]

Does GFM support all these weird chat-specific corner cases though? Otherwise I'm not sure it's an "equivalent" bug

[t3chguy]

Nope, that's why I turned it into the general markdown bug, to pick the right dialect, with the current suggestion of gfm, I'd suggest arguing against gfm there if you don't like it's back tick handling.