Smilies displaying mid-word

While those of us who type properly put spaces before/after emoticons, a lot of people don't. What would be neat, however, is the disabling of emoticons as a temporary basis (view > emoticons on/off) or something.

So it's better to cater to the people doing the wrong thing? I think it's more confusing to see an emoticon in the middle of a word than to see a bare ":)"

And maybe people would start typing better if their emoticons didn't work. There's no harm in that. :)

Bug #703 looks like another specific case of this problem.

How would somebody using another client know if it displays different on mine? If every other client is displaying mid-word, we'd be the odd man out doing something strange for no particular reason.

Putting spaces around our emoticons counts as "doing something strange"? Sounds like a reasonable thing to me! I don't care whether my buddies using other clients see emoticons at weird times. I just want them to show up at logical times on MY client.

I see what anonymous is saying... people in other clients see smilies in mid-word, but you won't, so they'd continue doing the wrong thing and you'd see ":)" sometimes. Personally, I'd still rather see ":)" than a smiley mid-word.

AIM and (I assume) Gaim show the emoticon. iChat does not.

If people aren't going to go for this change, I'd at least settle for a preference.

I'm with marshall. Emoticons should never be displayed inside links or inside words. An emoticon should display as an image if:

• It is surrounded by spaces
• It borders another emoticon
• It ends a line

Marking #703 as a duplicate of this, as I like this discussion better.

Please don't assign tickets (especially not to the non-existant person anybody)

I just hit this when pasting an FTP URL into Adium. sftp://user:pass@url.com:22/home/user/web/files puts a wry smiley in the middle of the protocol! This doesn't happen with http://... so I'm guessing Adium's already checking for those. Could it be extended to any protocol? (\w+://)

John.

sftp isn't a recognized protocol in Adium. I suggest you make a separate ticket for it.

this is an issue for times as well. 11:00 is displayed as 11"Some simlie"0. i don't see why this is even an arguable issue... don't we want things displayed correctly? who cares what every other client is doing? this is the BEST client, and as such, should not need to be "the same"... at version 0.86, as i am using, we haven't decided this argument yet? evands, i'm with you...

Is this something we want to look into for 1.0?

(In [14454]) An emoticon now displays if and only if one of the following is true:

• It begins or ends the string
• It is bordered by spaces or line breaks on both sides
• It is bordered by a period on the left and a space or line break the right
• It is bordered by emoticons on both sides or by an emoticon on the left and a period, space, or line break on the right

No more "sad code!"

Fixes #721.

Just curious, does that mean that "hey dude:) " wont give you a smiley?

David Munch has a point. If there is only whitespace after the emoticon, it should still be shown. Anyway, that works just fine in 0.89, but I still get a smiley in the middle of URLs (http://).

Should probably just run something like trim() on the string before examining it, or what not. I agree with the two above commenters.

(In [15830]): Fixed an edge case with smiley parsing: If a smiley is at the beginning or end of the line after trimming whitespace it should be displayed graphically. This check is done last because -[NSString stringByTrimmingCharactersInSet:] is more expensive than other things done for the emoticon.

anonymous, milestone on this ticket is Adium 1.0; you won't see any change until 1.0.