Re: [EGD-discu] [Vote] Touche morte + espace

[Marcel <bkn.ema@xxxxxxxxx>]

Dimanche 22 Janvier 2017 16:45:56, Flamme a écrit :
> 
> > Du fait que les caractères précomposés sont déjà super bien accessibles, les
> > utilisateurs garderont le réflexe de taper autant de caractères précomposés que
> > possible, et de ne recourir aux diacritiques combinants que quand ils n’ont pas
> > le choix.
> 
> Je me demande… Oui, pour 99% des cas… mais il y a les tapes 
> accidentelles, pas si rares,

Le fait d’être obligé de relâcher AltGr pour avoir le diacritique combinant, fait 
que les frappes accidentelles ont plus de chances de se terminer par un espaçant. Ou
serait-ce du même ordre que l’espace insécable faute d’avoir relâché Maj, ou VerrCap 
du fait de trop étirer l’auriculaire ? Les textes truffés de combinants erronés me 
font du souci quand ces combinants ont par erreur été choisis comme caractères morts 
lors du développement de la dispo. (Faut que je vérifie s’il en reste chez moi 
comme caractères intermédiaires des combinants par compose.) C’est aussi une raison 
pourquoi je trouve ISO/IEC 9995-11 pas bonne, car elle demande à utiliser des 
combinants comme caractères morts partout, alors que son algorithme n’est censé 
fonctionner que dans les applications où il a été implémenté. Comme fautes de frappe,
les combinants sont des erreurs insidieuses parce que souvent difficilement décelables.
Je ne comptais pas avec ce 1 % de cas…

> et puis tous ceux qui trouvent toujours un 
> moyen d’utiliser ce qui est facile d’accès pour un usage différent de ce 
> qui est prévu.

Ça dépend de savoir par qui c’est prévu. Par exemple, Unicode n’a pas prévu 
officiellement d’utiliser les exposants et indices en maths, pourtant c’est suggéré 
par (quasiment) Microsoft. C’est surtout le cas du symbole degré sur l’azerty pour 
simuler l’o et même l’e en exposant, et c’est pourquoi je propose d’avoir le vrai 
exposant e au même niveau sur la touche à côté, et l’abréviation nᵒ/Nᵒ en séquences.
A priori il ne faut pas empêcher les gens de faire ce qui leur semble utile si c’est 
juste de la saisie de texte.

> Et puis, je ne suis pas sûr que certains ne prennent pas 
> plaisir à vouloir cette méthode pour tout.

A priori cela se retournerait contre eux puisque ça gonfle le nombre de frappes. 
A priori encore, il ne faudrait pas leur mettre des bâtons dans les roues. Après, 
certes par exemple au Vietnam, les utilisateurs ont l’habitude de taper les 
diacritiques à la suite, mais ils utilisent des éditeurs d’entrée qui leur sortent 
du précomposé (à part ceux qui utilisent la disposition de clavier Windows pour le
vietnamien). 

> 
> > Dans ce sens, la stratégie des deux trois
> > caractères informatiques par {espace} et des combinants par {point} est totalement
> > ratée, car d’une elle complique la programmation, et de deux elle complique
> > l’écriture de nombreuses langues africaines, pourtant supportées au niveau des
> > lettres de base.
> 
> Je ne vois pas en quoi ça “complique” de mettre sur le point plutôt que 
> sur Espace. Est-ce seulement une question d’accessibilité (quoique le 
> point soit très accessible) ou y a-t-il quelque chose qui m’échappe ?

Ça charge l’index (gauche), là où le pouce (gauche) pourrait le faire, et les autres 
doigts gauches sont moins immédiatement disponibles pour la suite.

> 
> > Certes, si tous les pays du monde
> > concernés par les caractères latins composés avaient fait autant de lobbying que
> > le Vietnam, on pourrait peut-être aujourd’hui tout écrire en précomposés, si
> > vraiment il y avait assez de place,
> 
> En fait je pensais plutôt à l’autre solution. Tout faire avec du 
> combinant. Taper “é” sur le clavier n’aurait été qu’un raccourci pour 
> créer en interne un chaîne e + ´.

Ça aurait obligé Microsoft à mettre à jour les resssources système pour le clavier, donc 
ç’aurait été une bonne chose aussi de ce côté. Mais les concepteurs d’Unicode voulaient 
reprendre tous les encodages existants. Chaque caractère des jeux de caractères 
préexistants devait avoir un point de code dans Unicode, donc ils ont tout casé.

> Ainsi la gestion des chaînes eût été unifiée. Et les langages qui savent 
> gérer l’Unicode aurait directement implémenté des fonctions où 
> len("déjà") == 4, bien que tout soit fait avec des combinants.

On peut toujours le faire. Pour reprendre l’exemple des regex, \X représente 
un caractère espaçant suivi de n’importe quel nombre de caractères combinants. 
C’est quelque chose qui fonctionne déjà aussi dans Notepad++. Ça remplace l’unité 
quand la cible est une grappe de graphèmes¹ entière, pas juste une unité de code 
comme dans les regex traditionnelles (où “caractère” veut dire “unité de code”).

¹ J’appelle “grappe de graphèmes” ce qui en anglais se dit « grapheme cluster ».

> 
> >> La normalisation n’est qu’une rustine.
> >
> > Pourquoi ?
> 
> Parce que c’est juste pour là pour basculer d’une méthodologie à une 
> autre dans un système bicéphale.
> Parce que ça ne permet pas de combler tous les besoins.

Je comprends, en lisant la suite…
Le fait qu’il soit difficile de satisfaire tout le monde est une réalité bien 
connue. Pour le coup c’est une faible consolation, je comprends.

> 
> > Tout à fait, mais si la tâche consiste à travailler sur du français ou d’autres
> > langues européennes hors lituanien avec marques tonales, le problème est à la source
> > car ces langues ne sont pas censées être saisies avec des diacritiques combinants,
> 
> Mais, justement, certains, pas encore nombreux, se servent de ça pour 
> écrire en français. C’est en 2010 la première fois qu’on m’a contacté 
> pour me parler des combinants (je ne crois pas en avoir entendu parler 
> avant ça)

C’est très très courant comme cas de figure. La plupart des développeurs ne savent 
pas. Cela a même fait l’objet d’un fil sur la ML d’Unicode :
http://www.unicode.org/mail-arch/unicode-ml/y2015-m12/0073.html
Moi j’ai appris plus tard encore.

> qui posaient problème pour la reconnaissance orthographique 
> des mots écrits avec eux. Il a été facile de corriger le problème dans 
> le correcteur orthographique qui effectue en interne une conversion des 
> caractères combinés en précomposés.

En effet c’est disponible dans les langages, en JS c’est '.normalize()' 
ou '.normalize([NFC])' précédé du nom de la variable de la chaîne.

> 
> >> Notons par ailleurs que la normalisation ne résout pas tous les
> >> problèmes. La position d’un motif détecté par une expression régulière
> >> dans un texte normalisé ne correspond pas à la position de ce même motif
> >> dans le texte original. Autrement dit, même si on peut traiter le texte
> >> pour analyse, les résultats renvoyés ne correspondent pas au texte à
> >> traiter en ce qui concerne les positions.
> >
> > C’est sûr, mais est-ce vraiment important ? Je n’ai pas de cas pratique en tête,
> > j’imagine qu’il faut corriger le texte d’origine sans y toucher par ailleurs, alors
> > oui ça va être dur. Mais ça me semble un cas limite.
> 
> Je ne voulais pas rentrer dans le détail, mais puisqu’il le faut…
> 
> Je conçois Grammalecte, un correcteur grammatical (CG) pour LibreOffice. 
> En l’état des choses, je ne peux pas proposer une correction 
> grammaticale correcte si on écrit avec des caractères combinants.
> 
> Examinons pourquoi:
> Le CG, dans LibreOffice, n’est qu’un répondeur. LibreOffice lui fournit 
> du texte à examiner et attend en retour une liste d’erreurs contenant 
> chacune un message, une position, une longueur et éventuellement des 
> suggestions et une URL pointant sur des informations hors-ligne.
> Mettons que le texte qui parvient au CG contient des combinants. Si le 
> CG le normalise, les erreurs qu’il détectera ne seront pas placées 
> correctement, puisque la chaîne sera modifiée, attendu que cette 
> normalisation ne peut se faire qu’en interne (le CG ne peut que 
> suggérer, il n’a aucun droit de réécrire le texte du traitement de 
> texte). Pareillement, si la zone d’erreur contient des combinants, le CG 
> ne renverra pas la bonne longueur de texte à souligner. Autrement dit, 
> on peut trouver les erreurs, mais leurs position et longueur seront 
> inadéquates.
> Donc, normaliser, dans LO, ce n’est pas possible.
> — Solution 1: Réécrire complètement le CG. Il n’est même pas certain que 
> ça résoudrait tous les problèmes. Hors de question.
> — Solution 2: Réécrire toutes les regex, pour tenir compte des 
> combinants (ces regex sont parfois déjà bien compliquées). Envisageable, 
> mais pas le temps et vraiment pas motivé. C’est une usine à gaz.
> — Solution 3: désactiver localement le CG s’il détecte des combinants 
> dans un paragraphe. Envisageable, mais comment le signaler à 
> l’utilisateur? C’est quand même mieux que des signalements mal placés.
> — Solution 4: fournir un moyen de transformer en amont les caractères 
> combinés en précomposés via le formateur de texte (qui, lui, peut 
> modifier le texte écrit à sa guise). Envisageable, mais loin d’être 
> idéal, car ce n’est pas une solution automatisée et invisible.
> — Solution 5: il y a peut-être une solution intermédiaire, mais le 
> diable est dans les détails, je ne suis pas sûr que ça fonctionnerait, 
> il faudrait que je prenne le temps de m’y attarder. Comme ça m’ennuie, 
> je n’y pense guère. Quoi qu’il en soit, les combinants compliquent la vie.

En fait, c’est l’utilisateur de LO qui complique les choses.. Si toutes les langues 
supportées par le CG peuvent s’écrire sans combinants, on est en droit de demander 
à l’utilisateur de prendre ses dispositions. Donc solution 4 mais en tâche de fond,
comme il existe des programmes qui normalisent automatiquement le texte saisi dès 
que l’utilisateur le tape. Cela fait qu’en programmant des dispositions Keyman, il 
faut même prévoir ce cas de figure, est-il écrit dans la documentation.

> 
> Le problème se pose pareillement pour le CG en mode serveur. S’il reçoit 
> du texte avec des combinants et qu’on lui demande de rendre des erreurs 
> avec leur position, normaliser n’est pas possible. Les combinants 
> comptent dans la longueur des chaînes, on ne peut pas les substituer 
> comme ça sans modifier ces longueurs de chaînes. Il faut faire avec.

La solution est peut-être celle que tu as donnée plus haut, en créant une fonction 
'lengc()' qui autrement que 'len()' renvoie la longueur en prenant comme unités les 
“grappes de graphèmes” (grapheme cluster). LO doit bien sûr l’implémenter lui aussi, 
comme il intègre HarfBuzz (même si ce n’est pas la même chose). En fait c’est ça, 
« implémenter Unicode »: Avec les diacritiques combinants, ça n’a plus beaucoup de 
sens de compter les unités de code si c’est pour traiter du texte.

> 
> Voilà pour l’exemple où on ne peut pas normaliser juste pour se faire 
> plaisir. Je ne suis certainement pas le seul qui voit ces choses d’un 
> œil mauvais.

Je pense que pour positiver, on peut se dire qu’on est encore dans la phase 
d’implémentation d’Unicode, et une fois que tout sera en place, ça ira beaucoup mieux.
En attendant, se dire peut-être que c’est le prix à payer pour avoir un encodage 
plus facile qu’avant. 

Certes s’il n’y avait plus de précomposés, tout serait conçu d’emblée différemment, 
et on pourrait continuer d’exprimer les positions en unités de code.

> 
> > C’est vrai, je ne l’avais pas remarqué. Donc en fait le bépo tente de se racheter
> > de son esprit de rupture avec l’azerty en gardant des caractères informatiques
> > par 'touche morte, espace' (et les chiffres en Maj) ? Je pense surtout à beaucoup
> > de symboles qu’on aurait pu laisser, mais ça ne serait plus le bépo, ce serait
> > l’asertuniop’ ou quelque chose comme ça. Pour être vraiment le bépo, le bépo devrait
> > maintenant ergonomiser TOUS les caractères informatiques qui ne le sont pas encore.
> > Mais pas en les proposant par 'touche morte, espace'…
> 
> Je ne suis pas sûr de comprendre pleinement cette remarque. Je n’ai pas 
> forcément suivi toutes les conversations.

Je voulais dire que pour être ergonomique, le bépo doit fournir un accès convenable 
par touches vives à l’ensemble des caractères ASCII. À part ça je me dis que de 
nombreux caractères auraient pu être laissés sur leurs places azerty sans nuire 
à l’ergonomie, mais c’est peut-être une fausse impression, quoique, l’asertuniop’ 
utilise les places bien accessibles de la rangée des chiffres, comme le bépo 
d’ailleurs, mais différemment, et davantage :
http://bepo.fr/wiki/Utilisateur:Marcel/Version_2.0#Utilisation_de_la_rang.C3.A9e_des_chiffres

> En ce qui concerne les 
> caractères informatiques sur des positions moins favorables, les gens 
> sont très divisés… je ne vois pas comment remédier à ça.

Le principal motif de division provient de divergences dans la priorisation de 
l’utilisation des places bien accessibles encore paramétrables, sur la moitié 
droite sur la rangée de repos et celle au-dessus. L’option mainstream donne la 
priorité aux nouvelles touches mortes, tandis que l’option alternative que je 
peux proposer consiste à prioriser la touche morte Latin (qui devrait même pouvoir 
être symétrique) et les caractères informatiques laissés pour compte. Cela est basé 
sur deux constats :

1) La touche morte Exposant n’a pas besoin d’être bien accessible, car l’idéal 
réalisable est de pouvoir taper tous les exposants latins minuscules (les seuls à 
être vraiment utiles, à part les chiffres déjà bien accessibles par Circonflexe et 
Hatchek) par touches vives sur un niveau partiellement dédié. Sous Windows, ça peut 
être Maj + Num, tandis que sous macOS, on a vu que les touches mortes sont 
prorogeables, donc on peut créer une touche morte Exposant ponctuelle et une autre 
touche morte Exposant prorogée, à désactiver à la fin de la séquence en exposant.

2) La touche morte Scientifique concerne très très peu d’utilisateurs, certainement 
moins que la programmation. Donc elle peut monter d’un niveau, en Maj + AltGr, pour 
libérer une bonne place pour l’un des caractères informatiques laissés pour compte. 

> 
> > Ce qui est actuellement relégué dans des « coins obscurs », ce sont les caractères
> > informatiques proposés par 'touche morte, espace', le ^ et le `. Une fois qu’ils
> > seront sur des positions adaptées à leur usage, la position en accès direct sur
> > la barre d’espace sera libre pour éviter de reléguer les combinants de la barre
> > d’espace vers les touches point et virgule.
> 
> En ce qui me concerne, ce n’est pas du tout pour ces raisons que je ne 
> veux pas des combinants sur Espace. Ça n’a aucun rapport. Je suis opposé 
> à l’idée de trop faciliter leur accès intrinsèquement, indépendamment de 
> toute autre considération.

Fondamentalement, même si je comprends tes motifs, c’est une approche biaisée. 
À mon avis (qui peut être biaisé lui aussi), c’est un peu comme quand Unicode 
décrète que les exposants doivent être laissés aux experts, pendant que le commun 
des mortels doit s’embêter avec du formatage, souvent instable et mal adapté car 
trop haut, et n’avoir même pas le droit d’utiliser les exposants dans les brouillons.
Or, bonne nouvelle pour moi et certainement pour tout le monde, cette vision 
étriquée-là N’EST PAS celle de Microsoft, qui au contraire *prône* l’utilisation 
des exposants préformatés (au moins en ce qui concerne les chiffres).

Mais on était en train de parler d’autre chose.

> 
> >> alors qu’on voudrait juste avoir un Espace avec un comportement
> >> normal et mettre les combinants sur une place presque aussi correcte,
> >
> > Bien sûr que ce comportement est encore “normal”.
> 
> J’aurais dû écrire “usuel”, ou “attendu”, parce que connu.

Je ne sais pas pourquoi il serait souhaitable de continuer de suivre les dispositions 
de clavier héritées quand cela se retourne en fin de compte contre les utilisateurs.

Cdlt,
Marcel

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