)
See, if it processed them from left to right, it would’ve put a there, followed by a “)”. But it doesn’t. Here’s another one, to make sure it’s not just the :
:rolleyes:)
And here’s another test:
:rolleyes:confused:
rolleyes:
:rolleyes:(
It’s not going in the reverse order that they’re listed on the smilies page; otherwise it would’ve put a :rolleyes: on that last line. So what’s going on?
:eek:
:wally
works fine on me…
ultrafilter is asking how it parses anomolous cases where two smilies follow each other and share a colon, since some of them end in a colon, and some of them begin with a colon. His example suggests that it does not just scan the text once starting at the left, substituting the image as a possible substitution is completed. I’m mildly surprised, as that would be the efficient way to do it, and this isn’t an application where the result would be particularly crucial, one way or the other. They apparently substitute them one at a time in some preferentential order:
cool: confused:
:eek:mad: :mad:eek:
Note that the same one is taken whichever way I order the pairs, and we’ve established that cool > confused and mad > eek
mad: :mad:cool:
cool > mad.
:mad:confused: mad:
mad > confused.
eek: :eek:confused:
eek > confused. So, for these 4:
cool > mad > eek > confused. Ordering the rest of them is left as an exercise for the reader. What I actually did was a merge sort. This is valid assuming the things are actually well ordered. Let’s make one of the comparisons we didn’t make to check transitivity:
eek: :eek:cool:
Looks good. And I don’t BELIEVE I’m concerning myself with THIS!
This is just a curiosity; It looks like there’s some internal order in which smilies are processed. Now why would do this, and not just read them left to right, is a BIG question.
If I had to guess, I’d say that since these are things individual customers can add through administration, and the strings are arbitrary, they just go through them one by one rather than constructing a state table to do a proper lexical scan, or some similar technique. Simpler, and they probably figure the extra overhead will be in the noise level.
Makes sense.
And for those interested, they do the smilies after replacing ampersands and angle brackets with their html escape sequences. Thus, an ampersand next to a close parenthesis (or j) will also create a winking smilie (or happy orthodox Jewish guy).
To clarify, the character & is converted by the software to & to prevent similar sequences from being possible (why they do this, I don’t know). Thus if you type &[sup][/sup]) it gets converted first to &[sup][/sup]) which then gets converted to &) (the semicolon is not necessary to display correctly. Likewise for <[sup][/sup]) >[sup][/sup]) &[sup][/sup]j >[sup][/sup]j and <[sup][/sup]j.
Of course, in order to prevent the effects, as I did, you can put in extra VB tags such as [b][/b] between things so the parser can’t catch them.
Since I seldom use smilies.