Re: [EGD-discu] Détails à régler sur BÉPO2FM

[Nicolas Chartier <chartier.n@xxxxxxx>]

On Mon, 25 Jul 2016 20:46:36 +0200
Valentin Melot <v.melot@xxxxxxxxxx> wrote:

> Hello, mes réponses pour certains points sont dans le corps du mail.
> En guise de prolégomènes, je signale que certains changements
> (notamment l’idée de faire un clavier trimodal, de créer des touches
> modificatrices Num, PRO ou Kana, etc.) ont déjà été looooonguement
> débattues entre janvier et juin et ne sont pas consensuelles, donc je
> ne pense pas qu’il soit nécessaire de rererevenir dessus…
> 
> >  1. Ajout des lettres en exposant, avec une touche morte
> > Exposant ;  
> Favorable, reste à choisir où (il y a de la place, et les touches
> mortes que nous avons déjà créées avec Flavien peuvent encore être
> discutées).

Favorable, ça me parait plus cohérent qu’une tambouille pas du tout
mnémotechnique avec altgr, qui en plus ne couvrirait pas tous les
symboles.
Euh, en passant, on a le même problème avec les indices, non ?

> >  2. Désunification des minuscules du schwa et de l’e tourné ;  

J’ai pas compris.

Je remarque d’ailleurs que sur le 2FM le schwa a disparu de la carte au
profit de la touche morte API.
Vu que le ə sert en API, il y est, mais par contre c’est pas terrible
pour les espérantistes.

À mon avis c’est un point à corriger, par exemple :
- en laissant la touche morte API sur {z},
- en déplaçant les symboles en {h} ailleurs (touche morte
  ponctuations ?)
- en mettant les ə et Ə en {h}.
Ou alors :
- en remettant əƏ sur {z},
- en déplaçant les symboles en {h} ailleurs,
- en mettant la touche morte API sur {h}
Ou autre.

> >  3. Ajout de la lettre-apostrophe en touche vive ;  
> Sur la couche de base, tu veux dire ? Est-ce vraiment justifié, eu
> égard de l’usage de ce caractère ? Je crois que le breton est la
> seule langue concernée, me trompé-je ?

Quitte à jouer avec les apostrophes, j’aurais commencer par mettre ’ en
accès direct…
Ce projet à parfois des priorités bizarres je trouve :)

J’ai tendance à penser que c’est le symbole qui a le pire ratio
fréquence d’utilisation / facilité d’accès.
(sur le bépo officiel hein, moi je l’ai en direct…)
((j’ai aussi le ' en direct, soit dit en passant, mais j’ai pas de
touche ê inutile))

> >  4. Ajout de l’okina en touche morte (cf. page de discussion de la
> >     version 1.0.1) ;  
> Elle est pour l’instant en latin étendu+AltGr+Maj+apostrophe.. C’est
> peu accessible effectivement, mais l’usage est rare. Une meilleure
> idée de placement ?

Elle est présente, et c’est déjà pas mal diront certains, mais c’est
vrai que touche morte puis altgr-maj ça pique un peu oui…

> >  6. Ajout de la majuscule de l’ɪ avec empattements (Unicode
> > 10.0) ;  
> En API+maj+I ?

Euh, ça sert à quoi ce symbole ?

> >  7. Ajout du symbole copyleft (Unicode 10.0) ;  
> Favorable sans réserve. Mais où ? Mon cœur irait vers une place sur la
> couche de base, mais mon esprit se demande si c’est raisonnable.

latin + r ?
Ou alors on vire le ſ de la carte de base et on y laisse une place pour
le copyleft.

> >  8. Ajout du bitcoin (Unicode 10.0) [sans que cela n’exprime aucune
> >     opinion personnelle] ;  
> +1, on en avait déjà parlé, je ne sais plus quelle position avait été
> choisie. Je crois currency+B, avec des permutations…

Si y’a de la place, pourquoi pas…

> >  9. Mise en accès direct du croisillon/carré (le « dièse » des
> > claviers téléphoniques) pour les mots-clés sur Twitter ;  
> Où le mettrais-tu ?

C’est un point que j’ai déjà chez moi, j’ai simplement inversé # et $

Utilisation du # :
- symbole de numéro (mais plus rare que n°)
- hash tag
- languages informatiques (C/C++/C#, Python, Perl, Ruby, Bash, CSS)

Utilisation du $ :
- unité monétaire
- languages informatiques (PHP, JS, Perl, Ruby, Bash, moteurs de
  template, maven, TeX)

État actuel : $ en direct, # via shift

Pour ma part j’ai inversé les deux pour pouvoir enchaîner les frappes
successives de # sur des lignes consécutives pour commenter rapidement
un bout de shell.
Et autant je ne touche pas à PHP, autant je fais régulièrement du
shell, et le $ via shift ne me gène pas.

> > 13. Ajout des séquences cʼh, Cʼh, CʼH ;  
> Je crois que le principe retenu est « une touche égale un point
> Unicode », même si je reconnais que cela améliorerait grandement la
> saisie du breton.

C’est si compliqué que ça de taper « c’h » ?
Ici, non, mais j’ai le h à gauche :)


> > 15. Ajout des principaux diacritiques combinants en touches vives,
> >     niveau AltGr ou Ctrl + Alt (assurer la portabilité sous les OS
> >     autres que Windows) ;  
> Je saisis l’idée, mais c’est très coûteux en place. Je vois trois
> autres options envisageables :

Attention, ça va chier.

>  * Première solution : si l’utilisateur frappe une touche morte
> correspondant à une diacritique [D] puis une touche [T], soit une
> combinaison [D]+[T] existe dans le Compose et on la met, soit il n’en
> existe pas et on insère la combinante correspondant à D suivi du
> caractère normalement donné par T. Problème : cela complique les
> successions de touches mortes et je ne sais pas si on peut faire ça
> facilement dans le Compose.

Je suis pas sûr de comprendre…
D + T qui existe dans compose, je vois, admettons l’exemple ^ + e, ça
va donner ê. Jusqu’ici tout va bien.
Mais si ça n’existe pas, tu vas taper D puis T, ça n’existe pas et donc
tu voudrais que ça produise à la fois le D combinant, qui va donc se
placer sur la lettre précédente, puis T ?

Ça veut dire que « e + ^ + e » = « eê »
Ainsi que « e + ^ + c » = « eĉ »
Mais que « e + ^ + t » = « êt » ?
Je sais même pas si c’est possible de l’implémenter (avec Compose ou
avec n’importe quel autre système), sans même aller parler de
l’enchaînement des touches mortes.

>  * Deuxième solution : profiter totalement de l’équivalence canonique
> Unicode et transformer toutes les touches mortes correspondant à des
> diacritiques en vives correspondant aux combinantes : dans le XKB, [^]
> ne donnerait par exemple plus dead_circumflex mais U+0302 (combining
> circumflex, hat). On s’autorise toujours à conserver des successions
> non standard dans le compose, par exemple en remplaçant la règle
> dead_circumflex + 1 = ¹ par U0302 + 1 = ¹.

Équivalence canonique Unicode ?

Tu veux dire le truc qui fait qu’un symbole qui ressemble à un ê
parce que taper via « ^ + e » ne sera pas trouver via recherche du
symbole qui ressemble à un ê parce que taper via « e + ^
combinant » ? :)

Parce que, non, ça ne marche pas.

Par exemple, si je vais sur la page
https://fr.wiktionary.org/wiki/prol%C3%A9gom%C3%A8nes (on se demande
pourquoi), qui contient 4 ê, et que je cherche ê (combinant), j’ai 0
réponse.

Donc cette proposition me semble morte d’avance, parce qu’il me parait
hors de question de modifier le comportement des combinants.
Parce que les combinants ne sont pas gérés par compose, si on surcharge
le comportement des combinants, ils deviennent de simple touches
mortes, et ne seront plus combinants…

Accessoirement, tu fais comment un « t̂¹ » ? tu tapes « t ^ ^ 1 » ?

Bref, on ne peut pas avoir une même touche qui fait deux choses
différentes (mort & combinant) suivant le contexte.

>  * Troisième solution : changer la façon d’accéder au caractère
> correspondant aux diacritiques. Aujourd’hui, pour obtenir la lettre
> modificatrice correspondant à une diacritique (par exemple ¨, ^ ou `),
> on a deux options : faire la morte en double, ou bien suivre la morte
> d’une espace. Pour ma part, j’ai toujours utilisé la première
> solution, mais je ne sais pas si je suis représentatif. Peut-être
> pourrait-on ne conserver qu’une de ces deux solutions, et faire en
> sorte que l’autre donne la combinante, aujourd’hui reléguée en
> morte+AltGr+espace ? Inconvénient : pour les touches mortes qui
> donnent plusieurs lettres modificatrices possibles (par exemple,
> circonflexe qui donne ^ ou ̭  cela devient compliqué).

Vu l’usage, je vois pas trop l’intérêt de changer l’existant…
C’est si compliqué que ça de faire ^ + espace insécable ?

Beaucoup de soucis pour si peu…

-- 
Nicolas

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