It is impossible to escape markdown formatting characters

[bazzilic]

Steps to reproduce

1. Try sending, e.g., this text: __*__
2. It is impossible to do :) because of markdown formatting

Expected behaviour

There should be a way to escape formatting characters (e.g., using a backslash: \_).

Actual behaviour

Sending "__*__" will result in a message containing just one "*" written in italics. Same with other markdown characters: "*", "_", "`", "~".

Other Comments

This was reported in https://github.com/telegramdesktop/tdesktop/issues/2683 and https://github.com/telegramdesktop/tdesktop/issues/3713 but those issues got closed without any resolution.

Operating system

macOS 12.3

Version of Telegram Desktop

Telegram Desktop 3.6.1

Installation source

Other (unofficial) source

Logs

No response

[ilya-fedin]

2. It is impossible to do :) because of markdown formatting

Have you actually checked that?

[bazzilic]

@ilya-fedin you are right, my bad. I updated the original message.

[ilya-fedin]

@bazzilic new variant looks weird

[bazzilic]

Yeah I had to escape the md characters in the message, fixed now. At least I can escape them here on github! I can't do that in telegram.

[ilya-fedin]

What's the problem to send such characters in the code tag?

[bazzilic]

True, I can send them in a code tag or as an image or using WhatsApp. It's just that I'd like to send them as plain text in telegram. It's kinda weird that there are certain combinations of regular symbols that are impossible to send via a messaging app. And as far as I understand, it's not completely impossible, e.g., a bot can escape md characters and send these combinations (see this). It's just the telegram desktop client that can't do that.

[ilya-fedin]

There's no markdown in mtproto (it's entirely client-side in tdesktop and other clients for humans), but if you want such a possibility, there should be a valid use-case apparently, 'I'd like to send them as plain text' doesn't sound like a good motivation.

[bazzilic]

Telegram is a messaging app. I want to send a message, which I can't. What other valid use case do you need? If you don't like my abstract example with "__*__", I can give you some other things you can't talk about using Telegram Desktop:

• Python's "magic methods" such as __init__, __str__ and others
• Some kaomoji's

[ilya-fedin]

What other valid use case do you need?

The point is the code tag gives you possibility to send the message unchanged (no tag parses, no space stripping)

• Python's "magic methods" such as init, str and others

The code tag is invented exactly for such use-case

• Some kaomoji's

Why code tag doesn't fit this use-case? You can choose monospace from the context menu or use Ctrl+Shift+M hotkey to get them in-line and without breaking apostrophes used for the in-line code tag.

[bazzilic]

A better question is - why not allow users to escape it like any other markdown-capable input would allow you to?

[ilya-fedin]

why not allow users to escape it like any other markdown-capable input would allow you to?

"Why not" is not a good motivation for a change.

[bazzilic]

I gave you my motivations. Using code tag for everything that I want to send and can't because of a weird markdown implementation in TD sound like a hacky workaround and not the intended way. Allowing escaping of special characters is standard practice everywhere where there are special characters.

[ilya-fedin]

Code tag is the intended way to send text unmodified in a lot of markup languages. Also, markdown is not (de-facto) standardized and has a lot of dialects.

[bazzilic]

I think it is standardized de facto but not de jure :) I am not referring to markdown standardization though, telegram's version of markdown is different from other flavors such as GitHub or StackOverflow. But all other flavors that I know of allow users to escape special characters.

[ilya-fedin]

Well, if we have a lot of dialects, then it IMHO not standardized de-facto. When I say 'in a lot of markup languages', I refer not only to markdown though. Without demonstration what problem this behavior creates this couldn't be a bug, a feature request at best (personally I think this should be closed with wontfix though as code tag perfectly fits the needs you described).