Journal Voter pour virer les emojis de Gitlab

Posté par  (site web personnel) . Licence CC By‑SA.
63
19
fév.
2022

J'utilise Gitlab de temps à autre, principalement pour embêter les devs en leur faisant des tickets. En général, une partie de mon temps de rédaction se passe à pester contre ces fichus emojis qui essaient de s'inviter chaque fois que je fais deux points. Je fais beaucoup de liste, dans mes tickets, et ça démarre toujours par cette typographie terrible : deux points. En fait, j'aime bien les deux points pour leur usage de base, qui n'est pas de faire des smileys. C'est vrai que je pourrais faire mes tickets en anglais, et en respectant la typographie anglaise qui consiste à coller la ponctuations aux mots : ça règle le souci. Sauf qu'on ne se défait pas si facilement de l'habitude de mettre des espaces avant ses deux points.

J'utilise aussi trop de smileys quand je cause à l'écrit. J'essaie de me soigner. Mais bizarrement, quand un :) m'échappe, le fait que ce fichu menu d'emoticone apparaisse ne me procure aucune joie et continue de me faire pester. En fait, si je voulais remplacer mes frimousses textuelles par un caractère unicode, j'utiliserais directement un caractère unicode. J'ai une touche "compose" qui est super pour ça.

Bref, cette fonctionnalité est l'une de celle qui me fait le plus râler sur Gitlab et quelques autres logiciels (oui, ne faites pas les malins, Rocket.chat et Discourse, je m'occuperais de votre cas un jour). Laissez moi faire deux points sans menu !

Râler c'est bien, faire quelque chose c'est mieux. J'ai donc fini par explorer mon instance Gitlab de fond en comble à la recherche du bouton pour désactiver la chose. Je ne code pas vraiment, par contre je suis administratrice sur une instance, alors autant dire que j'avais moyen de tout casser trouver la bonne option. Las, rien de tel dans le monstre. Et ça se confirme en cherchant plus loin dans les retours de la communauté Gitlab : on ne désactive pas les emojis. Jamais.

On m'a cependant indiqué que le problème avait déjà été soulevé dans une issue, et que s'il y avait assez de vote pour elle, alors peut-être que Gitlab se mettrait à considérer le problème. N'importe quelle façon de désactiver ce truc me conviendrais.

Je ne suis peut-être pas la seule à pester après ces habitudes anglophones qui considèrent qu'une espace suivi de deux points ne peut qu'être là pour faire des emojis, et que tout le monde adooooore ces petits dessins. Je me dis que parmi les lecteurs de Linuxfr, d'autres auront probablement pesté aussi de leur côté. Avec un peu de chance, en parler ici amènera plus de votes pour que cette issue soit prise en compte. Avec encore plus de chance, quelqu'un a trouvé un hack pour brûler ce système d'emoji et le partagera en commentaire.

Pour info, ce message contient 4 fois ces deux points, et jamais je n'ai pesté contre le système de Linuxfr. C'est tellement, mais tellement confortable !

Pour une fois, au lieu de pertinenter le journal, vous pouvez directement pertinenter l'issue : https://gitlab.com/gitlab-org/gitlab/-/issues/20231. Par contre, si vous voulez moinsser, ne le faites qu'ici, merci !

  • # issue pertinent

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Moi je n'ai pas (toujours) de touche compose qui fait bien les frimousses Unicode, mais ça me fait aussi chagrin quand je rédige en français et que ce menu casse-pied joue l'opportun.
    Ayant l'impression que les autres usagers ne ressentent pas la même gêne que moi, je n'ai jamais chercher à désactiver cela sur les instances que j'ai eu à gérer. J'aurais cependant pensé la chose faisable et tombe des nus en découvrant le résultat de ton exploration. Mais pourquoi Gitlab et autres (faut que je vérifie si Gitea fait pareil) se sentent obligés de copier les :poop de Github ?!? (par contre moi je viens de pester contre LinuxFr de censurer « 💩 » ou est-ce juste pas dans son vocabulaire trop propret ?)

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: issue pertinent

      Posté par  . Évalué à 6.

      Pour avoir des emojis avec Compose, il suffit de les ajouter dans son fichier ~/.XCompose.

      Voici un example (avec un préfixe un peu long mais facile à changer)
      https://gist.github.com/m93a/9b2056cb867f08a3fddce0004200841a

      Et pour conserver les combinaisons par défaut, on s'assurera que le fichier .XCompose contient une ligne include "%L.

    • [^] # Re: issue pertinent

      Posté par  . Évalué à 5.

      J'en aurais pas forcément fait un journal donc merci d'avoir pris l'initiative, mais le comportement par défaut des emojis sur gitlab est effectivement assez énervante. Le pire c'est que des fois je veux faire faire un simple smiley :) et gitlab refuse à moins d'être forcé :(

  • # Attendre un caractère après les deux points

    Posté par  . Évalué à 8.

    La solution la plus simple serait de faire comme Google Chat (pas taper, je l'utilise au travail et je n'ai pas le choix). Le menu d'emoji ne s'affiche qu'après avoir ajouté un caractère après les deux-points.

    Comme toi j'ai plutôt le réflexe de mettre une espace avant les ponctuations doubles et Gitlab me fait hurler à chaque fois, mais jamais Google Chat, c'est bien la preuve que ça marche :)

    • [^] # Re: Attendre un caractère après les deux points

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 19 février 2022 à 20:10.

      Cette proposition serait "moins pire", mais reste imparfaite à mes yeux. On ne sais pas forcément quoi taper comme caractère après pour avoir l'emoji qu'on veut, et si on le sais par cœur alors l'utilisation de Compose est aussi simple (et en plus avec une touche qu'on peut choisir). L'ajout d'un bouton dans la barre de menu me semble le plus ergonomique quand on cherche un emoji parmi les milliers qui existent.

      • [^] # Re: Attendre un caractère après les deux points

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        J'ai commenté dans ce sens tout à l'heure dans l'issue : un bouton pour chercher et insérer des caractères spéciaux est plus ergonomique.

        La proposition précédente est en effet moins pire parce-que ça évite d'être perturbé quand on fait un retour à la ligne ou un espace après les deux points (ce qui correspond déjà à la majorité des cas où on est importuné), et sinon fait une proposition plus réduite.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Attendre un caractère après les deux points

        Posté par  (Mastodon) . Évalué à 10.

        Sous Slack (notre outil au boulot) je trouve le système top

        • Dès que tu tapes ':' tu as la pop-up qui arrive sous ton texte
        • Si ça arrête de ressembler à un emoji, la pop-up se vire (par exemple au moindre espace)
        • Au fur-et-à-mesure que tu tapes, il n'y a que les emojis contenant le texte que tu as tapé (donc tu n'as pas à connaître exactement le nom de l'emoji, rien que ":green" va te donner la croix verte, un carré vert etc… tu peux facilement sélectionner puisque tu as une liste réduite)
        • Si tu tapes le nom exact suivi de ':' finaux, alors l'emoji est insérée, c'est la seule façon qu'elle s'insère dans ton texte 100% tapé au clavier

        Je trouve que ça a zéro impact quand tu tapes du texte où tu ne veux pas d'emoji, quel que soit le texte (et nos conversations ressemblent souvent à des tickets Github).

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Attendre un caractère après les deux points

          Posté par  . Évalué à 10.

          La solution de gitlab est particulièrement mal foutue parce que la pop up ne t'aide en rien ou en tout cas moi je ne sais pas m'en servir. Quand tu tape :, tu as le focus sur une pop up qui t'affiche quelques emoticons qui sont choisis pour tout sauf pour leur pertinence et tu dois tenter de tapper des trucs en espérant que le nom du smiley soit ça. Un sélecteur de frimousses qui se respecte te les montre trier (groupées par genre), te permet de filtrer sur des descriptions de celles-ci, etc Et oui elle ne vient pas t'interpeller dans ta frappe tel un vulgaire clippy.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Attendre un caractère après les deux points

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      C'est un problème de règle typographique entre deux langues.

      En français, tout symbole typographique à deux traits comme le : est suivi d'une espace*, de préférence insécable. À l'exception des chevrons ouvrants « où cette espace est fort logiquement situé après.

      Sauf qu'en anglais, ces symboles ne doivent pas avoir d'espace avant, et sont donc accolés au mot précédant.

      Donc, pour un anglophone, un deux-points qui est précédé d'une espace est moins valide, et peut donc servir de raccourci.

      En général, je déteste justement pour ce genre de situation tous les langages qui réservent trop de symboles typographiques comme le MarkDown, BB2 et le Wiki, justement pour ce genre de collusion entre les usages linguistiques. Alors qu'avec un langage comme le HTML qui n'en réserve que trois (<, > et &, et donc je ne compte pas le ; puisqu'il fait parti du mot ouvert avec l'éperluette), on a beaucoup mais alors beaucoup moins ce genre d'incidents ultra-pénibles à l'usage, ce que les auteurs anglophones ne comprennent pas.

      • Oui, l'espace est féminin en typographie.
      • [^] # Re: Attendre un caractère après les deux points

        Posté par  (site web personnel, Mastodon) . Évalué à 7.

        symbole typographique à deux traits comme le :

        Tu veux probablement parler des ponctuations hautes

      • [^] # Re: Attendre un caractère après les deux points

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Il n'y a pas que le point-virgule que tu n'as pas compté ; j'ajouterai bien à la liste : le signe d'égalité (=), les guillemets droit double (") et simple ('), la barre oblique (/), le point d'exclamation (!), le double tiret (--) et les crochets droits ([]) je crois. Mais bon, ces symboles ne sont spéciaux qu'au second niveau…

        Non, l'espace n'est pas féminin en typographie ; c'est plutôt que l'espace de genre féminin est un terme (et le concept) typographique tandis qu'au masculin c'est un terme mathématique et astrophysique.

        Il est bon de chipoter parfois.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Attendre un caractère après les deux points

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Petite confusion de ma part : ce sont les parenthèses et non les crochets pour ce que j'avais à l'esprit, et il faut rajouter le croisillon et le pourcentage…

          <!ENTITY % flow
          "%block;|%inline">
          
          <!ELEMENT p
          (#PCDATA|%phrasing
          -(%flow_only|figcaption)>

          Pour le reste, c'est plus classique et on retrouve bien l'idée de second niveau

          <p>Il faut fermer les balises&hellip;
          <img src="/images/dessins/geekscottes_005.png"
           title="auto-satisfaction récursive" alt="Geeks Cottes 5" />
          (for the fun)</p>

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Quitte à râler

    Posté par  . Évalué à 10.

    Ce qui me les brise, sur gitlab et github, ce sont les pages qui interceptent le / qui sert normalement à chercher dans la page, et privilégie le moteur de recherche interne du site. Je peux certes faire ctrl-f, et sans doute que ça peut se désactiver avec du userscript, mais je n'y connais rien en la matière.

    En attendant ça m'énerve :).

    • [^] # Re: Quitte à râler

      Posté par  (site web personnel) . Évalué à 8.

      Ha oui ça aussi c'est insupportable !

    • [^] # Re: Quitte à râler

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Merci pour la découverte (ctrl-f)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Quitte à râler

      Posté par  . Évalué à 6.

      Dans github, je pense que l'interception du '/' fait parti des raccourcis claviers qui peuvent se désactiver avec : menu Settings, Accessibility, désélectionne 'Character keys' et enfin Save.

      Pour gitlab, je n'ai pas de compte donc je ne peux pas tester.

      • [^] # Re: Quitte à râler

        Posté par  . Évalué à 4.

        En effet, pour Github ça fonctionne, merci !

        Par contre il faut être logé pour ça : la préférence ne reste pas après le logout.

  • # Et ce n'est pas tout

    Posté par  (site web personnel) . Évalué à 10.

    Si on pouvait supprimer cela ainsi que toute forme d'assistance dans les formulaire texte, ça m'irait très bien :

    • les popups d'emoji de GitLab.
    • le remplacement automatique des smileys ascii par des images, en particulier la substitution d'un simple sourire :) par un emoji aux yeux écarquillés et au sourire jusqu'aux oreilles. Si je voulais une image, j'insérerais une image.
    • les popups Azure de liens vers d'autres tickets lors de l'appui sur #. C'est en particulier l'horreur dans le wiki Azure, où # sert aussi à écrire un titre, du coup à chaque saisie d'un titre une popup sans rapport apparaît.
    • le fait que lorsque je sélectionne du texte pour le remplacer par du code inline dans un commentaire sur GitLab ou sur Slack, je tape ` et le texte sélectionné devient du code inline au lieu d'être remplacé comme dans tous les éditeurs textes depuis toujours.
    • les doubles quotes de fin de chaîne caractères qui s'ajoutent toutes seules quand je commence une chaîne sur Compiler Explorer et dans la plupart des IDEs, idem pour les accolades et les parenthèses. (Je sais fermer une parenthèse, merci

    En fait toute forme d'action non sollicitée dans une zone de texte.

    • [^] # Re: Et ce n'est pas tout

      Posté par  . Évalué à 10.

      ) De rien ;)

    • [^] # Re: Et ce n'est pas tout

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      le fait que lorsque je sélectionne du texte pour le remplacer par du code inline dans un commentaire sur GitLab ou sur Slack, je tape ` et le texte sélectionné devient du code inline au lieu d'être remplacé comme dans tous les éditeurs textes depuis toujours.

      Pour ma/mon culture/édification, quels éditeurs de textes as-tu connu ?

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Et ce n'est pas tout

      Posté par  . Évalué à 3.

      le fait que lorsque je sélectionne du texte pour le remplacer par du code inline dans un commentaire sur GitLab ou sur Slack, je tape ` et le texte sélectionné devient du code inline au lieu d'être remplacé comme dans tous les éditeurs textes depuis toujours.

      Je n'ai pas vraiment compris où tu voulais en venir mais dans Slack j'ai supprimé le comportement en direct de '' et '`' et ça va beaucoup mieux.
      Il y a une option pour ça. Je tape des
      et la modification n'est faites que quand j'envoie le message.

  • # Avec uBlock Origin

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 21 février 2022 à 13:14.

    uBlock Origin est un bloqueur de contenu très versatile, utilisable pour ce genre de modifications.

    Pour supprimer le popup d'emoji sur gitlab.freedesktop.org, tu peux utiliser la règle suivante dans tes filtres:

    gitlab.freedesktop.org###at-view-58:remove()

    En regardant le DOM, chaque popup de complétion a son propre div (at-view-users, at-view-issues, at-view-milestones, at-view-mergerequests, at-view-labels, at-view-snippets, at-view-commands), donc tu peux rajouter des règles pour en bloquer d'autres.

    La solution nucléaire pour désactiver tous ces popups est d'enlever leur parent avec

    gitlab.freedesktop.org##div.atwho-container:remove()

    Pour info, la directive :remove() enlève purement et simplement l'élément du DOM, plutôt que simplement le cacher. Ceci permet d'éviter que du javascript le fasse ré-apparaître plus tard.

  • # Le lobbying paie

    Posté par  . Évalué à 9.

    🤖 GitLab Bot 🤖 @gitlab-bot added popular proposal label 7 hours ago

  • # Haha, cette issue me parle étrangement

    Posté par  . Évalué à 3.

    Il ne faut pas trop se plaindre, avant lorsqu’on appuyait sur Esc avec la sélection d’émoji ouverte, le commentaire qu’on rédigeait se fermait sans être sauvegardé : https://gitlab.com/gitlab-org/gitlab/-/issues/20262.

    Mais oui, votez pour moi ♥

  • # Ca va

    Posté par  . Évalué à 1.

    Pour faire vraiment beaucoup de gitlab, et de :, il me semble pas que ça m'a jamais géné, car gitlab ne fait pas d’autocomplétion, si ? Alors qu'avec Rocket chat je passe mon temps a réécrire ses mauvaises autocomplétions. Et ça me fait vriller.

  • # Anecdote amusante Skype

    Posté par  . Évalué à 2.

    Une chose émotionellement difficile pour les pauvres hères qui doivent utiliser Skype, est l'icône de choix emojis, qui est un petit smiley. Une icône qui s'affiche à la fin de chaque ligne, donc.

    De CHAQUE ligne.

    Bonjour ☺
    Ça va ? ☺
    Toute ta famille est morte ☺
    J'espère que tu t'en remettras ☺
    C'est vraiment très triste ☺

    Quand ils ont déployé la màj qui a mis cette icône, des gens se sont plaint que ça causait des quiproquos avec leurs proches ou leurs clients :
    https://answers.microsoft.com/en-us/skype/forum/all/remove-smiley-face-from-mesages/9188b1ad-d813-4037-b5a8-d5d989c291a7

    Il est possible de les virer mais je ne détaillerai pas, de peur de rendre service à un logiciel propriétaire.

  • # Je vote pour

    Posté par  (site web personnel) . Évalué à 2.

    J'ai grâce à toi un compte gitlab maintenant!

    Quand-même je ne peux pas m'empêcher de faire la remarque qu'avant le : ce n'est pas une espace mais une espace insécable et qu'en ce qui me concerne j'ai toujours considéré que c'est le travail du logiciel que j'utilise de l'insérer:

    https://github.com/foretspaisibles/cadet/blob/master/locale/punctuation/fr.tex#L14

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.