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

[ Thread Index | Date Index | More ergodis.org/discussions Archives ]


----- Mail original -----
> De: "Valentin Melot" <v.melot@xxxxxxxxxx>
> À: discussions@xxxxxxxxxxx
> Envoyé: Lundi 25 Juillet 2016 23:13:15
> Objet: Re: [EGD-discu] Détails à régler sur BÉPO2FM
> 
> Merci pour cet avis ! :-) Je tronque un peu.

Tu fais bien, parce que moi au contraire, j’en rajoute… :)

> >>>  1. Ajout des lettres en exposant, avec une touche morte
> >>> Exposant ;
> > 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 ?

Alors là j’ai une idée, mais elle pique un peu beaucoup suivant jusqu’où on la pousse.

On a pour habitude de faire qu’une touche morte doublée produise le symbole correspondant à la diacritique.
Par exemple : dead-^ + dead-^ = ^
Même comportement si on met une espace simple en 2e.

Est-il nécessaire de garder ce principe partout ? Ça fait deux façon de produire le même symbole, si on est en manque de place/combo, on peut peut-être faire un sacrifice de ce côté.

De plus, on a une touche `, doit-on garder dead-` + dead-` = ` ?

Ne peut-on pas transformer dead-` + dead-` = dead-`` ? Idem pour dead-´

Ça libère alors deux places sur la carte de base, certes en altgr-shift, mais vu l’usage des exposants/indices, ça passe.
On pourrait même utiliser une seule place en faisant dead-EXP + dead-EXP = dead-IND


Autre suggestion : appliquer plus ou moins le même principe sur les touches mortes qui ne correspondent pas à des diacritiques.
Ces combinaisons permettent d’accéder à un nouveau niveau (API, latin/ponctuation, maths), si on fait deux fois la combo, que ce passe-t-il ?
- API + API = rien du tout pour l’instant,
- latin + latin = Thorn
- maths + maths = Nabla

Thorn et Theta sur la touche T, ça se tient.
Delta et Nabla sur D, ça se tient.
Par contre, API deux fois, y’a rien, et je trouve que c’est pas un surcout monstrueux, puisque c’est une double frappe de la même touche.


Encore plus loin (trop ?), encore plus fort : poursuivre ce principe pour carrément faire du ménage sur les touches mortes.
Par exemple, une touche morte langue :
- une pression = touche morte grec
- une seconde pression = touche morte latin
- une troisième = touche morte cyrillique

Avantage : gain de place
Inconvénient : ça fait une frappe de plus pour les caractères latins, et deux de plus pour le cyrillique.

Autre exemple (plus raisonnable ?) : la brève (˘) morte accessible par double pression de la touche morte caron/hatchek (ˇ).
Ou comme ce dernier a le nom d’antiflexe, double ̂ = ˇ
On pourrait avoir le point souscrit mort par double pression du point suscrit mort (˙)


Voilà, tout est histoire de compromis. Ce que je propose à un impact plus ou moins fort suivant l’usage. Mais permet de caser davantage de touches mortes.


Bref, combien de touches mortes veut-on caser ? Quels sont leur usages relatif aux autres ?

À vous !

> >>>  2. Désunification des minuscules du schwa et de l’e tourné ;
> > 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.

Ah oui non pardon, toutes mes confuses.

> >>>  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))
> 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 ! :-)
> 
> >>>  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… :|

Le but n’était pas la cohérence mais uniquement de caser le symbole.

> >>> 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.
> > […]
> > 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…
> 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.
> Cela me va très bien si l’on ne change rien ! :)

Moi aussi \o/

-- 
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".


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/