Re: [EGD-discu] Chaînes de sortie

[Alexandre Garreau <galex-713@xxxxxxxxxxxx>]

Le 03/01/2019 à 19h27, Marcel a écrit :

Si sur le projet bépo, c’est devenu un marronnier, voire un épouvantail ou un serpent de mer, c’est peut-être parce que cela fait partie des problèmes insolubles du fait que la maqueette d’impression des touches a été figée avant que ce soit résolu.

Peut-être aussi que c’est parce que ça tient à cœur à certains, alors que pour d’autre, ça ressemble très fort à un maronnier parce qu’ils en voient ni l’utilité ni l’intérêt.

il implémente la méthode Dvorak au lieu de la méthode Colemak,

Faudra vraiment que j’entende quelqu’un d’autre que toi me confirmer tout ça sur colemak parce que pour moi en attendant colemak c’est juste un dvorak avec la contrainte supplémentaire de pas bouger certaines touches pour les raccourcis.

Donc permettez-moi de vite traiter les arguments d’Alexandre, au moins pour l’archive :

Youpi !

On 03/01/2019 16:33, Alexandre Garreau wrote:

Le problème est le suivant : c’est nécessaire pour pouvoir taper d’autres langues […], langages […], ou juste différemment […].

C’est souvent opposé, mais ce n’est plus valable depuis que je propose de ne pas toucher aux grandes ponctuations telles qu’elles sont sur le bépo, mais d’ajouter les chaînes de sortie sur des emplacements dont on peut se passer, si possible sur les mêmes touches.

Pour les raisons que je donne plus tard, ça me semble toujours stupide d’avoir une touche pour plusieurs caractères (on gère mal les raccourcis claviers avec ça (tiens, un argument pour un caractère « cʼh » unique dans unicode [0] : « et Ctrl+cʼh on le fait comment ? »)). Donc ça ça reste valable.

Par contre, n’importe quoi d’autre que l’accès direct ou le shift est juste trop peu ergonomique pour être plus intéressant que de taper directement le caractère et ensuite l’espace insécable, qui plus est vu qu’on a eu l’intelligence de mettre des caractères qui en ont besoin en shift, comme l’espace insécable. Idéalement, faudrait aussi les «» en shift (et <> en accès plus facile que altgr (direct ou sift), c’est ce que je fais quand je mets les chiffres en AltGr ou en accès direct (si seulement xkb proposait cette option partout ! comme une case à cocher dans la conf du clavier)), et idem pour le tiret long (sur quadratin).

Dans le cas extrême, ces chaînes pourraient aller en Maj+Altgr si elles sont jugées suffisamment intéressantes pour justifier l’appui sur AltGr en plus de Maj. Pour les guillemets, prendre les places des symboles ⩽⩾… Au point médian, une place en AltGr au lieu de Maj+AltGr irait bien, car cela irait dans le sens des personnes qui l’utilisent – et qui ont la modestie de se satisfaire d’une place en AltGr (contrairement à une initiative qui le voulait en direct). « Maj+AltGr » au contraire pourrait être ressenti comme une brimade pour un seul symbole relativement fréquent selon le style, tandis que ça passe pour une chaîne.

Sauf que « … » est fréquent aussi en fait, parfois plus, parfois moins, il est vrai, c’est une très bonne remarque, très pertinente. Mais ça n’a rien à voir avec quelque autre ponctuation que ce soit, et surtout ça ne libère absolument aucune place pour une telle.

D’ailleurs, le point médian est toujours considéré comme lourd pas certaines personnes, même ses plus éminent·e·s promotrices/eurs (ou, du coup, promot·rice·eur·s : vous voyez ? visuellement plus lourd, quoi que sémantiquement plus précis (et au final j’aime beaucoup, mais la plupart non, et surtout personne ne s’impose une telle exactitude, on trouve plutôt des raccourcis comme « promotrice·eurs » ou, pire, des horreurs comme « éminent·es » ><)). On y préfère souvent des mots épicènes ou des tournures différentes si pas trop lourdes. La position en Shift+AltGr peut être vue comme une façon de refléter ça (et, dans l’autre sens, « … » est vraiment très accessible pour quelque chose de justement aussi léger et discret par rapport à ce que c’est : mais là encore ça peut être vu dans les deux sens).

Et les gens n’apprennent généralement qu’un clavier, qu’ils ne configurent pas, ne paramétrisent pas, ne changent pas. Il faudrait que le clavier se « paramétrise » tout seul, en fonction de ce qu’on tape, donc du contexte (et que ce soit pas omniprésent, et configurable par l’utilisateur, avec des outils de haut niveau). La solution actuelle d’avoir les processeurs de texte qui font ça me semble bonne : en fait on considère le guillemet comme un raccourci clavier, et il insère le caractère associé avec sa bonne ponctuation.

Malheureusement non, car dans les processeurs de texte et même dans Publisher c’est l’espace insécable Latin-1 et rien d’autre. S’il y a quelque chose qui fait moche et fout la représentation informatique du français en l’air, c’est bien celle-là, d’abord parce qu’elle est justifiante sur le web, et puis parce qu’elle bugue depuis des décennies et n’est jamais déboguée. Laisser les utilisateurs à la merci de cette autocorrection-là n’est plus soutenable.

Là c’est la faute du logiciel. Mais le logiciel est mauvais. Une disposition clavier qui entre le bon espace insécable ne résoudrait absolument pas le problème : on aurait les deux, le bon et le mauvais, et au final ça justifierait toujours. Donc ça va pas.

Et au final c’est pas parce qu’une autre couche fait mal son travail que c’est à nous de coupler trop fort pour faire un travail qui n’est pas le notre pour corriger autrui parce qu’il est incompétant et que même nous nous en rendons compte.

En fait, c’est pas plus à nous de faire ça qu’aux concepteurs de police de foutre des espaces dans leur polices. D’ailleurs, ce serait même une meilleure solution en fait ! Au moins ça resterait un caractère unique, utilisable comme commande, raccourci clavier, etc.

Et là on me dirait « mais c’est un caractère utilisé dans plusieurs langues ! », et on pourrait, là encore, avoir des tas de solutions dont les plus sales seraient tristement les plus réalistes : ajouter un caractère à unicode pour les guillemets français avec espace (ya bien toute sorte d’emojis, les drapeaux, etc. !), ou plus propre mais trop complexe : changer l’affichage de la police (voire la police tout court) en fonction de la langue, de l’utilisateur, etc.

C’est sale, mais c’est une exagération qui montre encore mieux le problème de résoudre ça sur la mauvaise couche, et c’est tout à fait le genre de problèmes qui pourraient se rencontrer, comme les concepteurs de police et d’encodages sont parfois plus compétents et savants que ceux de claviers, eux-même plus que ceux de logiciels haut-niveau pour utilisateur final… parce qu’au final plus on va bas niveau plus c’est cultivé, et plus on va haut niveau… c’est un fait connu et triste.

Mais c’est pas une raison, c’est un boulot haut niveau, relatif à une sémantique haut niveau, à régler en haut niveau. C’est aux programmeurs de haut niveau de se cultiver et de devenir meilleurs, pas aux autres de tout rendre plus sale pour compenser leurs bourdes sous prétexte qu’ils en savent plus et qu’« ils peuvent ».

Le processeur de texte, normalement, est sémantique et sait ce qu’on tape, et on doit pouvoir configurer ce qu’on compose, et comment ça marche (c’est plus simple que de chercher le menu des petits modifs compose&cie du clavier dans GNU/Linux (ou Windows, ou ça existe juste pas)).

Ce qui marche bien, sous Windows, c’est de le faire par Clavier+ en mettant l’état de la bascule VerrDéfil comme condition, qui ne sert plus que dans les tableurs.

Ça c’est un bidouillage utilisateur, trop compliqué pour devenir un standard. Ça peut se promouvoir comme astuce à largement appliquer, et une fois largement répandue et utilisée ça pourra donner des idées.

Perso en attendant je trouve ça toujours désagréable.

En fait surtout, pour moi, niveau prog ce serait très chiant. Même dans emacs en général en fait : je peux déjà dire que « «» » sont des raccourcis clavier, et configurer comme je veux, avec l’idée de « une touche, une action, un comportement »… mais si c’est « «  » et «  » » (c’est compliqué hein ? :P la langue française et sa typographie n’a jamais prévu l’échappement x)), donc deux à chaque fois… là c’est compliqué : laquelle est un raccourci clavier, comment éviter le comportement de l’autre, faut-il l’annuler… c’est juste plus complexe : c’est la mauvaise couche, faut faire ça plus haut niveau.

C’est l’ancienne approche. Quand sur le projet bépo on étudiait l’espacement automatique, on partait du principe de le mettre aux endroits où se trouvent les guillemets. Mais pour le bépo ce n’est pas ce que je suggère de faire. J’ai été très précis dans mon message : les chaînes s’ajoutent en plus, pas à la place. C’est la 2ᵉ ou la 3ᵉ fois que j’évoque le sujet, à chaque fois je parle d’ajouter, à chaque fois on me dit de ne pas changer le comportement existant. Mais je ne propose pas que le bépo change l’existant, je propose que le bépo ajoute une fonctionnalité en plus, sur d’autre emplacements que celles où se trouvent les ponctuations en question, qui elles, resteraient inchangées…

Tu dois te faire plus explicite alors, dire un truc genre « sur altgr en plus du caractère seul ».

Et ça prend toujours un caractère de plus. Ya pas tellement de place libre hein, souvent ça en bougera un autre.