Bug #173

smilies : not differentiate min. from maj.

Added by Stéphane C over 7 years ago. Updated over 7 years ago.

Status:NewStart date:08/24/2011
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


a bug or bad choice ?

Chans topics & messages displayed are altered with certains emoticons...
as the smiley oO in the word flood, etc.
It comes from not differentiate min. from maj.
Following the exemple of :o (surprised) and :O (scared). Signs are not allowed at the same picture ;).

(cf. attached file)
Can you change the rule, or fix the problem ? thank you :)

probSmilies.jpg (22 KB) Stéphane C, 08/24/2011 08:29 pm


#1 Updated by Valentin Manthei over 7 years ago

Actually, I think this is a feature. It's easier to setup emoticons, if lower and upper case characters are handled the same.
However, if there are some other opinions, we can discuss it.

#2 Updated by Stéphane C over 7 years ago

I agree with you... too
observe these arguments

  • with usual form :
    xd, xD, XD, Xd
    we must consider the case, and list all the possibilities

disadvantages: is not to forgot it & this multiplies the expressions

  • with your system :
    simplifies the writing for the same result as above


- no method to prevent the display of a smiley

Ex. KVirc Client displays a smiley on the words "pirate", "heart", "smileglasses"
so, LightIRC is set to do the same and i can't prevent this display : Pirate with P maj. for ex.

- I am the owner of channels games : quiz, motus, scrabble

the text must rigorously be displayed
Can you find this word : _ _ _ _ ?
Cool ?
-almost ! : _ O O _
perhaps boom, zoom, zoos, etc.
this is the already mentioned problem of "oO"
(my database has 785 words with 2 "o")

- a web link ?

Imagine : 3w.xdprod.thing ("xd" = Emoticon)

what is the good choise for a modern applet ?
flexibility, increased personalization.

why not combine the two capabilities?

I suggest three ways :

  • 1st method "global switch"
    EmoticonsCasSensible = 0/1
    0 for maj. = min. (default)
    1 for maj. is not min.
  • 2nd method "option set for each element"
    :p\i -> prrr.png
    option "\i" for "implicit" then :p = :P

or if you prefer the add formal option, as :
:p\f -> littleprr.png for only :p and not :P

  • 3rd method (extra) regexp (re_ syntax) for "experts"
    (implicit :)
    (formel :)
    is different

In my opinion the second approach seems better. With the addition of an optional "\f".

And three methods could be applied ?
try to be reasonable :)


#3 Updated by Roi Conde over 7 years ago

I don't really see the point or advantage by making difference between capitals or not.

The only atmosphere where 'HELLO' != 'hello' is in the coders world, but I think that for a chat, it would make no sense, and more than probably, people won't understand what's happening if for some reason, the smiley is not shown (if they mix Capitals and lowercase).

I think it would be a bad idea.

#4 Updated by Stéphane C over 7 years ago

Roi Conde,

I understand you... but not !
the advantage is not having a disadvantage.
Follow me :

"I'm certain that users prefer not to see a smiley expected, than the opposite situation"
That people know the difference between oo and oO

I have two other applets available on my page :
  • For these applets, differentiation maj/min is. (as some clients : kvirc, mirc scripts, miranda...)
  • If a smiley is displayed where it should not, sometimes i can act. But never with LightIRC. No choice, Impossible ! :)

It's up to us to make the proper adjustments, for the benefit of users.

  • It would be accessory just want to differentiate : o and O

But make it possible, would have no more worries than usual :)

"the problem is particularly noticeable in the word games (and web links)"

remember :
my database contains really 785 words with "oo" (378323 total words)
have a look for "xd" emoticon : Auxdits, rixdale, etc. (french words) and for other languages ? I don't know.

I think: there are hundreds of IRC, thousands of salons and different perspectives.
Nothing was done without reason.
I prefer the flexibility, for something that is not superfluous

Now, look at the Concurrency :

(applet coolsmile)


smiley.sad.emoticons=:-( :( :-< :<

yes, no a-z characters : but several signs for a single smileys ! Does that not the beginning of the solution ? (I wanted to start a new topic)

next :


smiley.naughty.emoticons=:p :P :-p :-P slurp :P°

(miranda client)

Smiley = "./ksk-tongue.png", 1, ":P ;P :-P ;-P :p", "Tongue"

it's not very elegant, but it is so

I take my idea from yesterday... imagine :

(new version of LightIRC)

:p :-p :p° -> prr.png (default = elegant = implicit)

oO Oo\f -> suspicious.png (option f = strict = formal)

"I understood the idea of LightIRC was good, but not complete..."
then the other applets are more flexible.
with little option \f : LightIRC will be over !

Then I do not think it is so hard to code :)

Merci Roi Conde, to participate in the discussion :)

#5 Updated by Roi Conde over 7 years ago

Better and easier would be to replace xd for xdd (for your particular problem) and so on with all the characters that might be incompatible with certain words.
It's what I've done.

#6 Updated by Kevin Glazenburg over 7 years ago

Valentin Manthei wrote:

Actually, I think this is a feature. It's easier to setup emoticons, if lower and upper case characters are handled the same.
However, if there are some other opinions, we can discuss it.

I think there should be some way to handle upper and lower case characters differently.
Stéphane C has given some nice ways of handling this. :)

Also available in: Atom PDF