Articles : [RFC] Évolution du clavier « fr-latin9 »
Posté par nimnim (). Modéré le 13 septembre 2006.
Au vue de cette situation, les claviers doivent s'adapter et l'enjeu actuel est de savoir dans quelle direction vous souhaiteriez voir le clavier fr-latin9 évoluer. En effet, voilà déjà plusieurs années que votre serviteur (Nicolas Mailhot) a repris le clavier fr-latin9 que Guylhem Aznar maintenait et qui a été inclus dans xfree86/xkb. Depuis, je n'ai eu aucun retour à son sujet. Entre temps, Guylhem a succombé au clavier canadien international et n'est plus trop intéressé.
Depuis la situation a évoluée :
- xorg et xfree86 se sont séparés,
- la base de définition des claviers a désormais son propre projet
- et surtout, les locales unicode sont devenue la règle et plus l'exception
![[en]](../images/en.png)
L'entrée dans le bugzilla xkeyboard−config (727 hits)-
projet de définition des claviers (1069 hits)
-
Patch préliminaire (454 hits)
> Lire la dépêche (274 commentaires, moyenne: 2,7).
Vous avez demandé le commentaire #754189.
Run by 
Cette page a été générée par Templeet en 0.1392s (dont 0.0138 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
ls | more --> more: command not found (???)
ce qui me gene dans le latin9 par rapport au latin1 : Alt-gr + espace donne espace insécable. un espece de caractere bizarre qui ressemble a un espace a l'oeil, mais que mon shell ne connait pas comme un espace.
pour peu qu'on tape vite et qu'on maintienne alt-gr appuyé lors d'un espace apres le pipe, on a droit a un joli :
# ls | less # remarquez ici l'espace insécable entre | et less
bash: less: command not found
c'est assez agaçant.
résultat => retour au clavier latin1
une solution avec une nouvelle map ?
[^]Re: ls | more --> more: command not found (???)
pareil ! j'ai cru devenir fou avec les 'grep: command not found' avant qu'on me donne la réponse sur la tribune. C'est plus qu'agaçant on peut perdre pas mal de temps avant de comprendre de quoi il retourne (au moins la première fois. maintenant je sais)
[^]Re: ls | more --> more: command not found (???)
[:haha]
Tu pourrais au moins avoir la politesse de nommer ton sauveur...
Enfin à mon humble avis, c'est un des plus grands avantages du fr-latin9, l'espace insécable.
[^]Re: ls | more --> more: command not found (???)
Ah ça fait plaisir de se sentir moins seul avec ce genre de problème :)
Au début on n'y comprend rien (comment ça tu connais pas grep !?!?)
Ensuite on trouve ça super lourd...
D'ailleurs le problème m'arrive aussi en faisant du Perl... En général c'est plus suite à une accolade qu'un pipe, mais au final il n'apprecie pas plus à l'interprétation : Unrecognized character \xC2
[^]Re: ls | more --> more: command not found (???)
Oui, je confirme qu'à la longue c'est _vraiment_ lourd... Et je n'avait pas réalisé que ça venait du latin9... En fait, du moment que je n'avait pas un q en tapant un a je ne m'était pas trop posé la question :$
[^]Re: ls | more --> more: command not found (???)
ah oui mais non, vous allez pas me retirer l'espace insécable quand même. C'est un truc limite indispensable quand on utilise le clavier pour faire autre chose que de la ligne de commande et de la programmation.
Le caractère bizarre qui ressemble à un espace c'est bien un espace (d'où le fait qu'il y ressemble).
Si tu laisses altgr appuyé trop longtemps c'est comme si tu laisses ctrl ou shift appuyé trop lontemps, ça donne n'importe quoi et c'est bien normal.
Si vraiment ça pose problème, demande à ton shell d'évoluer et de bien le considérer comme un espace (parce que bon, c'en est un).
[^]Re: ls | more --> more: command not found (???)
> C'est un truc limite indispensable quand on utilise le clavier pour faire autre chose que de la ligne de commande et de la programmation.
ah bon ? dans quelle situation par exemple ?
[^]Re: ls | more --> more: command not found (???)
Pour écrire du texte français, par exemple !
Là par exemple, tu aurais dû en mettre un entre "bon" et "?"
(enfin, pour pinailler un peu, ce serait même une espace fine insécable, qu'il faudrait mettre là)
[^]Re: ls | more --> more: command not found (???)
Quand on écrit en bon francais (désolé, clavier sun...), on met des espaces insécables avant les doubles ponctuations ( : ; ? ! et je crois que c'est tout a ma connaissance) et à l'intérieur des guillemets francais (les << et >>). Sans ca, point de bon texte dans un traitement de texte utilisateur lambda.
Donc, OUI à l'espace insécable ! (Note : il me semble qu'en général, la combinaison est ctrl+espace...)
L'espace insécable est différent et à utiliser parce que :
- il ne fait pas toujours la même taille que l'espace normal (il me semble que la norme est de faire un "demi espace", à vérifier)
- il sert surtout à ne pas se retrouver avec un ":" perdu tout seul en début de ligne dans un texte, ce qui est une faute. Et la bidouille ne suffit pas : que se passe-t-il si jamais un jour tu ajoutes du texte avant le : qui "pousse" le : en début de ligne ? Il vaut mieux le rendre systématique (certains éditeurs comme OOo le corrigent automatiquement par exemple, si on en fait la demande dans les options de correction)
[^]Re: ls | more --> more: command not found (???)
Tout ce que tu décris, le traitement de texte pourrait le faire tout seul sans qu'on aie besoin de recourrir à un caractère de plus. D'ailleurs dans Latex on n'utilise pas d'espace insécable il fait tout ça comme un grand.
Donc NON à l'espace insécable, ou alors qu'on l'affiche differement d'un espace "normal" (avec un petit point au milieu ou je ne sais quoi, mais qu'on puisse faire la différence !)
[^]Re: ls | more --> more: command not found (???)
Oui et non, pour tex c'est tilde ~Unicode me semble intéressant pour résoudre certaines ambiguïtés ou enrichir les langages. Parfois le code ascii atteint ses limites. Par exemple:
le \ de TeX doit être écrit \\\\ lorsque que tu génère du TeX en Perl, C ... Un cauchemar. Un caractère commande aurait été plus judicieux.
idem pour l'affectation x<-2, x < -2 ou x flèche 2?
[^]Re: ls | more --> more: command not found (???)
Ah bon, tu es sûr ? Dans latex j'ajoute explicitement un espace insécable avant les caractères de ponctuation. Mais si y'a pas besoin, clair que je vais pas m'embeter !
[^]Re: ls | more --> more: command not found (???)
Oui c'est géré si tu as précisé à Babel que tu écris en Français. Il ira même transformer le "bonjour!" en "bonjour~!".
Et si vous voulez faire la guerre
Payez-la de votre peau
[^]Re: ls | more --> more: command not found (???)
1) Comme l'a dit quelqu'un plus haut, ce n'est pas tout à fait équivalent à "bonjour~!" : l'espace insécable inséré devant le point d'exclamation est plus fin qu'un espace insécable généré avec « ~ ».
Pour vérifier ça, il suffit de tester ceci :
Pouet !\\
Pouet~\string!
2) Personnellement, je n'aime pas les logiciels qui réfléchissent à ma place (j'aime ma liberté !), donc je désactive cette fonction automatique avec \NoAutoSpaceBeforeFDP. Ceci me permet, si j'en ai envie, de mettre une double-ponctuation sans espace la précédant. Par contre, si je mets un espace (normal) devant une double ponctuation, celui-ci est bien transformé en espace insécable fine par [frenchb]{babel}. Parfait.
[^]Re: ls | more --> more: command not found (???)
> Tout ce que tu décris, le traitement de texte pourrait le faire tout seul
> sans qu'on aie besoin de recourrir à un caractère de plus.
> D'ailleurs dans Latex on n'utilise pas d'espace insécable il fait tout
> ça comme un grand.
Euh ... il peut le faire tout seul mais dans le résultat c'est bien un caractère différent.
Reste que justement, il ne peut souvent pas le faire tout seul. Les deux points ils sont précédés d'un espace insécable en français, mais pas en anglais. Les chiffres, des fois il est pertinent de mettre un espace insécable (ex: PHP 5) et des fois non (ex: j'ai acheté 3 lapins).
Je ne veux pas limiter mes espaces insécables uniquement aux gros traitements de texte, je veux pouvoir écrire des textes simples avec des vrais caractères français. Je ne veux pas non plus d'un espace insécable purement automatique qui m'empêche de décider quand je le veux et quand je ne le veux pas.
Si les développeurs ou comptables ont un problème d'ambiguité entre O et 0, c'est à eux de faire attention en tapant au clavier, de spécifier une police spécifique dans leur logiciel (0 barré) ou de coder un comportement spécifique (le mode idiot-proof de certains imports qui transforme les O en 0 quand ils attendent un nombre).
Il n'y a rien à faire sur le clavier, sur les polices habituelles, et encore moins retirer un des deux caractères du clavier.
Pourquoi en serait-il autrement ici ?
Si tu as un problème d'ambiguité dans les commandes shell à cause de mauvaises frappes clavier, tu peux tenter une des solutions suivantes :
- faire en sorte de faire attention en tapant
- mettre une police spécifique à la ligne de commande dans ton terminal
- demander un mode idiot-proof au logiciel pour qu'il considère l'espace insécable comme un espace sécable
Dans tous les cas il n'y a pas lieu de toucher au clavier ou à l'espace insécable, qui est utile et tout à fait pertinent en français.
[^]Re: ls | more --> more: command not found (???)
Je pinaille, mais on dit « une espace insécable »
Le mot « espace » est féminin lorsqu'on parle du caractère.
:-D !!!NOUVEAU!!!
[^]Re: ls | more --> more: command not found (???)
On écrit : « j'ai acheté trois lapins », en toutes lettres. Non mais.
[^]Re: ls | more --> more: command not found (???)
Quand tu traduis des programmes par exemple. Les .po, la localisation, tu n'as jamais entendu parler ? La question "comment faire un espace insécable sous linux" apparaît régulièrement sur les ML de traduction (par exemple pour Wesnoth-fr, qui est une liste à bas débit, c'est environ tous les 2 mois).
[^]Re: ls | more --> more: command not found (???)
si tu te poses la question c'est sans doute que tu n'en as pas besoin ;)
Sans doute qu'il voulait dire pour taper du texte "littéraire", mais je reste quand même persuadé que cela reste du domaine de l'éditeur de texte : sous latex, je présume que c'est automatiquement géré (une espace en français avant un point virgule -> espace insécable), et sous openoffice c'est également géré par le système je crois, par exemple on obtient cette espace avec ctrl+espace , ou évidemment altgr + espace)
D'autres utilisations ?
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: ls | more --> more: command not found (???)
Wikipédia... si FF n'avait pas ce bug qui les fait disparaître !
[^]Re: ls | more --> more: command not found (???)
Ce n'est pas la faute de firefox ! Si tu veux faire une espace insécable sur wikipedia, tu écris
[^]Re: ls | more --> more: command not found (???)
À l'âge d'Unicode, les entités HTML ont fait long feu !
Tous les "&*;" sont à jeter à la poubelle quand on peut faire autrement !
Lire les discussions de Wikipédia à ce sujet (dsl pas le temps de rechercher la page de discussion concernée).
[^]Re: ls | more --> more: command not found (???)
Et comment tu fais un "<" ? Et dans les URL, comment tu fais un "&" ? D'ailleurs, un "&" qui n'est pas remplacé par "&" dans une URL provoque une erreur au validator... Donc non, on ne doit pas les jeter ! Et vive le !
[^]Re: ls | more --> more: command not found (???)
il y a un mot clé "quand on peut faire autrement" ;)
Les < > & (et accessoirement " et ') ont besoin des entités. C'est le principe même de toutes les grammaires, fournir un système d'échappement aux caractères spéciaux.
Les espaces insécables et autres caractères unicode n'en ont pas besoin. C'était juste des raccourcis pour palier les problèmes de saisie et d'internationalisation. Ces problèmes peuvent maintenant être évités bien en amont de manière bien plus satisfaisante.
[^]Re: ls | more --> more: command not found (???)
Oui, comment tu fais pour que dans "J'ai acheté un livre sur PHP 5." le "5" ne passe pas à la ligne alors que dans "Le chiffre 5 est le résultat de 3 et de 2" on puisse le mettre à la ligne ?
Cette problématique n'est pas gérable automatiquement. Et je ne vois pas non plus pourquoi je devrais lancer un gros machin qui a des règles spécifiques à chaque langue pour taper du simple texte au clavier.
L'espace insécable c'est du même niveau que les majuscules accentuées ou les chevrons à la françaises. Il y a des caractères spécifiques et c'est bien de les utiliser. Que certains logiciels dédiés sachent repérer les erreurs et proposer des conversions implicites c'est très bien, mais ça ne doit pas devenir la règle.
> sous openoffice c'est également géré par le système je crois, par
> exemple on obtient cette espace avec ctrl+espace , ou évidemment
> altgr + espace)
Tout à fait. Et tu voudrais que tous les logiciels qui ne soient pas dédiés à la programmation ou à la ligne de commande réimplémentent en interne un remappage du clavier suivant la langue (parce que l'espace insécable avant ponctuation double c'est purement français) en interne ?
Ca ne serait pas plus logique de traiter ça de manière globale sur le clavier et que les applications à usage "spécifique" comme les terminaux ou les éditeurs de code fournissent un moyen de palier à une erreur de frappe (parce que votre problème reste une erreur de frappe) ?
[^]Re: ls | more --> more: command not found (???)
c'est un avis perso, mais je pense que tout ce qui doit être stocké à +/- long terme devrait mieux garder les caractères ascii standard (ceci concerne wikipedia, messagerie internet etc), et c'est au logiciel (ou pourquoi pas au système si on peut le résoudre à un niveau supérieur) de gérer cela.
Je ne suis pas du tout pour un apauvrissement de la syntaxe et des conventions du français correct, mais je trouve déplorable lorsque l'on présente du texte qu'il ne soit pas dans un format standardisé et pérenne, c'est à dire par exemple les messages internet composés dans "word", et qui sous le filtre des divers serveurs auront été complètement dénaturés : les guillemets, les apostrophes etc.
Justement sous latex si on écrit des apostrophes standards ils sont transformés ensuite en belle apostrophe...
Peut-être par la suite lorsque l'utf-8 sera généralisé sans problème, on pourra en reparler peut-être...
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: ls | more --> more: command not found (???)
Je ne sais pas si tu as vu, mais UTF-8 est généralisé sans problème aujourd'hui.
Le nombre de générations de Red Hat/Fedora par exemple où UTF-8 est activé par défaut doit rapidement approcher la dizaine
[^]Re: ls | more --> more: command not found (???)
mauvais exemple, ils les sortent comme vache qui pisse. autant compter le nombre de secondes depuis la création d'Unicode si c'était pour invoquer un grand nombre sorti de nulle part.
Windows has no users. It has hostages.
[^]Re: ls | more --> more: command not found (???)
N'empêche que l'essentiel c'est qu'effectivement la plupart des distros ont choisi utf8 ou le feront dans un avenir proche.
Au vu des arguments évoqués, Unicode a tout d'un standard universel, n'en déplaise aux moinsseurs d'unicodistes !
(Venez argumenter, plutôt que moinsser, au fait ! On a l'impression d'assister à un vote "Unicode : bien ? Pas bien ?", alors que le but est de se mettre d'accord sur ce qui est raisonnable. Autant voter sur le temps qu'il fait !)
[^]Re: ls | more --> more: command not found (???)
Unicode est justement censé être le standard dont tu parles. Ce n'est pas pour rien que Wikipédia a choisi cette option.
One charset to rule them all, si on veut.
Reste à se mettre d'accord sur l'encodage (UTF-xx). Mais je pense que les différentes possibilités ont toutes leurs utilités, liées à des contraintes techniques différentes. Heureusement, on peut aussi se mettre d'accord sur la manière de reconnaître l'encodage utilisé.
[^]Re: ls | more --> more: command not found (???)
Marrant, en fait je pense justement le contraire. En reléguant certaines choses au logiciel, tu fais justement bien des dégats à la pérénité de tes données. Tu imposes à tout logiciel futur d'implémenter les mêmes règles, avec les mêmes interprétations et éventuellement les mêmes défauts.
Mettre comme tu le dis tes données en pur ascii en imposant au logiciel de lecture de transformer ça à la volée, tu jettes des contraintes dans le futur sans savoir si tu sauras les gérer facilement.
Personnellement j'ai bien plus confiance dans le fait que Unicode et le codage unicode que j'utilise persisteront (ou du moins auront des programmes de conversions vers les éventuelles nouvelles normes) que dans le fait que les logiciels du futur interprêteront de la même manière que maintenant les règles du français à partir d'un texte en pur ascii.
> Peut-être par la suite lorsque l'utf-8 sera généralisé sans problème, on pourra en
> reparler peut-être...
On y est depuis longtemps tout de même ...
[^]Re: ls | more --> more: command not found (???)
Si tu laisses altgr appuyé trop longtemps c'est comme si tu laisses ctrl ou shift appuyé trop lontemps, ça donne n'importe quoi et c'est bien normal.
Si vraiment ça pose problème, demande à ton shell d'évoluer et de bien le considérer comme un espace (parce que bon, c'en est un).
Certainement pas !!! Il a un code ASCII différent !!!
Il est proprement scandaleux que deux caractères différents et d'usage différents soient représentés exactement de la même manière à l'écran, au point que l'utilisateur n'ait aucun moyen de les comparer. Le pire est que le clavier les produit tout seul. Si tu tapes sur un clavier de portables, tu verras que les touches de modification comme alt-gr ont une certaine latence lorsqu'on les relâche, et il n'est pas normal que l'utilisateur doive penser à s'arrêter une demi seconde lorsqu'il sait qu'il vient de toucher à l'une de ces touches. Je veux bien un caractère à la con lorsque j'appuie dessus, mais il faut qu'il soit matérialisé dans ma police pour que je puisse corriger ma faute de frappe.
[^]Re: ls | more --> more: command not found (???)
Si tu veux taper encore plus vite, il suffit de ne pas mettre d'espace.
$ ls|less
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: ls | more --> more: command not found (???)
Sur l'espace insécable, d'autres claviers on fait le choix de le mettre à alrgr+shift+espace, ce qui le rend plus difficile à taper accidentellement mais le laisse accessible.
Je pourrais faire pareil dans le nouveau latin9, cela satisfait-il tout le monde ?
[^]Re: ls | more --> more: command not found (???)
Dommage que ce soit si compliqué (vu que je l'utilise quand même pas mal), mais oui, tant qu'il reste relativement accessible, ça me parait un compromis réaliste (pour ma propre personne, je ne sais pas pour les autres).
[^]Re: ls | more --> more: command not found (???)
Personnellement, ça me semble illogique que l'on doive rendre l'accès à ce caractère si dur sous prétexte qu'une minorité de personnes a des problèmes avec.
En revanche, ce que je pense, c'est que les personnes qui n'arrivent pas à taper correctement des "| " sans générer d'espace insécable utilise xmodmap pour remapper comme il leur convient la touche Espace pour retirer toute génération d'espaces insécables.
Exemple : dans le fichier .Xmodmap:
keycode 65 = space space space space space space
S'en suit un xmodmap .Xmodmap
À bon entendeur.
[^]Re: ls | more --> more: command not found (???)
Perso, j'ai une frappe bien rapide mais il ne m'est jamais arrivé une seule fois de faire l'erreur de l'espace, parce que j'utilise le pouce de la main droite pour taper sur altgr et ce même pouce pour les espaces dans le terminal. L'erreur est donc impossible.
[^]Re: ls | more --> more: command not found (???)
xmodmap.... C'est bien quand on est sous X mais sinon, sur une bonne veille console des familles ?!
Me concernant, c'est peut-être idiot mais la première fois de ma vie ou j'ai testé une distrib utilisant latin-9 par défaut, je me suis retrouvé très vite confronté à ce problème (c'est ça de taper trop vite :) et lorsque je me suis rendu compte que ça venait du latin-9 j'ai cru naïvement qu'il s'agissait d'un bug et je ne l'ai plus jamais utilisé.
C'est bête parce que ça permet probablement de faire des trucs sympas mais ce simple "détail" me gonfle à un point tel que, pour moi latin-9 == /dev/null !
The UNIX way of sex:
date;cd ~;gunzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep
[^]Re: ls | more --> more: command not found (???)
« d'autres claviers on fait le choix de le mettre à alrgr+shift+espace, ce qui le rend plus difficile à taper accidentellement mais le laisse accessible. »
Perso, c'est une modif que j'applique depuis toujours, donc je vote [pour] les yeux fermés. En plus, ça n'empêche vraiment pas de taper des espaces insécables quand il en faut, le Shift-AltGr-Espace restant quand même un raccourci très confortable.
Tiens sinon,une autre modif que j'aime bien, c'est ça :
key <LSGT> { [ less, greater, guillemotleft, guillemotright ] };
Je trouve ça assez mnémotechnique, au point d'avoir oublié où étaient ces guillemets à l'origine. Et le pipe que ça remplace ne me manque pas trop (j'en avais mis un sur le ² en haut à gauche du coup, à la place des guillemets anglais, mais je continu d'utiliser plutôt celui du 6 en fait, même si il est pas très confortable).
[^]Re: ls | more --> more: command not found (???)
Pourquoi taper plus de caractères que nécessaire ?
# ls|less
est bien suffisant !
Bon, ok, -----------> []
[^]Re: ls | more --> more: command not found (???)
ce qui me gene dans le latin9 par rapport au latin1 : Alt-gr + espace donne espace insécable. un espece de caractere bizarre qui ressemble a un espace a l'oeil, mais que mon shell ne connait pas comme un espace.
Tout pareil, j'ai essayé Latin9 il y a quelques années, j'ai vite abandonné. Cette combinaison de touches était la raison majeure pour laisser tomber ce truc vite vite vite, mais si je me souviens bien, il m'avait aussi semblé que l'auteur (de l'époque...) avait voulu mettre trop de caractères accentués en combinaison sur les touches caractères correspondantes (genre â à Â À sur le « a »), ce qui faisait doublon avec d'autres touches (genre « à ») et d'autres pratiques simples et efficaces (genre Majuscules puis « à » puis Majuscules quand on veut insérer un À isolé) ; le tout au détriment d'autres caractères de typographie, que j'aurais bien vu en combinaison de touche.
Mais tout ceci est bien loin... Et là je suis sur un portable sous Windows en train de faire Shift + Num puis AltGr, 0, 1, 9, 2 puis Shift + Num, le tout pour insérer un malheureux À... Alors Latin1 ou Latin9... Tant que c'est pas OuinOuin !
[^]Re: ls | more --> more: command not found (???)
Ah mais c'est pour ça!!! J'ai cru que mon install partait en sucette.
Merci de tout coeur, je tapperai moins vite. :D
[^]Re: ls | more --> more: command not found (???)
Comme indiqué, dans la nouvelle version, tu pourras taper à la vitesse que tu veux