Tdesktop: Support formatting text (bold, italic...) without bots thru user interface

[kirsan31]

Now both Ios and Android version support formatting without bots and thru user interface!
Exotic android versions (like MIUI), that have own selection menu, doesn't support this with interface, but at least we can use ** and __ (and in webogram too).
Tdesktop where it most needed, and where it can (and must!) be most user friendly, doesn't have this functionality!!! Please, finally, integrate text formatting thru user interface and without bots :)

[stek29]

yay, duplicates :)

[auchri]

@stek29 of?

[stek29]

@auchri the closed #330?
It's intended, just because old one was closed.

[MasterGroosha]

@stek29 This shouldn't be considered as duplicate IMO since #330 was opened in late 2014 when no official clients had Markdown support without bots.
Now Android, iOS and Webogram support it.

[Turby3Pots]

how to strike thru that's what iwanna know

[MasterGroosha]

@Turby3Pots Not possible

[Flam1ngDem0n]

Has this been resolved/fixed? Or is the desktop version still without text formatting without the requirement of using a bot?

[kirsan31]

@Flam1ngDem0n still not implemented :(

[Flam1ngDem0n]

@kirsan31
That's a bummer. Hopefully it will be added some time soon.

[TheBestPessimist]

+1 for this fieature. i like it on android, but it doesn't work neither on ios nor telegram desktop. I think it would be nice if telegram would support this feature (telegram the ...company/application/protocol?, not just telegram desktop or telegram android, etc.)

[KAMiKAZOW]

Unicode supports strikethrough text and pasting that into Telegram works just fine. Try it out using http://adamvarga.com/strike/

Unicode features should, IMO, exposed via the desktop environment (like they support Asian characters), so that all applications can benefit equally.

[sedovalx]

Also it would be nice to extend the support for code blocks on the desktop client stretching the code blocks on the whole available screen width.

[SaphireLattice]

https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/ui/text/text_entity.cpp#L34
That seems to store a huge regular expression dealing with `code` blocks (actually called pre). If you CTRL+F then further down you can find the logic that seems to control the actual formatting in the message or something like that... And it seems that the code is very repetitive even with only code blocks
Point is, adding the rest of markdown (*italics*, **bold** and [links](google.com) at least) is going to require either tons of almost-same-code or rewriting this part.

[iansowinski]

Aren't there any markdown libs for cpp? Rewriting this part with it should be much easier.

[SaphireLattice]

How exactly that would make it easier? It will add another library and will
require a way to translate its data into TG data. The only way i see it is
rewriting parser to be more generic. Maybe look at what the web telegram is
doing?

On Tue, May 9, 2017, 20:32 Ian Sowinski [e-mail] wrote:

Aren't there any markdown libs for cpp? Rewriting this part with it should
be much easier.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/telegramdesktop/tdesktop/issues/2847#issuecomment-300164852,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEFMuFrz1wX5d849mJ1XsBAeDRoz8Gxzks5r4GsIgaJpZM4LjWQ1
.

[igorsantos07]

So the issue is fear of writing long regexp to discover whether a message has bold or _italics_ formatting, because the code fence was complicated enough? Is it "just" this? (not joking, but trying to summarize the current problem).

This is expected for ages in Telegram Desktop, the best client but that still doesn't support that, for no reason from the user's pov.

[SaphireLattice]

Regular expression is the easiest part here, so no, it's not the problem.
The problem is the parsing code that uses those expressions, it's a bit
further down in the same file. Even with just the code blocks there's a
very high amount of duplicating code. And adding anything more either means
adding /more/ of the duplicating code, or redoing the parser to be more
generic.

On Wed, May 31, 2017, 05:59 Igor Santos [e-mail] wrote:

So the issue is fear of writing long regexp to discover whether a message
has bold or italics formatting, because the code fence was
complicated enough? Is it "just" this? (not joking, but trying to summarize
the current problem).

This is expected for ages in Telegram Desktop, the best client but that
still doesn't support that, for no reason from the user's pov.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/telegramdesktop/tdesktop/issues/2847#issuecomment-305032499,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEFMuDEA1dLQ4Zfy1dkwUtNn7WK3Rjnoks5r_J9XgaJpZM4LjWQ1
.

[stek29]

@dangranos It parses links while typing to show previews, but it doesn't work so well and looks like a hack.

[SaphireLattice]

@stek29 Yeah, that seems to be a bunch of hacks made at different time, with some ducttape over this. The main parsing loop itself here seems to do the parsing by constantly pushing the start of substring to match forward and then matching ALL of the regexps.

This can be replaced by a finite-state machine. Would get rid of regexps and maybe make it a bit faster (I mean, the regexp matching isn't the cheapest operation, no?). Though that means analyzing the current code and noting down all the possible ways it should go and add markdown to this.

[SaphireLattice]

@john-preston or any other person doing the merging. Supposing in the future I, or someone else, will redo the parsing code in any (sane) way, and then make a Pull Request, will such PR be accepted? Or are there some specific rules or requirements for PRs? (Other than standard "it must compile" and "don't break everything").

Sorry for mention, as I am not really familiar with who's responsible for what in this project.

[stek29]

@dangranos I'm pretty sure it would.
Also, in case someone does this, please parse them as links (while user is typing) -- it would help a lot with #3232. So don't do it in text_entity, do it in flattextarea. Or make flattextarea store text_entity internally.

Btw, speaking of hacks. ~ symbols use different font than other symbols. That's intended and fixes #27, which is OpenSans' issue imo.

[john-preston]

@dangranos The problem with markdown will be not only the initial parsing, but also applying it back and forth when you edit such message.

[ksmirenko]

@john-preston What about the Android Telegram app? Both editing and bold/italic formatting work there very well. How is Telegram Desktop different?

I agree that supporting Markdown fully would be challenging, but the initial issue was about bold/italic formatting, which is already supported in the mobile apps.

[SaphireLattice]

@john-preston Isn't that fixable by adding the formatting symbols around the parts of text that should be bold/italics/etc, and then passing that down to whatever is responsible for displaying and editing the text?

[stek29]

@dangranos or just passing text along with it's formatting information.

[SaphireLattice]

Or just use plaintext to transmit message and parse/format it on client
side without the weird message structures that you must convert from and
to. But alas, that's not something that can be done.

On Thu, Jun 1, 2017, 20:28 Viktor Oreshkin [e-mail] wrote:

@dangranos https://github.com/dangranos or just passing text along with
it's formatting information.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/telegramdesktop/tdesktop/issues/2847#issuecomment-305492805,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEFMuKg6yni2S_qXuXF2Nd2_QHT9uvjEks5r_rxjgaJpZM4LjWQ1
.

[stek29]

@dangranos I meant passing between different classes in app, not passing to server.

[JosXa]

I'd just like to add my voice to this, +1. I am so distraughtly missing my markdown on the most appropriate device, and end up opening the web client, editing and reposting my messages every time... I'm not proficient in C++, but I would assume that finding another library for this job, even if it blows up the project, couldn't hurt and shouldnt be too hard either :disappointed:

[nyuszika7h]

@iansowinski @Rostgnom Using an external library wouldn't work, because Telegram uses its own variation of Markdown which is incompatible with standard Markdown. That uses **bold** / __bold__ and *italic* / _italic_.

[stek29]

@nyuszika7h using external library won't work indeed, but for different reasons.

[JosXa]

@nyuszika7h That doesn't strike me as much of an issue, you can always adjust the tree parser to use Telegram's markdown instead of the official implementation...

@stek29 Could you elaborate on the different reasons?

[stek29]

@Rostgnom because the issue is not about not being able to parse markdown -- writing simple regex based parser would take less than 10 minutes.
The issue is about how telegram (and tdesktop) handle parsing -- it's done through entities of different types, with offset+length.
But TDesktop's code in this part needs to be rewritten -- parsing is done multiple times, code is duplicated in field, message sending and maybe somewhere else. And parsing links while typing made it even worse.
You can easily allow formatting with bold/italic in the same way as monospace, but that would make everything even worse. The code needs to be rewritten, and it won't be easy -- no matter if you use some third party parser or not.

Btw, issue with adding ``` on each line is also related -- if I understand correctly, that's done to workaround splitting into text blocks.
Also, you should keep possibility of message editing in mind, as Preston said.
This should also integrate with link parsing, spellchecking, drafts and many other things.

So this issue report is much deeper than "monkey code more regexes", it's about complete rewrite of everything related to entities and formatting. And there are too many edge cases and stuff only Preston (or even nobody) knows.

[kirsan31]

First step:

Alpha 1.1.11.

• Send * bold * and __ italic __ text in your messages (in addition
  to already supported monospace and multiline monospace).

[JosXa]

@stek29 Thank you for providing this insight! I noticed there has been done something https://github.com/telegramdesktop/tdesktop/commit/f6eccf85dcb7e26681369659baa0eece0afb2b50

[auchri]

Fixed in latest alpha version.

[jez9999]

This doesn't seem fixed to me. I can't use any Markdown in the Telegram desktop client.

[nyuszika7h]

@jez9999 Are you sure you're using the latest version? Note that you have to double the bold/italic formatting characters like on mobile:

**bold**
__italic__
`inline code`

And three backticks for multiline code. Alternatively, you can right click in the text input field and use the "Formatting" menu, you'll find keyboard shortcuts there as well.

[TheBestPessimist]

As per the spec https://commonmark.org/help/ it should be

_italic_ and NOT __italic__

(please observe the single underscore).

This is how every markdown-powered platform i know works (check right here on github!)

[nyuszika7h]

I don't know why Telegram chose to use double characters, but there seems to be no way to escape Markdown in the official clients so that may be part of the problem. The API uses the normal Markdown syntax internally and escaping works too. Also note that Telegram doesn't support nested formatting (this includes links).

[stek29]

The API uses the normal Markdown syntax internally and escaping works too.

Nope, it doesn't. BotAPI isn't the API used by everything else (actually, BotAPI is just a "proxy" for normal mtproto API). And BotAPI markdown isn't a popular flavor, tbh.

Initially when one character markdown was introduced, a lot of people who had no idea about what markdown or escaping is started complaining that their * highlights turn into bold text. That's why double characters are used.