Bug 302534

Ha, I like specific and well defined test cases like this. It means I can chuck that straight into a unit test, and muck about with stuff until it passes :). 

Will fix soon

Actually, that breaks the case of "_*this should be in italics and bold*_".

*** Bug 302643 has been marked as a duplicate of this bug. ***

Can we maybe disable this plugin for now? It's causing quite a few issues (i.e it's annoying me :) )

Git commit 06d9441d7638c2730a69ec3e2a0470a996585932 by David Edmundson.
Committed on 02/07/2012 at 08:59.
Pushed by davidedmundson into branch 'master'.

Temporarily disable format-filter plugin as it is causing issues. See attached bug.
Reviewed-by: Martin Klapetek

M  +3    -3    filters/formatting/format-filter.cpp

http://commits.kde.org/telepathy-text-ui/06d9441d7638c2730a69ec3e2a0470a996585932

(^|\s)-.*-(\s|$)


Tested this regular expression (just for finding things). Seems to work.

Yeah, that was basically the regex I tried earlier. But that broke the case where "_*this should be in italics and bold*_" (As I posted above).

[13:13] <shocklateboy92> how should we deal with the formatting issue
[13:14] <alin> shocklateboy92: personally I will enforce a space -
[13:14] <alin> shocklateboy92: and I will prevent the filter to be applied to everything that was detected already
[13:14] <shocklateboy92> and we'll screw the bold and italics case for now?
[13:14] <alin> shocklateboy92: what do you mean screw?
[13:15] <alin> shocklateboy92: bold and italic work..
[13:15] <shocklateboy92> _*this should be in italics and bold*_
[13:15] <shocklateboy92> if we enforce a space
[13:15] <shocklateboy92> it will not be in bold 
[13:15] <alin> i do not know any legitimate use of * or _ in normal words
[13:15] <shocklateboy92> becuase there's no space next to *
[13:15] <alin> but the issue with enforcing spaces is only for -
[13:16] <alin> if you exclude the links
[13:16] <alin> _ creates no problems
[13:16] <shocklateboy92> hmm
[13:16] <alin> bold and strike out would give you troubles
[13:18] <alin> but that you can thing as special combinations
[13:18] <alin> and treat them in advance
[13:18] <alin> and if they match there is no need
[13:19] <shocklateboy92> ah
[13:19] <shocklateboy92> now there's a thought
[13:19] <alin> -*_ strike, bold, italic
[13:19] <alin> -* strike and bold
[13:19] <alin> -_ strike and italic..
[13:19] <alin> *_ bold and italic
[13:19] <alin> * bold
[13:20] <alin> - strike
[13:20] <alin> _ italic
[13:20] <alin> if you do it with a case... should avoid any traps... and enforce space only for strike -
[13:21] <shocklateboy92> hmm
[13:21] <alin> of course links are excluded apriori to avoid messing with them
[13:21] <shocklateboy92> _*-test*_- makes it bold, italic and strikethrough
[13:21] <shocklateboy92> you reckon that would mean too many possible combinations?
[13:21] <alin> yes... if you have to do it separately yes
[13:22] <alin> I do not know if there is a regex... for abc in any order
[13:22] <alin> thought that would not be difficult to write
[13:22] <alin> as you can always sort it
[13:22] <shocklateboy92> oh of course there is
[13:22] <alin> and always match only the ascii sorted 
[13:22] * shocklateboy92 kicks himself in the head
[13:22] <alin> shocklateboy92: then... problem solved
[13:23] <shocklateboy92> alright
[13:23] <shocklateboy92> I shall give that a try

I don't fully understand the plan, but whatever you do should _exactly_ match what GTalk does.. as the goal is to make sure what you see is what your friend (in GTalk) is seeing.

We are no longer GTalk formatting, but general. This bug is now fixed.