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

[Marcel <bkn.ema@xxxxxxxxx>]

On 03/01/2019 20:18, Alexandre Garreau wrote:
> 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.
Certainement peu nombreux ceux-là, ici où des sacrifices sont consentis pour avoir la synergie de 4 ponctuations avec l’espace insécable puis l’espace fine insécable de la barre, posant au passage un challenge tant aux francisants qu’aux programmeurs (parce qu’elle est en Shift+<SPCE>).
>     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.
Ce n’est qu’une partie de la différence, mais par rapport au bépo ce point va certainement être l’essentiel, en plus du seuil de conversion trop élevé qui a conduit au moins un contributeur à proposer un rapprochement azerty–bépo.

Sinon, inutile d’attendre, le site du Colemak est très fourni. Pour commencer :
https://colemak.com/FAQ#Is_it_worth_switching_from_Dvorak_to_Colemak.3F
>     Donc permettez-moi de vite traiter les arguments d’Alexandre, au moins pour l’archive :
>
> Youpi !
Non. L’idée est que ça vaille décharge pour moi. Autrement je me sentirais traître et félon.
>     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.
Non, c’est plutôt bidon comme argument, car même avec XKB (Linux, ChromeOS) on peut disposer les niveaux Ctrl et ça rend les raccourcis indépendants des caractères graphiques, exactement comme sous macOS, et un peu comme sous Windows (où les raccourcis reposent sur les codes virtuels des touches).
Perso j’ai une dispo en qzjfgy/asertuniop’ où les raccourcis sont en azerty. Sauf que ça occupe 2 éléments sur 8, donc je ne m’en sers pas mais pour le bépo, qui n’utilise que 4 éléments par touche, ça marchera nickel.
> 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.
Pourtant quelqu’un a dit ici sur la ML que pour lui, taper l’espace à part est trop compliqué, même quand les deux sont au même niveau.

Trop peu ergonomique l’AltGr ? En tout cas personne ne se plaint de la “mauvaise” accessibilité des tirets, des [], des {}, de l’€…
> 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).
 Exact. C’est ce que je fais qui ai les chiffres en AltGr, ou en accès direct quand ils sont verrouillés, ou en pavé en synergie avec l’espace fine insécable (= le seul séparateur des triades français qui fonctionne).
>     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.
+1, les points de suspension en AltGr je ne propose pas de les changer de niveau, mais bien de les mettre en synergie avec les crochets dont ils sont si souvent entourés. Sur le bépo c’est l’une des pires suites, les mêmes doigts font un aller-retour entre le haut et le bas du clavier. Aurait fallu les mettre à la place du ^ en AltGr+6, quitte à simplement permuter les deux ! Le résultat aurait l’air pas mal : []… en haut, /\{}^~ en bas. Du coup, le ^ est recasé mieux. Mais on parlait d’autre chose…
> 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
Ce n’est pas notre rôle. S’il est certes bon d’avoir un avis à titre personnel, les développeurs de dispositions de clavier n’ont pas vocation à se poser en prescripteurs en matière d’écriture inclusive. Le point médian en Shift+AltGr, c’est justement ce dont je vous propose de voir le côté indécent aux yeux d’une partie des personnes utilisatrices…
> (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).
C’est oublier – il faut bien le souligner – que les « … » s’accompagnent souvent de « [] » pour marquer les coupures et omissions « […] » dans les citations.
Une autre solution serait de permuter crochets et accolades : /\[]…~ en bas, {}^ en haut. Deux solutions au choix, ça met à l’aise…
Sauf que — la carte simplifiée ! argh…
>         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.
Le pack d’autocorrections linguistiques de Word, il faut bien sûr le désactiver, comme le font déjà toutes les personnes utilisant le bépo, j’imagine… Que la chaîne espace–ponctuation soit manuelle ou automatique ne change rien pour le logiciel.
> 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.
Facile de taper sur les autres. C’est que ce n’est justement PAS leur travail ! Demander à tous les développeurs d’interfaces de saisie de texte de nous courir derrière parce que nous refusons de nous mettre en état de taper notre langue sur un clavier adapté, je pense que c’est juste…

Le projet bépo, ayant compris cela, a introduit une synergie. Dans la droite ligne, je propose de continuer la route et d’aller de l’avant.
> 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.
Bonjour les boucs émissaires… je vous plains.
> 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.
OK, la seule solution pour balayer le sujet de la table, c’est d’écrire n’importe quoi ?

Les drapeaux des pays sont tous codés à l’aide des 26 indicateurs régionaux. Notre tricolore : "🇫🇷".
C’est même écrit noir sur blanc dans les Code Charts :
https://www.unicode.org/charts/PDF/U1F100.pdf#page=6
« Regional indicator symbols
These characters can be used in pairs to represent regional codes. In some emoji implementations, certain pairs may be recognized and displayed by alternate means; for instance, an implementation might recognize F + R and display this combination with a symbol representing the flag of France.
[…]
1F1EB    REGIONAL INDICATOR SYMBOL LETTER F
[…]
1F1F7    REGIONAL INDICATOR SYMBOL LETTER R
[…] »

Pas folle la guêpe…
> 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 ».
Non, la représentation informatique interopérable de la langue française n’est pas « un boulot haut niveau », c’est proprement aux développeurs de dispositions de clavier de l’assurer en permettant d’écrire directement en français correct, partout, sans les obliger à toujours courir les béquilles, les hacks, les éditeurs d’entrée ou la postproduction.

Dire que c’est « un boulot haut niveau », c’est verser de l’eau sur les moulins de l’industrie, qui veut justement que personne ne puisse avoir de textes utilisables ailleurs que dans les logiciels PAO haut de gamme. Avec le français ils ont moyen de réussir leur coup, à cause de nos exigences et de notre typographie de haut vol. Or il y a moyen de rendre cette dernière accessible à tout le monde, et ce moyen c’est l’espace fine insécable. C’est la raison pour laquelle le caractère qui aurait dû servir comme telle n’a pas été rendu insécable au début d’Unicode. C’est l’espace ponctuation U+2008, alors que sa sœur l’espace tabulaire U+2007 est bien insécable ! Même histoire avec les indicateurs ordinaux des langues d’un tiers de l’humanité. Il a dû y avoir quelques voyous qui savaient exactement ce qu’il faut faire pour mettre le désordre afin de maximiser les profits de leurs employeurs.

De concert avec le projet bépo, je propose que nous cessions de nous poser en brebis à tondre et en vaches à traire pour les industriels de la PAO. Leurs logiciels présentent suffisamment d’intérêt pour que ces sociétés n’aient pas besoin de gagner quelques dollars de plus aux dépens de la représentation écrite de notre langue.
>         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.
Je suis totalement d’accord. Ce n’est pas vraiment le rôle de Clavier+.
>         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 ».
Merci, c’est noté.
> Et ça prend toujours un caractère de plus. Ya pas tellement de place libre hein, souvent ça en bougera un autre.
Sûr.

Mais à mon avis ça vaut la peine, et je trouve même que c’est très important, au vu de tout ce qui a été écrit dans ce fil.

--
Cordialement,

Marcel
--
Courrielleur : Thunderbird 52.9.1 sous Ubuntu 16.04 Xenial Xerus

--
Pour ne plus recevoir les messages de cette liste de discussion, envoyez un courriel avec pour destinataire discussions-REQUEST@xxxxxxxxxxx et pour sujet "unsubscribe".