Clicking smiley: don't insert space

[Simon]

Hi,

rant rant rant, Simon has found something again with the site. :>

When writing a post, clicking a smiley above the textbox inserts <space>:smileycode: instead of :smileycode:. Why is this bad?

• Violates the user expectation: The button should insert exactly a smiley. It fails to do that. It inserts a space and a smiley.
  
• Leads to bad formatting: People generate posts with two spaces before the smiley. One they type themselves, the second comes from the button. This is very, very common:
  Recent example 1
  Recent example 2, at the end of the first line, and in the lines starting with smileys.
  Recent example 3, it happens even with many smileys directly in a row
  Recent example 4
  
• Even when you've forced yourself not to insert the manual space, if you want a smiley at the beginning of a line, you can't get around erasing the unwanted space. See example 2 above, that has the unnecessary space almost 20 times at a line-begin!
  
• Computer wants to be smarter than the user, but apparently fails.
  
• Two-fold inconsistence: The button doesn't have the space (only the image is clickable), but its output does, while the replaced string doesn't have it. (The replaced string is :smileycode:, not <space>:smileycode:, upon viewing the finished post.) Removing the space from the output makes all three things consistent.
  

I've considered to suggest the Javascript to check for whether there's a non-whitespace char in front of the cursor, and only insert the space on these occasions. This is also bad: Now the script must interpret whether BB-tags will be replaced or not. This requires the JS to include a full-blown BB-parser, which seems absolute overkill for probably unwanted complexity.

The sane solution is to ditch the inserted space. This is the simplest thing to do in the first place, and the simplest solution to the problem.

I hereby propose this. :-)

-- Simon

[ccexplore]

The insertion of space appears to be done automatically by the forum software and I haven't found a setting to suppress that.  Maybe a mod exists though to do so.

[namida]

A "mod" to do so should be as simple as changing a single character somewhere in the source code; it's something I'll look into later on tonight. I don't see much disadvantage in this change, so unless anyone speaks up with any objection to it, I don't think we need a poll this time.

[namida]

Done. Turned out to be a slightly larger change than just one character in the source code... it actually involved removing 5 characters. And a fair bit of time hunting down where these 5 characters were.

[ccexplore]

Interestingly I just noticed now that in one case I've been implicitly relying on the automatically inserted spaces:  consecutive smilies.  I tend to do that a lot, and now with the change I realize I had been implicitly relying on the automatic space insertion without even realizing it, because without the space, the smilies are too close together and don't look quite as nice:




Oh well.  I can adapt, just like in the past there are other (though much much rarer for me) cases where the automatic space insertion is unwanted.  I seem to be able to generally adapt to most things instead of complaining.

[ccexplore]

It's strange it took me this long to hit this, but it looks like in handling smilies, the forum software tries to guard against accidental transforms by basically requiring the previous character to be a non-letter, I think.  In other words, test;P;P as you can see is left alone (but not just specifically for that smiley of course, it pretty much applies to all of them).  Makes sense to avoid accidental transforms in normally typed text, but really bad user experience when this happens upon click-and-insert.  Overall, for me this is getting to the point of defeating the purpose of being able to click-and-insert. 

I suppose the proper solution is to perform an automatic space insertion upon click-and-insert, but only when the previous character is a letter or whatever class of characters it is that would prevent the forum software from interpreting the smiley code.  Then we get the best of both worlds where Simon don't get burned by extra spaces, and I don't get burned over and over by "forgetting" spaces.

[Simon]

This is exciting, I'm looking forward to the solution.

My gut reaction in the OP was that previous-char-based solutions breed different problems. Most likely, those problems would be rarer than ours now.

Since I don't like complication, maybe replacing ;P and similar common things is bad in the first place, and all smileys should become :lem-tongue: and the like.

-- Simon

[namida]

Changing this would involve Javascript, which is something I'm not overly familiar with. That's not to say I can't look into it, of course, but no promises...

[Mindless]

The more changes you make to the forum software, the more painful it'll be to upgrade it.