When you add a mention or emoji by typing @ / :, followed by whatever is required, and hitting Enter, it completes the rest of the username / emoji name, followed by a space. I assume this space is so that you can keep typing, but it doesn’t shift the cursor to account for the newly added space. So as it is, you have to hit the spacebar anyway, and you have trailing whitespace.
Considering that you may also want to finish a sentence (or be done writing the post) after the mention or emoji, I’d be inclined to just get rid of the trailing space and let people hit spacebar if they need a space. The second option is shifting the cursor forward one character so it’s after the space (was this already the intended behavior?), but I’m not sure I see much value in that. I’d rather hit the spacebar when I need a space than delete an automatically added space when I don’t need one.
(I know this is borderline a bug, so feel free to move it if this is more ux or feature. Also, as I wrote the previous sentence I just realized that this happens with tags / # too.)
Has something changed on this in the last two weeks or so?
I add a lot of :t2 values to the end of all my emojis and I always type them using the keyboard.
For example, to get a white-coloured thumbs up I’d type:
:+
Then I’d press tab to complete the yellow thumbs up, then I’d continue to type :t which would present me a short list of colours:
At which point I’d simply press tab again to autocomplete the :t2 variant that I want.
However, following what seems like a recent update, whenever I tab to complete the first :+1: a space is now added at the end, which means I now need to press backspace, then continue with my :t variants?
I completely get the inconvenience here but previously we were inserting a space and moving the caret backwards, it was causing confusion and made for lots of subtle issues.
We certainly like inserting the space, I am uneasy making it so :heart: inserts a space and :+1: does not.
What I think would be best here is to introduce a “background setting” in browser localsettings. Just have the client “remember” which skin tone you selected last and then default to adding it.
Then the fix here is trivial, you change this once here:
And then future emojis you insert will append the skin tone eg . I like this so much better cause we are respecting users more. It is very likely you want to keep to the skin tone you just picked.
The client app already remembers the skin tone that the user selects (and emoji picker already respects the selected skin tone), but currently our emoji autocomplete doesn’t respect the selected skin tone and always suggests the yellow skin tone. The PR will make our emoji autocomplete default to the user’s selected skin tone.
Regarding my original complaint/suggestion, yes I’m satisfied with the change. The cursor is now shifted to after the inserted space, so I think it’s good. Thanks for taking care of this.
. I like this so much better cause we are respecting users more. It is very likely you want to keep to the skin tone you just picked.
