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.)
À ce stade, j’appuie simplement à nouveau sur tab pour compléter automatiquement la variante :t2 que je souhaite.
Cependant, suite à ce qui semble être une mise à jour récente, chaque fois que j’appuie sur tab pour compléter le premier :+1:, un espace est maintenant ajouté à la fin, ce qui signifie que je dois maintenant appuyer sur la touche retour arrière, puis continuer avec mes variantes :t ?
Je comprends tout à fait les inconvénients ici, mais auparavant, nous insérions un espace et reculions le curseur, ce qui créait de la confusion et engendrait de nombreux problèmes subtils.
Nous apprécions certainement d’insérer un espace, mais je suis réticent à ce que :heart: insère un espace tandis que :+1: ne le fasse pas.
Je pense que la meilleure solution serait d’introduire un « paramètre d’arrière-plan » dans les paramètres locaux du navigateur. Il suffirait que le client « se souvienne » du ton de peau sélectionné la dernière fois et l’ajoute par défaut.
La correction est alors triviale : vous ne modifiez cela qu’une seule fois ici :
Ainsi, les futurs emojis que vous insérerez incluront automatiquement le ton de peau, par exemple . J’apprécie beaucoup cette approche car elle respecte davantage les utilisateurs. Il est très probable que vous souhaitiez conserver le ton de peau que vous venez de choisir.
L’application cliente se souvient déjà de la teinte de peau sélectionnée par l’utilisateur (et le sélecteur d’emojis respecte déjà la teinte de peau choisie), mais actuellement notre autocomplétion d’emojis ne respecte pas la teinte de peau sélectionnée et propose toujours la teinte de peau jaune. Ce PR fera en sorte que notre autocomplétion d’emojis utilise par défaut la teinte de peau sélectionnée par l’utilisateur.
Concernant ma plainte/suggestion initiale, oui, je suis satisfait du changement. Le curseur est maintenant décalé après l’espace inséré, donc je pense que c’est bon. Merci d’avoir pris en charge cela.
. J’apprécie beaucoup cette approche car elle respecte davantage les utilisateurs. Il est très probable que vous souhaitiez conserver le ton de peau que vous venez de choisir.
