Lorsque le paramètre « Activer les raccourcis emoji » est activé, les émoticônes comme :) sont converties en vrais emojis (). Cependant, cela ne peut pas être contourné en ajoutant simplement une barre oblique inverse devant (\:)). Cela est incohérent avec d’autres cas où l’échappement fonctionne, et sur Discord, vous avez un paramètre similaire :
Cependant, ce n’est pas imposé : si je veux :-) brut, je peux simplement taper une barre oblique inverse devant, et j’obtiens ce que je souhaite.
Pour le contourner, il faut utiliser quelque chose comme un caractère à largeur nulle entre les deux, ou entourer une lettre de chevrons au milieu, car ceux-ci ne sont pas rendus, etc. Par exemple :
:<g>),
ce qui crée une mauvaise expérience utilisateur pour ceux qui souhaitent plus de liberté dans la façon dont ils écrivent les emojis.
Il ne s’agit pas seulement de raccourcis, mais de tous les émojis. Je suppose que je ne suis pas contre le fait de le modifier pour que nous arrêtions d’utiliser les émojis si nous avons un antécédent \
Donc :
\:thinking: a la même parité que \`thinking` et \*thinking*
J’ai fait un post à ce sujet sur le forum de développement Roblox, qui utilise Discourse, et je suis d’accord : devoir toujours utiliser des caractères vides ou autre chose pour ne pas utiliser d’émoji est assez agaçant. Les émojis rendent souvent votre post un peu moins professionnel, et parfois vous voulez juste un petit :) sans avoir un à la place.
J’espère que cela sera modifié (« Je suppose que cela ne sera pas mis à jour puisque c’est open-source et tout cela »).
En fait, j’ai trouvé ce sujet parce que je suis moi-même tombé sur cette question (j’ai essayé d’échapper à un smiley, mais hélas, il s’est transformé en emoji ET a avalé mon caractère d’échappement… l’audace, ahah)
Nous avons déjà une solution de contournement pour cela avec les accents graves, par exemple :-) et :) .. ainsi que les blocs de code .. nous ne sommes pas vraiment sûrs qu’il soit nécessaire d’ajouter encore d’autres méthodes pour atteindre le même objectif ?
Mon argument portait davantage sur l’utilisation d’émojis dans une vraie conversation, et ne suffirait-il pas de ne pas rendre l’émoji, mais de le garder comme émoticône s’il y a un antislash devant ?
`` sont pour le code en ligne ; si vous ne discutez pas de programmation, utiliser des blocs de code n’a pas de sens. Même si c’était le cas, cela n’aurait toujours pas de sens, car les codes en ligne sont généralement utilisés pour mettre en évidence une seule ligne de code ou pour mettre en évidence des noms de classes/membres, etc.
Pas tout à fait — HTML tentera de se rendre si vous tapez par exemple <a>. Ainsi, les blocs de code en ligne sont la méthode attendue pour afficher cela.
Je ne suis simplement pas sûr de vouloir consacrer du temps précieux à l’ingénierie à quelque chose pour lequel nous avons déjà une solution.
Je recommande d’ouvrir un ticket en amont, bien que cela puisse signifier que nous devrons annoter les jetons de texte avec « original brut pour le jeton de texte ».
Ce bug présente le même problème de conception que « les traits de soulignement peuvent casser les liens automatiques », mais il s’agit peut-être d’un correctif spécifique possible. Je vais examiner ce qui peut être fait.
Un utilisateur de mon forum s’est plaint de ce problème de mise en forme. J’ai désactivé la complétion automatique des emojis comme solution pour notre cas d’utilisation, mais depuis que Discourse a été mis à niveau vers markdown-it v13 il y a quelque temps, le problème semble persister alors que l’échappement par antislash fonctionne maintenant sur https://markdown-it.github.io/
Cela pourrait-il être dû au fait qu’Ember.js s’appuie toujours sur la version 12 de Markdown, comme indiqué ici ?
). Cependant, cela ne peut pas être contourné en ajoutant simplement une barre oblique inverse devant (\:)). Cela est incohérent avec d’autres cas où l’échappement fonctionne, et sur Discord, vous avez un paramètre similaire :
a la même parité que `thinking` et *thinking*
