Add Markdown support. #2832

anoadragon453 · 2016-01-21T10:52:31Z

Underline, Italics, Strikethrough and Bold supported. Addresses #2497

…pported.

zetok · 2016-01-21T11:05:31Z

In its current form it interferes with user input.

The proper way to do it was discussed in Tox-Archive/Tox-STS#74 - in short, new message type is needed in toxcore, and using that there can be a proper markdown support done.

anoadragon453 · 2016-01-21T11:27:55Z

Hmm, I see. So there needs to be some sort of differentiation between markdown and non-markdown text.

Which we could technically add with something similar to Wikipedia's "nowiki" tag, essentially cancelling out md detection within those brackets, but a user with a different client would see those brackets and be confused.

Interesting. Well, when we do get a separate message type, this code'll be here to parse it :)

Zer0-One · 2016-01-21T11:30:33Z

@anoadragon453 You might be interested in catching up on the discussion here: Tox/Tox-Client-Standard#25

anoadragon453 · 2016-01-21T11:44:05Z

Thank you for the link, interesting read. A standard spec is definitely required if we are to go through with it.

In my personal experience, some users turn down Tox specifically because it doesn't feature basic text formatting.

IMO Toxcore should have a separate message type, each client should have a standard, non-instrusive way to switch between the two, and clients that can't support certain features should support as much as possible, and no more.

Hopefully we figure out what definite route we're taking soon so we can get some implementation going.

agilob · 2016-01-21T13:04:28Z

src/chatlog/chatmessage.cpp

+            else if (exp.cap(7) == "_" && snippet.length() > 2) // Italics _text_
+                htmledSnippet = QString("<i>%1</i>").arg(snippet.mid(1,snippet.length()-2));
+            else if (exp.cap(10) == "__"&& snippet.length() > 4) // Italics __text__
+                htmledSnippet = QString("<i>%1</i>").arg(snippet.mid(2,snippet.length()-4));


Italics 3 times but bold once?

@agilob What other pattern for bold should be added? :P

It'll have to be adapted to the STS' spec eventually anyways. It's pretty simply to edit/add new syntaxes though.

On January 21, 2016 5:04:32 AM PST, agilob notifications@github.com wrote:

int offset = 0;

while ((offset = exp.indexIn(out, offset)) != -1)

{

QString snippet = exp.cap();

QString htmledSnippet;

// Match captured string to corresponding md format

if (exp.cap(1) == "**") // Bold **text**

htmledSnippet =
QString("%1").arg(snippet.mid(2,snippet.length()-4));

else if (exp.cap(4) == "_" && snippet.length() > 2) //
Italics *text_

htmledSnippet =
QString("%1").arg(snippet.mid(1,snippet.length()-2));

else if (exp.cap(7) == "_" && snippet.length() > 2) //
Italics text

htmledSnippet =
QString("%1").arg(snippet.mid(1,snippet.length()-2));

else if (exp.cap(10) == "**"&& snippet.length() > 4) //
Italics __text**

htmledSnippet =
QString("%1").arg(snippet.mid(2,snippet.length()-4));

Italics 3 times but bold once?

Reply to this email directly or view it on GitHub:
https://github.com/tux3/qTox/pull/2832/files#r50397534

Your code:

** - bold * - italics _ - italics __ - italics

** - should make bold otherwise is mega inconsistent.

** - should make bold otherwise is mega inconsistent

Err, __.
According to github editor, __ results in bold.

zetok · 2016-01-21T20:26:39Z

@anoadragon453 irungentoo/toxcore#1502 here you go, you can checkout branch and make needed stuff on qTox side :)

anoadragon453 · 2016-01-21T21:49:01Z

Thanks, I'll start on the framework for differentiating between different message types.

Edit: Nevermind, already implemented. Just need to add a new type.

Edit 2: Of course we use a bool to determine message type...

Edit 3: Perhaps we should put a new message type on hold and consider other options... see Tox/Tox-Client-Standard#25 (comment)

zetok · 2016-01-23T00:18:13Z

Edit 3: Perhaps we should put a new message type on hold and consider other options...

Well, you're the one implementing it in qTox, so it's up to you when you decide to work on it. :)

The way I see it (perhaps biased a bit) is that it's going to be done via MARKDOWN message type.

Also, I don't see other options..?

ProMcTagonist · 2016-01-23T00:21:50Z

@zetok Tox/Tox-Client-Standard#25 (comment)

anoadragon453 · 2016-01-23T00:27:24Z

I think implementing it in toxcore is fine, but we have to do two things to implement it:

Be aware that MD messages may potentially break clients that have not been updated to work with them yet.
Figure out a standardized way for the client to determine that the user wants to send a normal or MD message - be it either a button toggle or something within the message itself (think '/me', /md perhaps?).

Once those two things are figured out and agreed upon, I'll be more than happy to crank out the code to make it work.

ProMcTagonist · 2016-01-23T00:57:24Z

needing to manually switch to markdown mode is stupid and a pain

the point of markdown is being readable whether it's styled or not and being integrated into plaintext

anoadragon453 · 2016-01-23T00:59:54Z

@ProMcTagonist Good point, if we're not doing another message type, then there's no need to check.

tux3 · 2016-01-23T01:01:35Z

@ProMcTagonist
I 100% agree, I think it's not natural to have to switch modes when you just want to chat.
And if people really feel it's important to not remove anything from the message another option is to render the markdown while keeping the markings, like GMANE does:

http://thread.gmane.org/gmane.text.docutils.user/4104/focus=4105
http://thread.gmane.org/gmane.mail.mutt.user/43722/focus=43750

But in my opinion this is not a problem.

zetok · 2016-01-23T01:07:15Z

the point of markdown is being readable whether it's styled or not and being integrated into plaintext

That doesn't matter. What matters, is whether you can send a non-marked by markdown message.

@tux3 how do you plan on doing this, when there'll be only md-marked messages?

ProMcTagonist · 2016-01-23T01:08:07Z

People sending codeblocks through tox should use the MD code formatting because otherwise it'll get all stripped in most clients anyway so codeblocks are an argument pro-constant-markdown

@tux3 That looks like a neat solution, no characters are removed -> no problem

anoadragon453 · 2016-01-23T01:08:39Z

@zetok Tox/Tox-Client-Standard#25 (comment) ?

zetok · 2016-01-23T01:09:20Z

@anoadragon453 No.

tux3 · 2016-01-23T01:09:30Z

@zetok
I don't see the case for sending non-markdown messages, though.
If you simply don't like Markdown, we will probably offer an option to not render it.
But do you need a special messages that forces other people to not use markdown?

TheNain38 · 2016-01-23T01:11:39Z

Yes, it will be best to have an option to not render it if they don't like it. @tux3 +1

ProMcTagonist · 2016-01-23T01:12:12Z

I vote for constant markdown parsing, in the normal message type, keeping signal characters like gmane, and an option not to render styling

TheNain38 · 2016-01-23T01:13:50Z

The problem with not removing signal characters is that you have the obligation to have them visible to have the styling.
And in the case of Markdown signal characters is the "replacement" to non rendered styiling

zetok · 2016-01-23T01:14:59Z

@tux3

I don't see the case for sending non-markdown messages, though.
If you simply don't like Markdown, we will probably offer an option to not render it.

It's not about liking it or not - it's about preserving information, with which markdown interferes.

Depending on the degree of "support" for markdown, it wouldn't interfere much, or would interfere to a degree where receiving (& rendering) side would have some info from message simply stripped.

Option to not render it (some quick switch [under r-click?]) is probably the solution. :)

ProMcTagonist · 2016-01-23T01:16:30Z

@zetok

It's not about liking it or not - it's about preserving information, with which markdown interferes.

This was my concern too, until:

@tux3

And if people really feel it's important to not remove anything from the message another option is to render the markdown while keeping the markings, like GMANE does:
http://thread.gmane.org/gmane.text.docutils.user/4104/focus=4105
http://thread.gmane.org/gmane.mail.mutt.user/43722/focus=43750

So everything is preserved.

tux3 · 2016-01-23T01:16:50Z

@zetok
We will have an option to not render Markdown then.
Now if markdown is enabled, should we do it the GMANE way or strip signaling characters?
Personally I'm okay with the GMANE option, although I don't think it's really needed.

anoadragon453 · 2016-01-23T01:17:16Z

I'd like to point out that copying a MD'd message perseveres the non-parsed text.

ProMcTagonist · 2016-01-23T01:18:01Z

@anoadragon453 it should be viewable without pasting to a text editor, which gmane solves nicely

anoadragon453 · 2016-01-23T01:18:39Z

@ProMcTagonist I'm unfamiliar with Gmane, how does it do this exactly?

ProMcTagonist · 2016-01-23T01:19:29Z

@anoadragon453
http://thread.gmane.org/gmane.text.docutils.user/4104/focus=4105
http://thread.gmane.org/gmane.mail.mutt.user/43722/focus=43750

TheNain38 · 2016-01-23T01:19:35Z

I'd like to point out that copying a MD'd message perseveres the non-parsed text.

+1
Also the problem in keeping signal characters is that the non-parsed text is the "replacement" to parsed text with Markdown...

tux3 · 2016-01-30T18:11:22Z

src/chatlog/chatmessage.cpp

@@ -54,6 +56,10 @@ ChatMessage::Ptr ChatMessage::createChatMessage(const QString &sender, const QSt
    //quotes (green text)
    text = detectQuotes(detectAnchors(text), type);

+    //markdown
+    if (Settings::getInstance().getMarkdownPreference() != 0)


You should use an enum for the preference instead of a magic value

sudden6 · 2016-01-31T11:06:44Z

@anoadragon453 could you please write a few words about this new feature in the user manual?

anoadragon453 · 2016-01-31T11:13:33Z

@sudden6 Sure, just in the wiki?

sudden6 · 2016-01-31T11:17:08Z

The user facing things are documented in /doc/user_manual_en.md

anoadragon453 · 2016-02-01T19:25:42Z

@sudden6 Added, thanks.

anoadragon453 · 2016-02-01T19:52:06Z

@tux3 Addressed the issues.

tux3 · 2016-02-01T20:15:12Z

I'll take a look at it as soon as I can

anoadragon453 · 2016-02-01T22:47:14Z

@zetok Good catch, fixed.

anoadragon453 · 2016-02-08T07:46:13Z

@tux3 Anything update on this?

anoadragon453 · 2016-02-25T00:11:48Z

⌛ ...

quininer · 2016-02-25T05:03:58Z

⌛ ... +1

Deleetdk · 2016-03-11T20:59:56Z

Any update on this? I downloaded the most recent version and I don't see any markdown options. Presumably, this branch wasn't merged yet?

ProMcTagonist · 2016-03-11T21:15:01Z

@Deleetdk This PR has not yet been merged. You can see this indicator next to the title in Github's web interface that lets us know it's still open:

When it turns purple and says "Merged," you'll know a PR was merged. (Red with "Closed" means it's rejected.)

anoadragon453 · 2016-03-11T22:40:03Z

Are we still waiting for the Tox Standard to decide the md rules?

On March 11, 2016 1:15:06 PM PST, ProMcTagonist notifications@github.com wrote:

@Deleetdk This PR has not yet been merged. You can see this indicator
next to the title in Github's web interface that lets us know it's
still open:

When it turns purple and says "Merged," you'll know a PR was merged.
(Red with "Closed" means it's rejected.)

Reply to this email directly or view it on GitHub:
#2832 (comment)

tux3 · 2016-03-12T00:30:45Z

Due to the inability of the Tox Standard to actually standardize things, we will move forward with Markdown support now and deal with standard conformance when there is something to conform to :)

Deleetdk · 2016-03-12T00:37:11Z

How long does it take for the builds to be updated? Specifically, the Windows 64-bit one.

tux3 · 2016-03-12T00:46:50Z

For the nightly builds, usually around ~30 minutes but since Jenkins is really busy at the moment count an hour or two.

anoadragon453 · 2016-03-12T01:33:35Z

Thanks for merging, I'll keep an eye on how the standard progresses and update accordingly 👍

zetok · 2016-03-12T09:08:40Z

Thanks for merging, I'll keep an eye on how the standard progresses and update accordingly 👍

"standard" is IMO currently a ~joke, and thus waiting for it is most likely a waste of time.

Added markdown support. Underline, Italics, Strikethrough and Bold su…

4a1da70

…pported.

agilob reviewed Jan 21, 2016
View reviewed changes

tux3 reviewed Jan 30, 2016
View reviewed changes

Andrew Morgan added 2 commits January 30, 2016 21:43

Markdown Preference now uses enumeration type instead of integer.

db84074

Fix merge issues

0120cfb

Andrew Morgan added 2 commits February 1, 2016 11:22

Added message styling section to user manual

ee4ccf1

Merge branch 'master' of https://github.com/anoadragon453/qTox

cc310e5

Use new connection syntax

08e9f0b

Fixed link to Markdown syntax in user manual

e04bd91

ProMcTagonist mentioned this pull request Feb 9, 2016

Unable to change font #991

Closed

tux3 merged commit e04bd91 into qTox:master Mar 12, 2016

zetok mentioned this pull request Mar 12, 2016

Markdown for messaging #2497

Closed

Add Markdown support. #2832

Add Markdown support. #2832

Conversation

anoadragon453 commented Jan 21, 2016

zetok commented Jan 21, 2016

anoadragon453 commented Jan 21, 2016

Zer0-One commented Jan 21, 2016

anoadragon453 commented Jan 21, 2016

agilob Jan 21, 2016

Choose a reason for hiding this comment

anoadragon453 Jan 21, 2016

Choose a reason for hiding this comment

agilob Jan 21, 2016

Choose a reason for hiding this comment

zetok Jan 21, 2016

Choose a reason for hiding this comment

zetok commented Jan 21, 2016

anoadragon453 commented Jan 21, 2016

zetok commented Jan 23, 2016

ProMcTagonist commented Jan 23, 2016

anoadragon453 commented Jan 23, 2016

ProMcTagonist commented Jan 23, 2016

anoadragon453 commented Jan 23, 2016

tux3 commented Jan 23, 2016

zetok commented Jan 23, 2016

ProMcTagonist commented Jan 23, 2016

anoadragon453 commented Jan 23, 2016

zetok commented Jan 23, 2016

tux3 commented Jan 23, 2016

TheNain38 commented Jan 23, 2016

ProMcTagonist commented Jan 23, 2016

TheNain38 commented Jan 23, 2016

zetok commented Jan 23, 2016

ProMcTagonist commented Jan 23, 2016

tux3 commented Jan 23, 2016

anoadragon453 commented Jan 23, 2016

ProMcTagonist commented Jan 23, 2016

anoadragon453 commented Jan 23, 2016

ProMcTagonist commented Jan 23, 2016

TheNain38 commented Jan 23, 2016

tux3 Jan 30, 2016

Choose a reason for hiding this comment

sudden6 commented Jan 31, 2016

anoadragon453 commented Jan 31, 2016

sudden6 commented Jan 31, 2016

anoadragon453 commented Feb 1, 2016

anoadragon453 commented Feb 1, 2016

tux3 commented Feb 1, 2016

anoadragon453 commented Feb 1, 2016

anoadragon453 commented Feb 8, 2016

anoadragon453 commented Feb 25, 2016

quininer commented Feb 25, 2016

Deleetdk commented Mar 11, 2016

ProMcTagonist commented Mar 11, 2016

anoadragon453 commented Mar 11, 2016

tux3 commented Mar 12, 2016

Deleetdk commented Mar 12, 2016

tux3 commented Mar 12, 2016

anoadragon453 commented Mar 12, 2016

zetok commented Mar 12, 2016