Bepo - Page 2

Léonard de Vince, pas mal...

Kochise

Je ne vois pas trop l'intérêt de changer complètement le layout clavier pour ça... J'ai accès à tous les caractères français :
avec CAPS LOCK, j'ai ÉÈÇÀ à la place des chiffres 2790, avec alt j'ai œ, … , — et «, et avec shift et alt, j'ai » et Œ. Pour tout le reste, je peux utiliser un clavier azerty classique ^^

L'idee c'est d'avoir tous ces caracteres, mais aussi qu'ils soient plus accessibles pour des raisons de confort. Mais je comprends que ca puisse sembler peu important. Dommage, a mon avis si les enfants apprenaient a taper sur cette dispositions plutot que sur du azerty, cela serait un progres.

En fait, je ne les trouve pas spécialement plus accessibles avec cette disposition ^^

non mais genre que le k soit une des lettres les plus faciles d'acces sur un clavier azerty, c'est quand meme un beau gachis d'efficacite.

meme si c'etait exactement les meme lettres, il suffit de voir cette image pour se convaincre que ce n'est pas le seul avantage du layout.


(personnellement je l'ai utilise pendant longtemps mais j'ai arrete pour deux raisons: 1) ils n'arretaient pas de changer des lettres de place, ce qui fait vraiment chier a chaque nouvelle version, et 2) j'ai un qwerty au boulot et je peux pas changer le layout donc maintenant ca me sert plus a grand chose).

Flanker> Tu utilises quelle variante de l'azerty ?

clavier OS X classique (enfin, après je l'ai modifiée un peu, mais ça ne change rien pour les accents)

Effectivement pas mal de caracteres sont accessibles (je ne vois pas l'apostrophe typographique en revanche), mais je trouve qu'ils sont bien moins pratiques d'acces que sur le bepo, en particulier les guillemets typographiques. Une affaire de gout peut-etre...

L'apostrophe typographique ? “ ‘ „ ” ’ " ' ?

Elle n'y est pas Tu as les guillemets simples, l'apostrophe pourrie, mais pas l'apostrophe typographique

« l'apostrophe typographique » n'est pas un caractère, c'est un glyphe (c'est-à-dire un certain dessin d'un caractère), c'est complètement stupide d'avoir deux versions différentes de l'apostrophe à deux positions différentes sur le clavier àmha. Il n'y a aucune différence sémantique entre l'apostrophe et l'apostrophe, c'est comme si on avait deux touches différentes pour faire un g comme ceci et un g comme cela : http://upload.wikimedia.org/wikipedia/commons/a/a1/Latin_G.svg

Mais la situation actuelle avec l'apostrophe, c'est comme si tous les "i" étaient en Courier new par défaut et qu'on essayait d'obliger l'utilisateur à entrer un caractère compliqué au clavier, à la place du i normal, pour afficher un "i" dans la police courante. Enfin en fait c'est même *exactement* ça, en remplaçant "i" par apostrophe

C'est quand même fou qu'il n'y ait pas d'option au niveau de l'OS même pour afficher systématiquement une apostrophe normale à la place du signe « ' », d'ailleurs. Ça semble pourtant le meilleur niveau où faire ça : logiciel par logiciel, c'est trop compliqué, et l'affichage des caractères est géré par des libs système, donc ça devrait pas être très dur... même MacOS n'a pas cette option ?

Bah suffit de changer la police de caractère par défaut, non ? En la remplaçant par une police avec une jolie apostrophe.

Euh ça c'était la situation sous unix/linux il y a quelques années (ça doit encore être le cas des polices console linux et des polices raster X11, d'ailleurs, peut-être), mais malheureusement il s'est depuis plus ou moins formé un standard (au moins de facto) parmi les fondeurs, notamment par la faute du consortium unicode qui fait n'importe quoi, qui fait que, si toutes les polices sans exception incluent une jolie apostrophe assortie au reste de la police (encore heureux !), désormais elles incluent *aussi* presque toutes l'apostrophe ' de type machine à écrire, et c'est cette dernière qui est utilisée par défaut (c'est-à-dire qui est utilisée pour le caractère ASCII apostrophe, et qui correspond à l'apostrophe dans les tables postscript, alors que c'était pas le cas avant). L'apostrophe ordinaire est reléguée à une position à la con, accessible par un numéro unicode improbable, donc tu peux la saisir si tu veux mais ça introduit un code 16-bit qui est différent du caractère "apostrophe", ce qui pose plein de problèmes (à commencer par le copier-coller, essaye de citer un post d'Ethaniel par insérer citations sauvées par exemple, tu verras. Ce qui se passe c'est qu'au lieu d'utiliser le caractère apostrophe, qui est associé par défaut à un glyphe moche, il insère le code caractère à la con qui correspond au glyphe apostrophe... et ce caractère ne passe pas correctement au sauver-insérer car pas dans le jeu latin standard...)

Alors certes on pourrait patcher toutes les polices pour changer les tables d'encodage et mettre le bon glyphe en correspondance avec le code caractère apostrophe, mais bon ça revient plus ou moins au même que ce que je dis (je proposais juste de le faire dynamiquement ^^).

Mais en fait je ne suis pas sûr de bien te comprendre ou que tu m'aies bien compris : je voudrais que ce soit systématiquement l'apostrophe normale qui soit affichée à la place de ', *quelle que soit la police*, je ne veux pas que ce soit le cas seulement pour la police par défaut ^^ (et je veux encore moins que tout soit systématiquement toujours affiché dans une seule et unique police )

Sally (./42) :

C'est quand même fou qu'il n'y ait pas d'option au niveau de l'OS même pour afficher systématiquement une apostrophe normale à la place du signe « ' », d'ailleurs. Ça semble pourtant le meilleur niveau où faire ça : logiciel par logiciel, c'est trop compliqué, et l'affichage des caractères est géré par des libs système, donc ça devrait pas être très dur... même MacOS n'a pas cette option ?

Ca pose des soucis, quand même... ce caractère ' n'est ni une apostrophe, ni un guillemet simple. C'est le résultat bâtard de l'histoire (comme souvent). Comme faire, dans un EDI, la différence entre le ' apostrophe et le ' délimiteur de texte ?!

Ce glyphe ' n'est en effet rien du tout . Par contre pour ce qui est de distinguer le guillemet simple fermant de l'apostrophe, je dirais qu'en français on s'en fout parce que les guillemets simples n'existent pas ; alors certes le problème se pose en anglais (britannique, il me semble qu'aux USA ils utilisent les guillemets doubles, enfin je peux me tromper)... mais déjà, remarque que le guillemet anglais fermant et l'apostrophe sont, et ont historiquement toujours été, identiques visuellement ; sont un seul et même caractère dans les polices. C'est donc un problème très particulier, la différenciation de deux usages sémantiquement différents du même caractère.

J'aurais tendance à dire que ça n'est pas quelque chose qui doit être traité au niveau de l'interface de saisie... dans les cas où on a besoin de faire cette différenciation, c'est à dire en gros pour de l'analyse automatique de texte, je pense qu'elle est assez facile à retrouver en fait, parce qu'il y a des règles relativement simples : déjà le guillemet fermant a un guillemet ouvrant qui lui correspond, et ensuite il n'est jamais suivi d'une lettre (il est suivi d'un signe de ponctuation ou d'une espace, ou de rien). À l'inverse, l'apostrophe est normalement suivie d'une lettre... bon il y a des exceptions, mais de toute façon faire de l'analyse automatique de façon infaillible c'est très difficile et à mon avis la distinction apostrophe/guillemet n'est pas le plus gros problème. Le seul truc qui pourrait arriver est que tu aies plusieurs candidats pour représenter la fermeture d'une citation et que tu choisisses le mauvais, mais en ayant accès à un dictionnaire ça doit être vraiment super rare (par exemple un dictionnaire pourrait t'informer que hopin' n'est sans doute pas une fin de citation parce que hopin n'est pas un mot et que c'est donc probablement une apostrophe qui indique la troncature d'un mot, hoping en l'occurrence. Inversement, dans hoping' c'est forcément un guillemet fermant... donc si tu n'as pas de citation ouverte c'est que tu t'es planté avant...)

Bref, je pense que c'est une fausse bonne idée que de vouloir introduire une distinction qui complique les choses pour résoudre un problème somme toute très mineur.

Le problème est un peu différent dans d'autres cas comme celui de -, qui à la saisie représente usuellement aussi bien le trait d'union que le signe moins, choses qui sont bien typographiquement deux caractères visuellement différents (le tiret en étant un troisième en toute généralité, quoique parfois identique au moins). Dans ce cas il est plus raisonnable de coder les deux caractères différemment, même si à la saisie ça n'est a priori pas nécessaire parce qu'ils ne peuvent apparaître que dans des contextes radicalement différents, donc c'est très facile pour un logiciel de faire la distinction (encore faut-il la prévoir, mais bon ^^).

P.S. : quézaco EDI ?

Sally (./46) :
P.S. : quézaco EDI ?

Environnement de Développement Intégré (IDE, quoi )

(edit : enfin je suppose, dans le contexte c'est peut-être pas certain...)

Oui c'est ça... et ça va avec la remarque que je voulais faire :

Sally (./46) :

Ce glyphe ' n'est en effet rien du tout . Par contre pour ce qui est de distinguer le guillemet simple fermant de l'apostrophe, je dirais qu'en français on s'en fout parce que les guillemets simples n'existent pas ; alors certes le problème se pose en anglais (britannique, il me semble qu'aux USA ils utilisent les guillemets doubles, enfin je peux me tromper)... mais déjà, remarque que le guillemet anglais fermant et l'apostrophe sont, et ont historiquement toujours été, identiques visuellement ; sont un seul et même caractère dans les polices. C'est donc un problème très particulier, la différenciation de deux usages sémantiquement différents du même caractère.

Il existe de fait en France dans le monde du développement... c'est malheureux mais c'est comme ça ^^

euh je ne comprends pas du tout alors

Est-ce que tu parles de la distinction entre ' délimiteur d'une chaîne de caractères et ' à l'intérieur d'une chaîne de caractères ?? si oui, je n'étais pas au courant que des IDE faisaient la distinction entre les deux en utilisant des caractères différents pour les représenter (il me semble que l'utilisation de \ est plus usuelle, non ? et en plus les chaînes sont plus souvent délimitées par ", et si ' sert à délimiter un unique caractère il n'y a plus de problème...)

Mais donc si c'est ça c'est carrément un cas *hyper* particulier et ça n'est pas du tout incompatible avec ce que je dis. Je proposais qu'au niveau du moteur d'affichage des polices de caractères, le caractère ' soit automatiquement affiché comme le glyphe ’ (purée qu'il est chiant à trouver sur mon clavier ), puisque ce glyphe est effectivement une représentation de ce caractère, et même sa représentation normale dans la police courante. Si un IDE veut faire une distinction visuelle entre le délimiteur de texte et l'apostrophe dans un texte, il y a plein d'autres moyens qu'utiliser deux caractères différents, par exemple il peut utiliser une police différente ou une couleur différente. Si tu parles de faire une distinction à la saisie, alors il n'y a carrément aucun problème, parce qu'en ce qui me concerne je ne parlais que d'affichage, pas de saisie. Si un IDE demande que tu saisisses l'apostrophe dans un texte d'une façon différente de l'apostrophe qui sert à le délimiter, pourquoi pas. Mais je ne suis toujours pas sûr d'avoir compris ce que tu voulais dire...

Non, justement, je dis qu'on a un problème pour dire à l'OS d'utiliser ' comme une apostrohe, alors que ça a un usage double dans les faits ; et que c'est pour ça qu'il a été préféré faire un nouveau caractère apostrophe, deux pour les guillemets simples, et conserver ce vieux ' pour la rétro compatibilité... c'est tout...

euh... il y a plein d'autres caractères qui ont un usage différent dans le texte et dans le code, typiquement comme je le disais "-" est utilisé pour le signe moins et ça n'a jamais posé de problème que dans un texte il soit aussi utilisé comme trait d'union, et les parenthèses ont un sens spécifique dans le code, je ne parle pas du point-virgule et du point ou en fait d'à peu près n'importe quel autre signe de ponctuation, pourquoi l'apostrophe devrait avoir un traitement particulier

Par ailleurs ' n'a pas été « conservé pour la rétrocompatibilité », il est relativement récent (enfin non, mais le fait qu'il soit universellement affiché en lieu et place de l'apostrophe est relativement récent. Comme je le disais ça n'était pas le cas sous la plupart des OS il y a 10 ans. C'est un phénomène qui est plus ou moins lié à une erreur dans la spécification unicode, il me semble...) Et puis un problème de compatibilité qui consiste à afficher un caractère pas exactement comme il l'était avant, c'est vraiment un tout petit problème de compatibilité, quelle application peut vraiment *dépendre* du fait que l'apostrophe soit droite ? à moins de faire de l'ascii art, je vois pas

Non c'est juste que si ta touche ' ne fait plus un ' mais une apostrophe, ça n'a plus de sens quand ça délimite une phrase... disons que ça en a encore moins qu'aujourd'hui

Bof, je ne vois pas trop ce que ça changerait, je trouve

Ben le fait que ta touche "-" ne fasse pas un moins mais un trait d'union fait que ça n'a théoriquement aucun sens quand on l'utilise dans une opération, mais dans les faits ça ne pose absolument aucun problème... (et pourtant s'il y avait une quelconque nécessité de différencier ça serait particulièrement facile à résoudre : il y a un moins sur le pavé numérique, il suffirait de l'associer à un caractère différent), je ne vois toujours pas quelle ébauche de problème ça pourrait poser si la touche 4 faisait le signe ’ plutôt que '

De plus si c'est vraiment un problème, alors ce problème existe déjà et ma solution n'y changerait rien : il n'y a actuellement pas de distinction entre le caractère délimiteur de texte et l'apostrophe... alors si ça te gêne davantage d'avoir un caractère délimiteur qui ressemble à ’ que d'avoir une apostrophe qui ressemble à ', eh bien... je ne te comprends pas, mais vraiment pas du tout . (En plus tu codes en général pas avec une police texte mais avec une police de type console, donc à la rigueur on peut mettre un apostrophe qui ressemble à ' dans les polices console, de toute manière elles servent pas à écrire des romans a priori, enfin bref.)

Non, je veux deux touches guillemets simples, une touche apostrophe, et une possibilité d'avoir le ' usuel et mixte pour rétro compatibilité Et qu'à l'avenir, les outils de développement utilisent les vrais guillemets simples pour les chaines de caractère ^^

mais rétro-compatibilité avec quoi ? l'ascii-art ?
Les guillemets simples sont déjà accessibles au clavier (sur le clavier PC français l'ouvrant est un peu caché, c'est AltGr+7, mais dans la mesure ou c'est pas un caractère usuel en français... et quant au fermant ben c'est l'apostrophe). Le problème c'est qu'en raison de standards mal goupillés ils sont généralement affichés comme ` et ' au lieu de ‘ et ’, mais justement c'est cet état de fait qui devrait absolument changer... (et est relativement récent, c'est ça le pire...)

Quant au fait que le délimiteur de texte doive être affiché ' plutôt que ’ dans un IDE, déjà je n'en vois sincèrement pas l'utilité, mais ensuite, comme je l'ai dit, de toute façon les IDE utilisent des polices spécifiques, donc bon je ne vois pas en quoi c'est un argument contre le fait que par défaut les bons dessins soient affichés...

Rétro-compatibilité aux logiciels qui utilisent ' sans se poser la question de ce que c'est...

Si j'utilise
$a = ‘This is a common string’
Je doute que mon logiciel accepte (et je veux bien deux touches différentes ; quand les logiciels essayent de deviner seuls, c'est la merde ; et on a bien deux touches pour les parenthèses !).

e ne parle que de l'affichage, ce que je voudrais, c'est que tu continues à taper :$a = 'This is a common string'Mais je me tue à te dire que jcomme avant, en utilisant la touche 4 ; il n'est pas question de changer le caractère apostrophe par quoi que ce soit d'autre dans la suite des caractères, mais simplement, au moment d'afficher à l'écran (ou d'imprimer), d'utiliser le dessin ’ (qui est présent dans toutes les polices) plutôt que le dessin '.

Par conséquent c'est automatiquement rétro compatible, parce que ton IDE, il ne regarde pas ce qui est affiché à l'écran, il regarde la suite des codes de caractères contenus dans le fichier... Alors certes ça voudrait cependant dire que par défaut le truc que tu as tapé s'afficherait :
$a = ’This is a common string’s en quoi c'est très gênant, certes c'est un peu moins joli que $a = ‘This is a common string’mais franchement je ne vois pa mais bon dans du code, on s'en fout un peu... et c'est soluble en traitant les polices console différemment des polices à chasse variable, en plus...

Et euh il y a encore assez peu de temps ça s'affichait effectivement comme ça sous les unix, j'ai programmé avec, le shell fait un grand usage de chaînes délimitées par ' ' (d'ailleurs ` est aussi un délimiteur pour un autre usage, toujours en utilisant deux fois le même), et ça ne m'a jamais posé le moindre problème...

j'ai l'impression que tu confonds la sémantique du signe et la façon dont il est dessiné, ce sont deux choses complètement distinctes...

Oui mais c'est un peu nul si ce qui est affiché n'est pas ce qui est à l'intérieur... encore un coup à avoir des affichages différents suivant les OS, ça, ou à ne pas réaliser que tu n'utilises pas le bon caractère puisque c'en est un autre qui s'affiche (genre tu utilises ’ alors que tu aimerais ', mais c'est de toutes façons ’ qui s'affiche dans les deux cas).

???
tu as dû mal me comprendre... ' et ’ sont deux dessins différents pour un seul et même caractère, l'apostrophe.

Il ne s'agit pas d'afficher quelque chose de différent de ce qui est à l'intérieur. Si on voit ASCII 0x27, l'apostrophe, ben on affiche ’, l'apostrophe ; et si on voit autre chose, ben on affiche autre chose et pas une apostrophe. Pas de confusion possible. Le caractère délimiteur de texte dans ton IDE est représenté par ASCII 0x27, le caractère apostrophe dans ton texte est également représenté par ASCII 0x27, le guillemet simple fermant dans un texte en anglais est lui aussi représenté par ASCII 0x27, et c'est affiché ’ dans les trois cas. Voilà ce que je dis, ni plus ni moins. C'est pour soutenir cette proposition, et pas autre chose, que j'argumente depuis tout à l'heure, et je ne vois toujours pas quel problème ça peut poser.

Par contre je vois bien quels problèmes l'absurde situation actuelle, où à cause du fait que 0x27 est souvent (désormais presque systématiquement) affiché ' au lieu de ’ on a créé ce gros hack qu'est le caractère unicode 0x2019 (qui s'appelle guillemet-apostrophe par opposition à apostrophe, déjà c'est vachement clair) afin d'avoir un caractère qui soit systématiquement affiché ’... résultat on a un doublon, deux caractères différents qui ont exactement la même sémantique et des textes qui peuvent utiliser aléatoirement l'un ou l'autre, voire les deux alternativement, super , pose¹. Des fois je me demande ce qu'ils fument chez unicode

¹J'ai failli oublier de finir ma phrase, heureusement que je l'ai relue après coup