Je voudrais désactiver le menu contextuel lorsqu’un # sans espace est tapé sur mon instance de Discourse.
Par exemple, sur meta, cela ressemble à ceci :
Je préférerais que ce menu contextuel n’apparaisse pas du tout. J’ai cherché des options et je n’ai pas trouvé de moyen de désactiver cela.
Voulez-vous le désactiver complètement ? Ou voulez-vous l’éviter juste au cas où aucun caractère suivant n’aurait été tapé ?
Nous avions l’habitude d’attendre qu’au moins 1 caractère soit ajouté après le #, mais nous avons changé cela pour qu’il ne soit plus nécessaire (les gens l’avaient demandé par le passé, mais nous l’avions évité plus tôt pour des raisons techniques qui ne s’appliquent plus).
Merci pour votre réponse rapide, idéalement je peux réactiver le comportement précédent, ce qui signifie, je suppose, que je devrai taper #c avant d’obtenir une liste d’étiquettes ou de catégories qui correspondent à ce caractère. Si cela est difficile, désactiver complètement la fonctionnalité est également une option viable, mais idéalement pas au prix de la suppression des étiquettes et des catégories.
Pouvez-vous expliquer l’avantage d’attendre un caractère avant de proposer la complétion automatique ?
Bien sûr. Je trouve cela distrayant d’être confronté à un menu de catégories lorsque je tape simplement un en-tête. C’est particulièrement évident avec les auteurs plus jeunes/plus lents. Lorsqu’ils tapent # puis réfléchissent à l’en-tête qu’ils veulent écrire, on leur présente ce menu de catégories qui n’a rien à voir avec ce qu’ils essaient de taper.
Oui, « # » l’arrête, mais c’est distrayant pendant le temps qu’il faut pour trouver la barre d’espace et déroutant car l’ordinateur suggère quelque chose qui pourrait avoir du sens lorsqu’on tape un commentaire, mais qui n’a pas vraiment de sens lorsqu’on rédige un article et qu’on saisit un titre.
Est-ce clair ? Désolé, j’ai essayé plusieurs fois de le décrire, mais je ne suis pas sûr d’avoir réussi 
La syntaxe Markdown correcte pour un titre inclut un espace après le #. Avez-vous envisagé d’utiliser l’espace pour le supprimer ?
Je parle de la courte période de temps entre le moment où quelqu’un tape # puis appuie sur espace.
Considérez un dactylographe qui tape à l’aveugle, il tape # puis cherche l’espace et maintenant il a une option de menu sur laquelle il doit prendre une décision. Même si vous tapez “#” rapidement, cela apparaît toujours pendant une courte période, alors qu’avant, il fallait l’écrire intentionnellement en utilisant plusieurs lettres, par exemple “#c” pour démarrer une recherche / sélectionner une balise.
Ce que je suggère, c’est que ce qui est maintenant un comportement par défaut est distrayant et interrompt le flux d’édition plutôt que de fournir un raccourci vers une fonction plus utilisée que la création d’un en-tête. J’ai vu cela avec certains de nos nouveaux utilisateurs d’ordinateurs, mais je trouve cela également distrayant car je réfléchis généralement au nom de mon en-tête et maintenant je dois appuyer sur # pour contourner un menu distrayant que je n’utilise jamais.
Si je suis dans la minorité, je peux envisager de le corriger, mais j’espérais une option basée sur la configuration.
Je me demande si nous pourrions demander une option de configuration - combien de caractères doivent être saisis avant que la fenêtre contextuelle d’autocomplétion n’apparaisse ?
Comme le # est utilisé pour le balisage ainsi que pour la communication humaine ordinaire, le fait qu’il fasse apparaître quelque chose trop rapidement me semble être un problème d’utilisabilité - et peut-être d’accessibilité.
Merci d’avoir signalé cela.
Je pense que quelque chose comme cela est une suggestion raisonnable. Laissez-moi voir ce que les autres pensent de cette idée.
Compte tenu de ce contexte, peut-être serait-il judicieux d’envisager d’en faire une préférence utilisateur plutôt qu’un paramètre du site… 
Comment nommeriez-vous ce paramètre pour les auteurs plus jeunes/plus lents afin qu’ils comprennent immédiatement ce qu’il fait ?
De plus, je pense que beaucoup d’utilisateurs n’accèdent pas à leurs paramètres, sauf pour remplir leur profil utilisateur. J’ai l’impression que la grande majorité des utilisateurs utilisent le logiciel de forum tel quel et ne sauraient même pas qu’une telle option pourrait exister dans leurs propres paramètres (je fais partie de ces gens 
).
Hmm, je ne suis pas à l’aise avec le fait de faire de l’accessibilité une option. Je pense que la valeur par défaut devrait être accessible, tant au niveau du site qu’au niveau de l’utilisateur.
Je ne suis pas sûr de trouver qu’il s’agisse d’un problème d’accessibilité (car il n’y a aucun problème pour accéder à une fonctionnalité). Je pourrais accepter de qualifier cela de problème d’utilisabilité (mineur), mais j’y vois surtout une question de préférence.
Je me creuse aussi la tête sur le commentaire d’accessibilité.
En regardant d’autres plateformes, certaines proposent des suggestions de tags dès qu’un # est entré - Twitter sur iOS commence par proposer les tags tendance jusqu’à ce que l’utilisateur entre un deuxième caractère.
Je ne suis pas convaincu par l’angle de la recherche à tâtons non plus, par définition, ils regardent leurs touches. Au contraire, la fenêtre contextuelle de tags sert de rappel que l’utilisateur est maintenant en mode de saisie de tags jusqu’à ce qu’il appuie sur espace.
Ce que j’aime dans le nouveau comportement, c’est à quel point il rend la saisie de tags plus visible pour les nouveaux venus.
Les titres ne peuvent pas être saisis à moins qu’ils ne soient au début d’une nouvelle ligne, mais voudrions-nous que le comportement par défaut change en fonction de la position du curseur ? Le seul groupe qui sera confus, ce sont les dactylographes qui ne savent pas que le # pour les titres doit être suivi d’un espace.
Alors, où en sommes-nous ? Il est douloureusement évident que si cela rend les tags plus visibles, cela surcharge un opérateur pour la saisie dans l’éditeur d’une manière que je trouve confuse et qui interrompt le flux de modification de leur publication.
C’est un problème même lorsque vous n’ajoutez pas de nouveaux en-têtes. Utilisez simplement la flèche pour parcourir un sujet que vous avez déjà modifié et qui contient des en-têtes. Vous descendez jusqu’à un #, puis lorsque vous continuez à appuyer sur la flèche, cela commence à sélectionner un tag ou une catégorie particulier plutôt que de continuer à descendre la page avec votre curseur. Je dois maintenant appuyer sur Échap pour continuer à descendre dans la publication avec le clavier ou éviter les mines terrestres #.
Modifiez une publication avec les deux exemples ci-dessus et utilisez la flèche pour naviguer et vous verrez exactement ce que je veux dire. Je suis d’accord que cela rend les tags plus visibles, mais si vous n’utilisez pas de tags, ce n’est pas une fonctionnalité, c’est quelque chose de nouveau qui gêne ce que vous faisiez auparavant.
Quant aux jeunes éditeurs. Le fait que leur éditeur fasse des choses magiques alors qu’ils essaient simplement de comprendre comment créer des en-têtes avec le langage markdown surcharge l’utilisateur avec plus de choses qu’il n’a pas besoin de savoir ou de comprendre.
Il est acceptable que la décision soit de ne rien faire ici, je vais chercher un moyen de le corriger, mais compte tenu de l’interruption du flux d’édition et de la courbe que nous ajoutons aux nouveaux utilisateurs qui doivent comprendre plus que ce qui est devant eux, il semble qu’une option soit un bon compromis. Je le prendrais au niveau du site car probablement si vous utilisez des tags, c’est plus une décision de site plutôt qu’une décision par utilisateur, mais par utilisateur basé sur la valeur par défaut du site est probablement la voie à suivre.
M. Jobs avait donc raison quand il a dit que les curseurs sont inutiles
Je plaisante.
Mais j’utilise tout le temps les touches curseur car j’écris beaucoup, surtout de longs textes, et je ne reconnais pas la situation que vous décrivez.
(Edit : Je suis arrivé ici en esquivant toutes les mines 
)
et même pas ici et maintenant
Je peux utiliser des tags grâce à l’autocomplétion avec le symbole dièse car ce nouveau système fonctionne si bien #comment-faire ou en tapant simplement un tag si je m’en souviens : #installation-non-prise-en-charge — cela a aussi fonctionné.
Alors — qu’est-ce que je ne comprends pas maintenant ?
Pour le moment, nous n’avons pas l’intention de faire de changements spécifiques ici.
Je ne suis pas sûr de la meilleure façon de résoudre ce problème et cela semble un peu improbable que cela se produise, mais je peux le reproduire en plaçant mon curseur au bon endroit et je suis d’accord que c’est gênant quand cela se produit (lorsque le curseur est à 1 caractère du début de la ligne).
J’apprécie la mise à jour et la façon dont @mcwumbly a capturé l’état actuel. Merci, @mcwumbly, d’avoir pris le temps de créer également les exemples animés ! Il n’y a rien d’autre d’ouvert de mon côté.
La correction pour moi consiste simplement à désactiver la complétion automatique pour les hashtags
Donc
#
N’émettrait pas de complétion automatique
test #
Émettrait une complétion automatique
#t
Émettrait une complétion automatique
En ajoutant ces règles, toutes les manipulations du curseur cesseraient et l’impact sur l’utilisateur serait absolument minime.
@martin … des pensées ?
Juste un rappel qu’il y avait certains sujets où des personnes (moi y compris) demandaient le comportement actuel auparavant, quand il était exactement comme décrit.