Message formatting

[dvor]

Markdown? support

Summary:

It would be nice for clients to support some kind of messages formatting. I think that things like italic, bold, strikethrough are used by some percentage of users and are quite important.

If we will support italic/bold why not to go for full Markdown support? code blocks and lists would be also nice to have.

Arguments for:

• Skype and some other messaging software provide simple text formatting.
• Markdown is quite popular, you can find implementation for many different platforms and languages.
• If some client won't support markdown messages will still look good enough:

Some *message* on client without **markdown** support.
- still look ~~bad~~ good and readable.

Arguments against:

• This require some effort from developers.
• Markdown may be too complicated and unfamiliar to many users.

---

@GrayHatter, @impyy, @tux3, @subliun

[KoKuToru]

gTox does have a hidden text-formatting support.
It's possible to crtl+b/crtl+i/ctrl+u text (bold/italic/underline)..
other clients get it as markdown-like text. It uses unicode noncharacters to difference between *-markdown and *-not markdown (same for ** and _)

https://github.com/KoKuToru/gTox/blob/9ca3cc4582234c4b302f226eca73484cf6d7eb55/src/widget/chat_input.cpp#L106-L171

[peterbozso]

I think it's a pretty good idea! Even through it's true that "Markdown may be too complicated and unfamiliar to many users.", it's simple: those who deem it too complicated simply won't use it. Or won't use all of it. Having full support won't hurt.
Besides, clients (optionally) also could add some basic text editing functionality (for example bold, italic, strikethrough text), making it easier for users to use these functionalities. I am for it!

[zetok]

proposed by @antis81 in qTox/qTox#1432 (comment):

Hm ... if we extend the idea to a real wiki-text parser (e.g. markdown like implemented in Github), that would actually become a useful feature. This would allow for sending also quick table and list mockups via chat-message.

Idea:
If a message starts with a command token like .md or better .parse:md followed by a space character - it could then be parsed with the selected parser. As Markdown supports HTML, it supports the — entity like — this one :).

This way we could also provide a drop-down box to select a parser and prepend it to the chat message (if not given by hand). Tokens could be (.parse:text == NO-PARSER, .parse:md, .parse:html, .parse:xyz, ...).

[subliun]

I like this idea. Perhaps full markdown support would be a bit excessive, but I would be fully willing to implement basic Skype-style formatting in Antox. I'd like to see a proposal to the STS with more details (which characters handle formatting, what they do, how to parse, etc).

[GrayHatter]

I'd be happy to add light markdown support to uTox.
On Sep 15, 2015 3:24 AM, "subliun" notifications@github.com wrote:

I like this idea. Perhaps full markdown support would be a bit excessive,
but I would be fully willing to implement basic Skype-style formatting in
Antox. I'd like to see a proposal to the STS with more details (which
characters handle formatting, what they do, how to parse, etc).

—
Reply to this email directly or view it on GitHub
#74 (comment).

[ProMcTagonist]

I like that better than disguised autoaccepted filetransfers. Fails much more gracefully.

[dvor]

If a message starts with a command token like .md or better .parse:md followed by a space character - it could then be parsed with the selected parser. As Markdown supports HTML, it supports the — entity like — this one :).

.md or .parse:md prefixes looks ugly to me. I don't think that we should add any additional information to message. Also introducing more that one format with .parse:xxx token will make things overcomplicated. I would choose single default formatting standard and stick to it. Github markdown looks like the best candidate.

I like this idea. Perhaps full markdown support would be a bit excessive, but I would be fully willing to implement basic Skype-style formatting in Antox. I'd like to see a proposal to the STS with more details (which characters handle formatting, what they do, how to parse, etc).

I'll try to create a pull request with all specifications in nearest future.

[KoKuToru]

I would prefer to be able to send plaintext + "additional info" (like formated text).
So clients who can't display formated text can happily display plaintext (as they do now) and clients that understand the "additional info" can display the formated text.

Of course toxcore would need a update ...

I really don't want to directly hack it "somehow" into the normal send message..

(Like MSNPlus used to do it in the past.. sending html and every client without the addon got the shitty html)

[dvor]

I really don't want to directly hack it "somehow" into the normal send message..
(Like MSNPlus used to do it in the past.. sending html and every client without the addon got the shitty html)

The idea is that markdown is quite readable in plain text in contrast to html. So there will be no problem for client without markdown support. Here you have some table:

for (int i = 0; i < 2; i++) {
    printf("value | %d");
}

One	Two
value	1
value	2

---

And now here is same message in plain text:

> I really don't want to directly hack it "somehow" into the normal send message..
> (Like MSNPlus used to do it in the past.. sending html and every client without the addon got the shitty html)

The idea is that markdown is **quite** readable in *plain text* in contrast to html.
So there will be no problem for client without markdown support.
Here you have some table:

'''
for (int i = 0; i < 2; i++) {
    printf("value | %d");
}
'''

One    | Two
----   | ----
value  | 1
value  | 2

---

Having ability to bold text or just paste a = peace.of(code); without any "additional info" toxcore tweaks is really cool feature.

[KoKuToru]

true markdown is pretty readable, but the client still would need to detect "i am markdown".
A additional flag/value for send message, like in send file (avatar or data), is needed.
For god's sake, please don't put these information directly in text/message body..

EDIT: or messages are default send in markdown... and sending clients escapes string for correct markdown rendering..

[alexbakker]

We could just add a new message type like TOX_MESSAGE_TYPE_MARKDOWN.

[dvor]

We could just add a new message type like TOX_MESSAGE_TYPE_MARKDOWN.

Should the user explicitly specify whether she wants to use markdown in this case (by some "markdown" switch or /md prefix)? Wouldn't it be easier always to use markdown (which will look like plain text if you won't include any special instructions)?

[zetok]

@dvor always using markdown is a bad idea.

Thing is, prefixing with /md (or whatever else) should be IMHO a preferable solution - though, as @impyy said, adding TOX_MESSAGE_TYPE_MARKDOWN sound much saner to me, than sending /md in message. /md part of the message should be kept client-side, and removed from messages that is being sent.

Though, /md seems a bit suboptimal to tell client that text should be formatted. E.g. when one uses cyrylic keyboard layout, they would have to switch to latin one just to type /md. What would be a better way (is there one?) to handle that?

Now, if you don't like by default messages in your client being plain, you can always default to sending TOX_MESSAGE_TYPE_MARKDOWN in your client - but user should have some switch that would allow sending plaintext message too.

[ProMcTagonist]

Though, /md seems a bit suboptimal to tell client that text should be formatted. E.g. when one uses cyrylic keyboard layout, they would have to switch to latin one just to type /md. What would be a better way (is there one?) to handle that?

What does Skype do for /me in other languages? Translate it?

A button will probably have to be used.

[stal888]

/md

Ridiculous. There are three use cases I can think of here, and none of them require prefixes.

• User wants to send plain text.
• User just wants to send basic bold, italic, and maybe struck-through text.
• User wants to compose a message in raw markdown.

Case 1:

1. Type hello world, enter. Client sends a plaintext message.

Case 2:

1. Type hello world, select world, cmd-b.
2. Your client sends a markdown message: hello **world**

Case 3:

1. Press cmd-opt-r (a hypothetical shortcut to put the editor into raw mode, where you type markdown syntax).
2. Type markdown document.
3. Your client sends the document as markdown.

[ProMcTagonist]

@stal888 But not every message should be parsed as markdown. Code chunks may include characters that would be incorrectly and undesirably interpreted as markdown if there were nothing to distinguish plain messages from markdown messages. I definitely agree that typing a command should be avoided at all costs but there still needs to be something that tells clients whether or not a message is intended as markdown.

[dvor]

But not every message should be parsed as markdown. Code chunks may include characters that would be incorrectly and undesirably interpreted as markdown if there were nothing to distinguish plain messages from markdown messages.

Not every message should be markdown, having separate type for it seems best idea.

So:

• new type should be added to toxcore TOX_MESSAGE_TYPE_MARKDOWN
• with this new type we can support more features, like code blocks and lists
• client should provide some way for toggle markdown mode
• github-like markdown looks like best option to me.

Are we good?

[zetok]

Are we good?

Sounds good to me.

github-like markdown looks like best option to me.

@GrayHatter said something about "lightweight" markdown for µTox - I take that it's because it would be hard to implement all of gh markdown?

Are there some libs that clients could use for that, and that STS could perhaps point to?

[KoKuToru]

I am for gh markdown without html.

[dvor]

Here is list of libraries https://github.com/markdown/markdown.github.com/wiki/Implementations

[AlexDaniel]

new type should be added to toxcore TOX_MESSAGE_TYPE_MARKDOWN

This does not look right. Markdown is not the only markup language people use, so please don't hardcode it. Just having a “type” is much better.

[GrayHatter]

wrong repo mate