Regression: triple-backtick code blocks broken when closing fence isn't on its own line (since v6.7.0)

[dkumankov]

Steps to reproduce

All three forms below are sent as plain text instead of code blocks:

1. Single-line: ```text```

2. Multi-line, closing on last content line:

   ```
   line one
   line two```
   

3. Multi-line with language tag, closing on last content line:

   ```cpp
   int x = 1;
   return x;```
   

Expected behaviour

All three render as code blocks; payload contains messageEntityPre.

Actual behaviour

Plain text with literal backticks visible. No entity is attached.

Only forms where the closing ``` sits on its own line (preceded by \n) still work.

Operating system

Windows 11

Version of Telegram Desktop

Broken in v6.7.0 (2026‑04‑04), still in v6.8.1 (current). Worked correctly in v6.6.x and earlier. Bug lives in the lib_ui markdown parser — all OSes affected

Installation source

Static binary from official website

Crash ID

No response

Logs

[dkumankov]

Caused by lib_ui commit 5e3b435ec ("Force a newline before ```") applying its newline-before guard to both the opening and closing match. One-line fix restricting the guard to the opening edge: desktop-app/lib_ui#299.

[john-preston]

This was a request to support highlighting code parts that include ``` in the middle of the code, but not on their own line, sounds reasonable.

[john-preston]

And look, GitHub mostly sides with me here, see how it handles your examples (only single line three-tick case is handled on GitHub, but it converts it to inline, as if you used single ticks in there, I don't see reason supporting this given that you can use single ticks in TDesktop), but other your examples are broken here too:

[dkumankov]

This was a request to support highlighting code parts that include ``` in the middle of the code, but not on their own line, sounds reasonable.

For context — me and the developer friends I chat with have been relying on this form for years, and it's pretty much unusable now; this worked across many TDesktop versions before 6.7.0.

Fair point on GitHub, but I think the more relevant comparison is actually the rest of the Telegram ecosystem — Web and the mobile apps all handle these three forms correctly as messageEntityPre, screenshots attached. After 6.7.0 TDesktop is the only Telegram client that breaks them, so the same input behaves differently depending on which client you typed it in, which is what makes it pretty noticeable in practice.

Web version:

And this in desktop version after send it in web:

On "just use single ticks" — those produce messageEntityCode, which is a different entity (inline, no language tag), so it's not really a workaround for ```cpp\n…\ncode```, you lose the highlighting.

And I think the fix in #299 preserves the intent of 5e3b435ec — a bare ``` in the middle of code still doesn't terminate the block, because the newline-before guard is kept on the opening edge. Only the same-line-as-last-content closing case comes back, which is what TDesktop did for years before 6.7.0. Happy to narrow it further if there's a specific disambiguation you'd like to keep (HRule etc.) — just let me know.

[john-preston]

Yes, I was talking about handling test the same way GitHub does, it simply converts it to single ticks if it's in the middle of the sentence.

I don't understand why won't you just put closing ``` on a new line, it looks clean and works everywhere, Telegram or not Telegram.

I didn't quite understand "a bare ``` in the middle of code still doesn't terminate the block, because the newline-before guard is kept on the opening edge", how can opening edge check help with premature closing in the middle of the codeblock? You have codeblock:

int main() {
  return 0; // look, I can put here ```
}

And in this case before my fix the codeblock was finished on this middle line, while now it wraps everything correctly, because opening and closing ``` are on their own lines.

[dkumankov]

Yeah, I totally get the reasoning behind 5e3b435ec now - and I honestly tried to retrain myself to put the closing ``` on a new line. Doesn't work; my fingers type triple-backtick → Ctrl+V → triple-backtick on autopilot before my brain catches up. Same story with the devs I chat with - message goes out unformatted, then "f*ck" and an edit. After years of muscle memory it's just not something you can drop on purpose. And on the single-ticks angle - those produce messageEntityCode (inline code), not messageEntityPre (a code block), so they're a different entity and a different render, not really a substitute for a pre block.

What keeps nagging me is that Telegram Web still handles the old form correctly out of the composer - the outgoing entity is messageEntityPre, no edit needed. So the new closing-fence rule is effectively a TDesktop-only choice at this point, and the same input ends up producing different messages depending on where you typed it.

Can we try to find a solution together here? Do you have any ideas on how this could be handled? If not, I'll keep thinking about it on my end and come back with something.

[john-preston]

Oh, it's just... It's not how it is supposed to work and the "too permissive" initial implementation I consider to be a bug and web version I guess took that one, maybe even from me (or just used the same simplest-possible regex), GitHub and others being the source of truth here, Google agrees:

My personal opinion is that we can adapt easily, just by getting used to the correct syntax, in a week / two / month. There can be some weird decisions, like experimental options for such things, but in my opinion this is a bad path and I don't really like it very much.