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

[Marcel <bkn.ema@xxxxxxxxx>]

Effectivement je n’ai pas été clair sur certains points, ce qui s’ajoute aux
pertes “inévitables” lors de chaque transmission. Donc je commence déjà par 
rajouter ce que j’avais écrit au début et qui anticipe un peu les 
« prolègomènes » de Miltøn :

Lundi 25 Juillet 2016 15:21:33, Marcel a écrit :
>>>> Bien vu. Toutefois beaucoup d’entre ces points ont déjà été rejetés à un 
>>>> moment ou un autre pendant ces derniers mois, et j’ai juste repris en vrac.
>>>> 
>>>> Avec les points de Miltøn, quelques autres, et après un tri, cela nous 
>>>> donne ceci :

Puis je reprends la première récension de Miltøn, en ajoutant les commentaires
de Nicolas et les réponses de Miltøn :

Lundi 25 Juillet 2016 20:46:36, Valentin Melot [Miltøn] a écrit :
>>> 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…

Souvent cela se réduisait à dire « non » sans donner de raisons ou en invoquant 
la carte de base à n’y pas toucher. Que ceux qui disaient « non » dans le temps 
veuillent bien expliquer pourquoi, et en plus, il y a des chances pour qu’ils 
y portent un autre regard aujourd’hui que lors du premier contact avec l’idée.

Lundi 25 Juillet 2016 21:41:16, Nicolas Chartier a écrit :
>> [réponses deux fois indentées]

Lundi 25 Juillet 2016 23:13:15, Valentin Melot [Miltøn] a écrit :
> Merci pour cet avis ! :-) Je tronque un peu.

>>>> 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 ?
> C’est moins évident. Ne serait-ce que parce qu’on a très peu de
> caractères en indice. Où verrais-tu cette morte ?
Pour ma part je vois la touche morte Exposant sur Maj + AltGr + E, et
la touche morte Indice sur Maj + AltGr + I, parce que la touche morte
Monétaire est plus ergonomique en Compose + €, avec Compose en AltGr
sur la barre d’espace ; et que la touche morte Point en chef irait bien
sur Maj + AltGr + P (en plus d’être en Compose point), et le § à son tour
sur Maj + AltGr + S, et l’eszett en Tréma (comme tant d’autres lettres 
allemandes).

>>>> 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.
> Quel rapport avec l’espéranto ? Je m’étais posé la question de l’usage
> du schwa avant de suggérer (en janvier) qu’on le dégage, et il
> semblerait que ce soit un caractère qui ne sert qu’en azéri. En
> espéranto, on n’utilise que des consonnes circonflexes et le u bref.
Sur la carte API on a la même minuscule pour les deux, mais ça a déjà 
été discuté et admis sur la ML, je l’ai mis dans la liste pour que ce soit
plus complet et ne risque pas d’être oublié.
>> 
>> À 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.
Ou la solution en place sur le BÉPO2FM !

>>>> 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 ?
Un courant anglais l’utilise comme apostrophe anglaise.

>> 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))
> On en avait parlé avec Flavien, sans oser remettre ça sur la table
> puisque cela a déjà dû être débattu. Le plus gros problème semble
> être celui de la confusion qui pourrait avoir lieu entre ces caractères.
> J’ai pour ma part simplement permuté les deux apostrophes. Bien sur, si
> une majorité émerge pour mettre l’apostrophe typographique en accès
> direct, et trouver une position acceptable pour l’apostrophe droite, je
> soutiendrai ! :-)
L’apostrophe en accès direct, je l’ai oubliée, pardon. Bien sûr. Les deux.
Le guillemet simple informatique serait bien à la place de la parenthèse
ouvrante, et les parenthèses en AltGr sur S et R, les crochets sur D et L
malgré que ce ne soit pas sur la rangée de repos (cf. plus bas).

>>>> 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…
Si on prenait quand même la « meilleure idée de placement » qui se trouve
sur la page de discussion :
http://bepo.fr/wiki/Discussion:Version_1.0.1#Lettre_apostrophe_pour_le_breton.2C_okina_pour_les_langues_polyn.C3.A9sienneshttp://bepo.fr/wiki/Discussion:Version_1.0.1#Lettre_apostrophe_pour_le_breton.2C_okina_pour_les_langues_polyn.C3.A9siennes

>>>> 5. Ajout d’une émulation de pavé numérique, en convertissant la 105ᵉ
>>>> touche en modificatrice « Num » (une carte exemple est en ligne à
>>>> http://dispoclavier.com/index.html#a5) ;
>>> Cf. prolégomènes. J’ajouterais que plusieurs claviers que j’ai eus
>>> proposaient déjà cette solution avec la touche Fn, ne serait-ce pas
>>> redondant ?
Les deux solutions ne se recouvrent que partiellement, comme le montre la carte
exemple et comme il ressort du fait que c’est une « émulation », c’est-à-dire 
sans les keycodes du pavé numérique. Sur la carte exemple on voit bien plus de
caractères que sur un pavé numérique en couche Fonction. Et justement tous les
claviers n’ont pas ce pavé numérique en Fn, surtout pas les claviers de bureau,
mais aujourd’hui même beaucoup de claviers compacts, y compris sur netbook, ne
l’ont plus, probablement parce que sous Windows, il fallait toujours activer la
bascule VerrNum avant de pouvoir s’en servir de pavé numérique plutôt que de 
bloc directionnel bis. (cf. plus bas, mappage des autres niveaux du pavé numérique)

>>>> 6. Ajout de la majuscule de l’ɪ avec empattements (Unicode 10.0) ;
>>> En API+maj+I ?
>> Euh, ça sert à quoi ce symbole ?
Pour un certain nombre de langues africaines notamment.
Oui, en API + Maj + I. U+A7AE.

>>>> 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.
> Il faudrait voir la fréquence d’usage du S long. Le latin+R, je ne comprends
> pas la cohérence… :|
Ou sur Maj + AltGr + L, et le © sur Maj + AltGr + R, ou pourquoi ne pas le virer
de la carte pour bien faire ? Les symboles de marques dans le Compose de la dispo,
et tous les symboles d’auteur aussi.

>>>> 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…
Oui.

>>>> 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 ?
À la place de la parenthèse fermante. En plus, comme ça, il est sera à côté de
l’arobase.

>> 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.
C’est pas bête ça. Je n’y pensais pas mais c’est très bien. Raison de plus
de mettre le croisillon en accès direct sur le BÉPO2FM.

>> Et autant je ne touche pas à PHP, autant je fais régulièrement du
>> shell, et le $ via shift ne me gène pas.
En mode Programmeur je l’ai en Shift moi aussi, en plus de l’avoir en Pro
(touche AltGr) tout le temps.

>>>> 10. Ajout des espaces insécables intégrées aux ponctuations hautes
>>>> doublées à cet effet, surtout avec espace fine insécable.
>>> Déjà discuté, il me semble…
Discuté et rejeté ! Pourquoi ? À cause des points de suspension et des choses
comme ça. Les ponctuations tournées de l’espagnol sont très bien aussi en 
Tilde, un peu comme l’eszett en Tréma. Le bépo grille ainsi pas mal de places
pour des trucs rares ou pas français, pendant qu’on continue d’envoyer se
promener les ponctuations hautes, que ce soit par mail, sur Twitter, ou ailleurs 
sur le web quand on écrit dans un formulaire ou dans une appli qui n’est pas un
traitement de texte ou autrement solidement codée. Solution : espace fine insécable.
Mais pas en Maj d’espace, sinon elle sera utilisée en guise d’espace insécable
classique, qui dans les traitements de texte perturbe déjà la mise en page du fait
de son comportement non standard.

>>>> 11. Ergonomisation des parenthèses et crochets en les plaçant tous les 4
>>>> en AltGr sur la rangée de repos, ainsi que les chevrons < et > ;
>>> Cela nuirait gravement à l’accessibilité de caractères français (æ, ù,
>>> virgule, €), de touches mortes fondamentales (tréma, latin étendu) ou
>>> importantes (tilde, qui sert à deux langues très parlées en France, à
>>> savoir le portugais et l’espagnol), de l’eszett allemand ou du s long
>>> (celui-ci étant, je le reconnais, moins important). Est-ce vraiment
>>> nécessaire ?
Oui pour gagner leurs places, mais à la base surtout pour les avoir de manière 
plus ergonomique. Car elles servent en français, contrairement au latin étendu
et tout. Mais c’est vrai que je trouve difficilement plus de deux places dans
la rangée de repos à donner aux parenthèses, crochets et accolades. Ces
dernières sont déjà bien placées sur le bépo il me semble, mais pas les crochets.
La touche morte Latin étendu ou Groupe tertiaire/quaternaire, je la mettrais
en AltGr + V, et la touche morte Háček en double frappe de la touche morte
Circonflexe, et aussi en Compose >.
Mais ce n’est pas encore très clair pour moi non plus… J’avais prévenu !

>>>> 12. Mise en accès direct des touches mortes accent aigu et accent grave
>>>> sur les emplacements libérés des parenthèses (solution imaginée pour
>>>> le bépo pour pallier le manque de touches mortes en accès direct à
>>>> côté du circonflexe) ;
>>> Voir remarque sur le point précédent, du coup.
Du coup je laisse tomber, car j’y mettrais ' et # (cf. 3. et 9.).

>>>> 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 » ?
Avec la lettre apostrophe en Maj de l’apostrophe (typographique) ça peut aller.
Mais il faudrait l’y mettre.

>> Ici, non, mais j’ai le h à gauche :)
Le clavier breton a le cʼh sur [Q] il me semble.
Le mettre sur le bépo est un geste de soutien au breton.

>>>> 14. Ajout de l’espace insécable justifiante pour les traitements de
>>>> texte, c’est-à-dire de la séquence U+2060 U+0020 U+2060 ;
>>> J’ai perdu le fil de ces questions sur les espaces. La question est :
>>> sachant qu’il faut, idéalement, une espace fine insécable avant les
>>> ponctuations doubles, où devrait-on utiliser des insécables non
>>> justifiantes, et où devrait-on insérer des insécables justifiantes ?
L’espace insécable classique est non justifiante dans les traitements de texte.
Cela ne se justifie ^^ que par leur emploi abusif avec les ponctuations hautes.
Comme on y met des fines, l’espace insécable des traitements de texte est encore
utile dans les noms de lieux en « Saint » écrits à l’allemande : St. Petersburg.
(Sachant que Firefox va me virer l’EIC, je mets une EFI.) Ailleurs, dans les noms
de personnes et tout ce qui ne doit pas être coupé à l’espace, il faut une espace
insécable justifiante. Selon Unicode (qui spécifie que l’EIC est justifiante),
tout caractère peut être rendu insécable par le fait d’être entouré de gluons.

Dans LibreOffice/OpenOffice, pas de problème, le gluon standard U+2060 s’affiche
même avec la trame de champ, comme une EIC mais sans chasse. Seul Word, au moins
dans ses anciennes versions, ne supporte pas le gluon et continue de fonctionner
avec l’espace insécable sans chasse U+FEFF. Donc normalement il faut prévoir les
deux, mais avec une moindre accessibilité pour la variante rétrocompatible (qui
ne fonctionne plus dans LibreOffice).

>>>> 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 :
[…]
>> 
>>> * 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.
>> 
Dans les cas où il n’existe pas de caractère précomposé, le comportement standard
est de sortir le caractère de base suivi du diacritique combinant. Mais c’est 
impossible avec un driver de dispo au format Windows.
D’où d’ailleurs ISO/IEC 9995-11.

>>> * 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.
>> 
Oui c’est mort pour deux raisons principales : Le manque d’implémentation
d’Unicode et le faible support des classes d’équivalence dans les algorithmes
de recherche ; la recommandation du W3C d’utiliser les caractères précomposés.
Cette dernière étant sans doute liée à la première.. Quand on voit dans une 
page web une lettre avec un accent qui semble s’envoler, on sait qu’on est en
face d’une séquence lettre de base + diacritique combinant. Ce n’est pas
normal, mais c’est comme ça, malheureusement.

Par contre, Unicode a cessé d’encoder de ces lettres précomposées. Ainsi 
les Lituaniens et les Maliens et bien d’autres sont obligés de recourir aux
séquences lettre + diacritique(s). En Lituanie il paraît qu’on utilise, pour
écrire le lituanien accentué (qui représente ~1 % en termes d’usage), on 
utilise semble-t-il de éditeurs d’entrée, avec les diacritiques espaçants de 
la troisième dispo lituanienne sous Windows. Au Mali on voudrait bien tout
entrer par touches mortes, mais en pratique on utilise des dispos avec les 
diacritiques combinants en touches vives, pour toutes les lettres, par souci 
d’homogénéité.

Sur le bépo on peut mettre les diacritiques combinants en touches vives grâce
à la modificatrice Num (touche B00) + AltGr, mais alors sur des touches à droite.
Perso je les ai sur les mêmes touches que les touches mortes plus une. 
Aigu, grave, circonflexe, tilde, macron et háček. Suscrits et souscrits.
Mais attention sur la page dispoclavier le prototype les a seulement en Ctrl + Alt.
Je vais les doubler en Num + Pro, car c’est plus ergonomique et c’est plus portable.

>>> * 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é).
>> 
Circonflexe donne tout d’abord ^ ou ˆ. C’est très simple :
Circonflexe EIC donne ^ ; Circonflexe EFI donne ˆ. Or ^ est sur touche vives,
et l’EFI est en Num + Espace car il sert de séparateur de milliers français.
Avec juste Espace par contre, il faut qu’on ait le diacritique combinant,
comme sur le clavier US-CUSTOM pour Mac : http://uscustom.sourceforge.net

Pour la lettre modificative circonflexe souscrit U+A788 ꞈ j’utilise surtout 
Compose ç suivi de deux fois touche morte Circonflexe.
« Compose ç » est chez moi la séquence compose des diacritiques souscrits.
Peut-être en voyez-vous une meilleure…

>> 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 ?
>> 
Si c’est pour un diacritique combinant, oui à mon avis. Mais encore une fois,
les diacritiques combinants ne sont normalement pas en Compose espace insécable.
À la limite c’est « has been ». Maintenant qu’on a Unicode, ce n’est plus adapté.

>> Beaucoup de soucis pour si peu…
> OK, j’ignorais que l’équivalence Unicode déconnait à ce point (je
> pensais que les caractères devaient être traités exactement de la même
> façon), et je n’avais pas pensé à certains des problèmes que tu pointes.
Moi non plus, à ce point-là !

> Cela me va très bien si l’on ne change rien ! :)
>>> 
¿\o/?!!!!!:⌇

>>>> 16. Mise en touches mortes des guillemets-virgules (8 en tout) ;
>>> Ceux utilisés par les langues qui nous intéressent sont tous sur la
>>> couche de base, me semble-t-il… :)
>>> 
Oui mais ce n’est pas très productif. Avec accent aigu et accent grave en touche
morte accès direct, on les génère avec les guillemets informatiques, et on les
complète au passage car il y a aussi ‟ et ‛, utilisés en PAO dans certaines 
circonstances graphiques, pour relever une citation par exemple, car c’est 
plus joli. Donc on peut mettre les allemands en Tréma, et les réfléchis en Tilde
ou autre.

>>>> 17. Remplacement de la touche morte Latin étendu et ponctuation étendue
>>>> par une touche morte Sélecteur de groupe ISO/IEC 9995, si possible
>>>> symétrique (double appui donne accès au groupe prochain) ;
>>> Déjà discuté, non ?
>>> 
Juste écrire « pas ça » ou quelque chose du genre n’est pas « discuter ».
Qu’est-ce qui n’est pas bon dans le concept ? En plus cela fait partie d’une
norme internationale boudée par Microsoft et implémentée à la lettre sous Linux, 
d’après ce que j’ai pu voir. Donc de quoi plaire au bépo et au BÉPO2FM.

>>>> 18. Ajout d’une émulation compose, si possible en AltGr d’espace
>>>> (puisque le tiret bas n’y fonctionne pas toujours) ;
>>> Cf. prolégomènes.
>>> 
Cf. mon commentaire.

>>>> 19. Mise en compose des symboles inférieur/supérieur ou égal, afin que
>>>> le style français et le style anglais soient également accessibles,
>>>> par exemple Compose < < pour ⩽, Compose < _ pour ≤ (sachant que pour
>>>> ≪ et ⋘ on peut prendre Compose < 2 et Compose < 3) ;
>>> Lié au point 18.
>>> 
>>>> 20. Ajout de la bascule Pro (Kana) pour un mode Programmeur (si possible
>>>> sur la touche E00 = $#) avec en accès direct : les chiffres, les
>>>> guillemets informatiques simple et double, les deux tirets
>>>> informatiques, l’arobase, le point, la virgule, le point-virgule et
>>>> le deux-points ;
>>> Cf. prolégomènes.
>>> 
>>>> 21. Ajout d’une modificatrice supplémentaire sur chacune des deux
>>>> bascules pour générer le grec et le cyrillique sans être obligé de
>>>> passer par les touches mortes (grec polytonique par touches mortes
>>>> chaînées) ;
>>> Idem 17, déjà discuté si je ne m’abuse.
>>> 
C’était quoi déjà le problème avec l’ajout de modificatrices sur les bascules ?
Je ne me souviens plus. 
Quelqu’un pour nous rafraîchir la mémoire ?

>>>> 22. Remplacement d’AltGr par Kana ;
>>> Cf. prolégomènes.
>>> 
Cf. aussi http://bepo.fr/wiki/Utilisateur:LeBret/Remplacer_AltGr_par_Kana
Mais ce problème est propre à Windows. Et Kana est insensible à VerrCap. 
Or j’aurais suggéré aussi de mettre l’Œ et l’Æ en accès direct, et l’Ù aussi,
cf. http://bepo.fr/wiki/Utilisateur:Kaze/B%C3%A9po-saymal

>>>> 23. Déplacement des chiffres au niveau Kana basculables en accès direct ;
>>> Cf. prolégomènes
>>> 
Cf. https://twitter.com/PhM_Norma/status/738037706912092161

>>>> 24. Ajout des caractères latins manquants (liste complète avec séquences
>>>> compose à venir de ma part si intérêt) ;
>>> Si on peut compléter, alors ne nous privons pas.
>>> 
>>>> 25. Ajout de caractères aux autres niveaux du pavé numérique physique,
>>>> principalement les lettres hex, les opérateurs typo, et des
>>>> séquences comme « 00 », « 000 », « U+ », « \u », « 0x », « &#x » (et
>>>> le point-virgule) ;
>>> Cf. prolégomènes.
>>> 
Là j’ai peut-être un trou de mémoire, je ne me souviens pas quand ça a été discuté.
Cela ne touche même pas à la carte de base. Est-ce que tu pourrais nous expliquer
où est le problème dans la complétion du pavé numérique ? 

>>>> 26. Ajout des séquences pour les entités HTML de l’EFI et de l’EIC.
>>> Cf. prolégomènes.
>>> 
J’utilise surtout celle pour l’EIC, à cause de l’instabilité du caractère Unicode
U+00A0. Certes on peut les avoir par un raccourci Clavier+. Mais tant qu’à faire,
ajoutons-les sur le bépo, peut-être en Num + quelque chose. Perso je les ai en 
Ctrl + Alt + , (EIC) et Ctrl + Alt + . (EFI).

>>> Voilà ! :)
>>> 
>>> -- 
>>> Miltøn
>>> 
>>>> 
>>>> Liste non exhaustive ; n’hésitez pas à ajouter vos desiderata.
Cela est toujours valable.
>>>> 
>>>> Pour Windows j’espère pouvoir m’en occuper en adaptant mes fichiers
>>>> quand ils seront finis (ou avant).
>>>> 
Parce qu’il me paraît plus faisable de fusionner le BÉPO2FM dans l’asertuniop’
que l’inverse. Mais il vaut peut-être mieux quand même de partir du BÉPO2FM 
et d’y implémenter les fonctionnalités retenues. Ça dépend surtout du nombre de
celles-ci, donc des résultats de votes. Mais dans l’idéal pas avant d’avoir 
vraiment discuté — et, bon, testé bien sûr. J’essaie de m’en occuper en temps 
utile.
>>> 

Bonnes vacances à tou·te·s !

Marcel

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