Version: 0.11 (using KDE KDE 3.5.0) Installed from: Ubuntu Packages OS: Linux Yeah, a short description was hard to come up with. Here's an example: I have two emoticons: :r and :rolleyes: Notice that :r is the first part of :rolleyes: If I have "Emoticons must have spaces around them" turned on, :r => [emot :r] :rolleyes: => :rolleyes: // NO EMOTICON PARSING If I have "Emoticons must have spaces around them" turned off, :r => [emot :r] :rolleyes: => [emot :r]olleyes // (semi-)expected behavior, but the better match should be chosen first, as per http://kopete.kde.org/emoticons/emoticonspec.html#impl-parser > Emoticon parser > > There are no real recommendation how to parse emoticons. But an emoticon with a longer string should have the priority over one > with a shorter string. (Example: if both :-() and :-( are in a theme, the picture for the first one should be used when :-() is > encountered)
I'm having the same problem here with version 0.11.91, compiled from source with kde 3.5.1
According to the code, it is taken by the order they are in the xml file.
Right; that makes this a bug according to the spec (written by you ;) )
:-() doesn't show as an emoticon when spaces are turned off r828851 kdenetwork
Created attachment 26951 [details] Fixes the sorting of the emoticons for KDE 4.1 Revision 812010 In revision 812010 the emoticons are unsorted. This patch fixes that. It probably doesn't follow KDE standards but it works.
The patch sorts, using qSort, according to size largest to smallest. This allows the rest of the code to behave as expected. It still applies cleanly to revision 869212
*** This bug has been marked as a duplicate of bug 174262 ***