anaseto a écrit 2229 commentaires

tout en gardant quelque chose d'au moins aussi simple en terme d'analyse syntaxique (càd dont la syntaxe est bien adapté à un traitement dans une chaîne de compilation)"

Pour perl ça pourrait pas être beaucoup plus compliqué que maintenant, où l'analyseur lexical triche pour faire avaler une grammaire contextuelle (et dont l'analyse est indécidable) à un analyseur LALR ;)

Mais sinon c'est vrai que mettre à profit les terminaisons régulières comme les pluriels en -jen analogie avec les @ de perls (ou -aro), ordonner les phrases comme on veut grâce à l'accusatif ou d'autres choses en ce genre est assez intéressant d'un point de vue linguistique, et pourrait au moins peut-être servir de base à un DSL utile.

Sur le manuel tu trouveras disséminées des bouts de BNF, qui en les regroupant te donneront à peu près tout. Et d'ailleurs, grâce à camlp4 (le préprocesseur à base de grammaires d'OCaml) se serait facile de faire la translitération rigoureusement.

Ça me rappelle un fois que j'avais tenté de faire ça à coup de Filter::Simple en perl, le résultat était assez rigolo, mais c'était pas très fiable car à coup de filtres utilisant des substitutions avec des regexps.

Mais bon, je suis en fait assez sceptique sur l'intérêt réel de ces traductions, parce que si je comprends bien tu traduits les mots-clés, du coup c'est soit des mots « descriptifs », soit des verbes à l'impératif, donc au final la régularité de l'espéranto n'apporte ici pas grand chose (c'est pas comme si on faisait des vraies phrases). Je veux dire : en anglais le manque d'information grammaticale sur un mot et la compléxité de la langue sont gênantes pour la prose, mais en programmation la fonction grammaticale est en général évidente de toutes façon et ne s'apparente pas vraiment à celle d'un langage naturel. Quant-au vocabulaire il ne faut pas vraiment y penser comme si c'était de l'anglais, mais plutôt une poignée de mots magiques, parce que c'est de ça qu'il s'agit en vrai.

Ce qui serait plus intéressant, et mettrait en lumière une vraie discrimination, ce serait de faire des traductions de documentation de librairies par exemple, parce que du coup là, pour bien comprendre ce que fait chaque fonction il faut comprendre l'anglais un minimum bien, et pour écrire soi-même une doc en anglais sans faire étalage d'une orthographe ridicule aussi, mais ce serait aussi beaucoup plus laborieux :)

Ceci dit, si c'est juste pour s'amuser, dans les essais plus tordus, il y a Perligata, qui permet d'écrire du perl en latin, mais pour le coup toutes les structures s'écrivent à l'aide de mots latins, il n'y a plus d'accolades, dollars ou autres, car des mots ou déclinaisons latines sont utilisées pour les fonctions grammaticales, et les phrases se terminent par un point. Alors, c'est pas très utile, mais c'est rigolo, et un truc comme ça en espéranto serait, à défaut d'être utile, plus simple que la version latine, ça c'est sûr.

Aucune configuration ne donne un résultat correct. J'ai testé avec rxvt-unicode, xterm ainsi qu'en console.

Des fois il faut s'avouer vaincu ;)

Tant que ça n'arrive que sur certains mails htmls pas standard… surtout que les histoires d'encodages c'est assez rébarbatif. Au pire mettre un firefox dans le mailcap si c'est indispensable :)

Le seul truc qui me vient à l'esprit : tester avec l'option -assume_charset (au cas où ce html ne spécifie pas d'encodage). Mais de toutes façons cet html est bizarre on dirait parce qu'il mélange plusieurs façons d'encoder les lettres, et du coup « à » se trouve pas traduit pareil à différents endroit suivant le -display_charset donc ça dépasse peut-être les capacités divinatoires de lynx.

Et pour lynx avec CHARACTER_SET:utf-8 et ASSUME_CHARSET:utf-8 ? (j'ai vu que j'avais ça dans le fichier de conf et que ça n'y était pas par défaut donc je l'avais sans doute rajouté pour quelque chose)

En tous cas, j'ai vérifié et sur un vieux message avec Type: text/html et les accents passent bien chez moi avec lynx -dump. Alors si ça marche pas lynx a d'autres options sur les charsets, mais je sais si elles serviraient.

Pour ce mail ça marche pas parce que ça a l'air d'être que du html, mais souvent c'est des multipart/alternative et du coup j'ai dans le .muttrc alternative_order text/plain text text/enriched text/html pour afficher de préférence la version texte quand c'est possible, donc ça permet d'éviter le text/html assez souvent.

l'éditeur interne de mutt […]

Tiens, c'est étrange. Dans la doc je lis :

3.60.0 editor:
...
This variable specifies which editor is used by mutt. It defaults to the value of the $VISUAL, or $EDITOR, environment variable, or to the string “vi” if neither of those are set.

donc l'éditeur ça doit être celui qui est donné par $EDITOR probablement (vu que c'est pas vi visiblement).

Dans mon .muttrc j'ai la ligne :

set editor="vim -c ' set syntax=mail ft=mail enc=utf-8'"

Une petite recherche m'a conduit à l'option formatoptions qui gère le reformatage, et il suffit que > soit dans l'option comments (normalement c'est le cas) pour que vim considère le > comme il considèrerait un symbole de commentaire de ligne dans un langage de programmation.

Chez moi la mise en forme via gq} ne fait pas ces immondes pâtés.
Mais j'utilise une extension nommée 'mail.tgz', ceci explique probablement cela …

Je n'ai pas d'extension spéciale pour les mails (juste ce qui est de base), et le gq} me justifie le texte en tenant compte des > et en en rajoutant ou en enlevant suivant ce qu'il faut donc c'est bizarre. Peut-être que c'est comme ça sans les options nocompatible et filetype plugin indent on (ce qui est sans doute le cas dans le paquet vim-tiny de base de Debian/Ubuntu).

Les programmes auxquels je contribue coupent leurs lignes de code à 80 caractères, mais je dois être vieux jeu.

Oui, je pense aussi que ça ne m'arrive de dépasser cette limite que pour les commandes shell avec find et compagnie.

Et ça donne un truc comme ça quand je réponds :
[…]

C'est moche en effet ;) C'est une des raisons pour lesquelles j'ai jamais trop aimé les « soft-breaks » plutôt que les vrais retours à la ligne.

Je n'ai trouvé que mutt. (Mais si tu as autre chose à proposer…)

En fait j'ai très vite fait les transitions évolution -> claws-mail -> mutt donc je n'ai pas grand chose d'autre à proposer. En même temps, je crois que je me suis arrêté de cherché plutôt au bon logiciel vu que j'aime la configurabilité, les raccourcis clavier, le fait de pouvoir taper mes mails dans vim, et les jolies couleurs auquelles sont consacrées plus de cent lignes de mon .muttrc :)

les mails en html. J'en reçois, et ils sont soit illisibles (encodage foireux, pourtant j'ai essayé toutes les combinaisons d'options de codage de links et elinks)

Et avec lynx dump ? J'ai pas le souvenir d'avoir eu de problèmes (mais je reçois pas trop de messages html donc j'ai peut-être juste eu de la chance).

les images. J'ai mis un autoview pour les images (parce que c'est une fonction basique des clients mails dont j'ai besoin) avec img2txt […]

C'est curieux, moi j'aime bien le fait que l'image soit pas en plein dans le texte par défaut, et plutôt de les afficher seulement à la demande (un entrée dans le mailcap et je lance les images avec feh).

les citations des mails (j'utilise un éditeur externe). mutt met un > au début de chaque ligne, mais ne coupe pas les lignes à 80 caractères et je dois refaire la présentation manuellement.

En même temps des fois si la ligne en question est du code ou quelque chose dans ce style il est préférable qu'elle ne soit pas coupée. Et puis remettre un paragraphe en forme se fait par exemple sous vim avec un simple gq}, qui prend moins de temps que de restructurer le message de sorte à ne citer que ce à quoi on répond.

Mais pourquoi il n'est pas simplement livré avec des réglages sensés dès le premier démarrage ?

C'est comme vim ou emacs : aucune configuration ne pourrait d'emblée satisfaire tout le monde (même sur des trucs simples ou qui peuvent sembler évidents), donc plutôt que de proposer un truc qui ferait râler tout le monde ou presque et qui obligerait à modifier ou désactiver des options, on a droit à une configuration minimale et à nous d'aller chercher sur la doc ou les exemples ce qu'il nous faut.

Alors c'est sûr, on doit configurer tout un tas de choses au début, mais si on utilise mutt ou d'autres logiciels dans cet esprit c'est un peu qu'on l'a cherché quand même. Et l'avantage c'est qu'après on est tranquille : mutt est plutôt stable.

[…] je pourrais te rétorquer tout un tas d’arguments comme quoi c’est vachement d’efforts quand j’arrive sur une autre machine qui n’a pas vim, que ça dépend vachement du clavier, et que ça demande pas mal de temps à maitriser.

En même temps pour le coup je trouve ça assez vrai : à chaque fois que ça m'arrive je me retrouve à taper sans faire exprès <esc> bêtement pour passer en mode normal au lieu de saisir ma souris, et me retrouver avec un jj avant le curseur alors que j'étais sensé me retrouver deux lignes en dessous… Comme taper <alt>[1-9] pour changer de bureau alors que je suis pas sous xmonad et que je voulais faire un <alt><tab> en fait, ou <shift><alt><enter> et attendre en vain le lancement d'un terminal qui ne veut pas venir.

Mais question clavier c'est pas mieux : l'azerty et le qwerty je suis devenu un parfait incapable avec (à part pour taper setxkbmap), comme quoi si on ne s'entraîne plus jamais on finit par vraiment oublier.

En maitrisant le Bépo, on ne maîtrise quasiment que sa machine, on doit faire l'effort de basculer dans les autres dispositions dès que nécessaire.

On peut quand même utiliser n'importe quelle machine sous X, il faut juste apprendre à taper setxkbmap fr bepo en azerty ou qwerty. Ça fait très longtemps que je n'ai pas écrit autre chose que cette commande en azerty o qwerty (même pour l'installation de Gentoo : j'utilise SystemRescueCD et puis voilà, bépo est là). Il reste bien sûr les cas malheureux où il faudrait utiliser une machine sous Windows :( Aah, ça fait plusieurs années que ça ne m'arrive pas, pourvu que ça dure!

qui sont en fait grosso-modo des fichiers de configuration

Je dis ça mais je sais bien que ça peut être assez fastidieux quand même, bien sûr!

Ce sont les fichiers, pas l'idée qui sont sous licence hein.

C'est encore oui et non : mettre un copyleft sur les fichiers, c'est mettre une licence sur une poignée de fichiers très courts qui ne représentent pas du tout le boulot derrière, et qui sont en fait grosso-modo des fichiers de configuration pour xkb et de keymaps pour la console pour lesquels on n'a pas trente six mil choix de toutes façons pour arriver au même résultat pour la même idée. Donc un copyleft sur ces fichiers peut difficilement s'interpréter comme la volonté traditionnelle de protéger un effort d'implémentation particulier d'une idée donnée, que ce soit du code, de la doc, des .xcf de gimp, etc…

Fait gaffe il y a deux dvorak-fr, c'est assez compliqué.

C'est bien là le problème : c'est compliqué alors que ça ne devrait pas l'être. C'est pour ça que le mieux ce serait peut-être une licence permissive : ça ne gênerait personne et ça rappèlerait pour ceux qui auraient un doute que le bépo veut se distancer des erreurs passées du dvorak-fr ou autre.

Vu le boulot qu’il y a derrière, je conçois parfaitement qu’on veuille mettre une licence dessus.

Oui et non, beaucoup de théorèmes mathématiques ont beaucoup de boulot derrière, et ce n'est pas pour ça qu'on y mettrait une licence (bien qu'en pratique tout le monde mentionnera l'auteur sans y être obligé par loi…). Mettre des licences sur les idées, aussi compliquées soient-elles, c'est toujours dangereux. C'est un peu comme si quelqu'un mettait une licence sur sa configuration de postfix ou un autre logiciel.

Bref, c'est une pente assez glissante ces histoires, et d'ailleurs même pour le logiciel pour qu'une licence copyleft ait une raison d'être il faut bien que le code ait une longueur minimale (même la fsf recommende de pas mettre de copyleft sur un truc de moins de 300 lignes).

Pour le bépo, j'ai tendance à penser que la licence est là pour se démarquer du ridicule cc-nc-nd sur l'ancien dvorak-fr (qui dit en passant est bien pire que le bépo à simple coup d'œil il me semble).

Il y a aussi le fait qu'on n'a pas besoin de taper à la même vitesse tout le temps : typiquement on a besoin de taper très vite pour de la prose (on pense plus vite qu'on écrit), moins pour du code (le temps passé à réfléchir nous limite de toutes façons), et pour un raccourci clavier je dirais que 71G est déjà abrégé en quelque sorte.

Il faudrait une métrique qui compte le temps par léxème (du coup ça peut varier pas mal suivant quoi et en quoi on écrit) qui tienne compte de la compléxité en plus de chaque unité sémantique.

… si tu utilises la souri*e* …

Ça m'a fait sourire, ça.

Désolé, j'ai pas pu m'en empêcher ;)

Je suis d'accord que changer complètement les raccourcis de tous les logiciels a des inconvénients : le temps qu'on y passe, l'effort pour la mémoire, et le fait qu'on ne peut utiliser que son propre ordi après.

Mais comme je le dis plus haut : c'est loin d'être une nécessité. La plupart des logiciels (du moins ceux que j'utilise) utilisent des raccourcis mnémotechniques et non ergonomiques au sens physique donc en bépo ce n'est pas pire qu'en azerty ou qwerty. Pour certaines lettres on aura de la chance et ce sera plus facile, pour d'autres ce sera le contraire, mais au final ça doit être kif-kif. La seule exception qui m'est survenue est le hjkl de vim, mais au final ça m'a conduit à mieux utiliser vim plutôt que de m'acharner à me déplacer case par case. Et dans tous les cas, le résultat n'est pas pire que les raccourcis mnémotechniques <C-n>, <C-p> et je sais plus quoi qu'on trouve dans emacs avec une disposition azerty ou qwerty.

En attendant, Ctrl-c Ctrl-v en Bépo, c'est pas ce qu'il y a de plus doux pour les doigts.

Heu, c et v sont à côté aussi en bépo, et on les tape avec l'index donc a priori c'est plus facile (a priori, parce que je n'utilise jamais ce raccourci).

Pour faire des slides facilement, et exportables en html ou pdf (via beamer), il y a pandoc. C'est facile à apprendre : c'est du markdown à la base, avec des extensions. Par contre pour faire des choses compliquées c'est limité : on peut utiliser des templates latex ou html pour configurer un peu l'exportation, et dans le pire des cas modifier les fichiers obtenus.

Ceci dit, si on connaît bien beamer, et qu'on a de bons raccourcis clavier sur son éditeur de texte, et des préambules tout faits, on n'y gagne pas grand chose à moins de vouloir exporter vers html aussi pour une raison ou une autre.

Bien sûr pour logiciels genre vim, faut adapter […]

Pas forcément, parce qu'on on perd le côté mnémotechnique des touches en remappant, et mine de rien c'est gênant. En plus si on utilise beaucoup de logiciels à la vim, ça représente pas mal de boulot de tout remapper.

Alors, hjkl peut sembler indispensable, mais d'expérience ce n'est pas vraiment le cas (pour dire, j'ai rien remappé pour jouer à crawl qui utilise ces touches, mais aussi yubn pour les diagonales, et on s'y fait sans problèmes, d'ailleurs l'index est trop surchargé je trouve par défaut).

Et de toutes façons, quand on utilise plus de trois-quatre fois à la suite ces touches c'est en général qu'on ne se déplace pas de manière optimale.

Ceci dit, certains mappages sont bien sûr utiles, comme mettre à profit les lettres accentuées éèêàç en accès direct qui sinon ne servent à rien.

Par contre, quand il s’agit de la console, la méthode d’installation « à la main » est toujours de vigueur pour FreeBSD, OpenBSD/NetBSD, OpenIndiana et Minix.

Quand j'avais essayé OpenBSD il y a un peu plus d'un an j'ai pu choisir bépo dès l'installation, et ça marchait en console direct après. Après c'était du bépo limité vu que l'utf8 marche(ait?) pas en console sous OpenBSD.

Le mieux c'est de lire un tutoriel. À peu près n'importe lequel fera l'affaire pour ce que tu veux.

Par exemple pour apprendre awk par l'exemple

http://www.gentoo.org/doc/en/articles/l-awk1.xml

ou sinon regarde carrément le manuel de gawk

http://www.gnu.org/software/gawk/manual/html_node/Getting-Started.html

qui est très complet et se lit bien.

Le seul truc moche dans ta commande c'est le __, qui est juste un nom de variable non initialisée donc ne sert à rien mais gawk ne s'en plaindra pas (à moins qu'il soit là juste parce que tu as mis en gras et que tout ne s'est pas passé comme prévu). Une bonne raison d'ailleurs qui me fait préferer perl à awk même pour les choses simples c'est l'option -w (warnings), qui évite beaucoup de mauvaises surprises.

Sur ma version, la 0.2.3, j'ai pu constater ce problème avec des pdfs énormes avec des images (genre pgfmanual de tikz), et je serai content si le problème est arrangé. Ceci dit, si j'utilise zathura depuis un bon moment ce n'est pas parce qu'il serait léger en ressources, mais à cause de son interface, avec ses « avantages » très subjectifs : ergonomie à la vim, configuration à l'aide d'un fichier de configuration, etc… qui font que ça s'intègre bien avec le reste des logiciels que j'utilise. Donc je pense que souvent « léger » fait surtout référence à une ergonomie particulière de l'interface (la définition pouvant donc varier beaucoup d'une personne à une autre!).

Tous ces exemples supposent l'utilisation de Bash, GNU coreutils et GNU find.

Le find et le xargs d'OpenBSD ont aussi les options utilisées dans ces exemples, et je pense que ça doit être pareil pour les autres BSD. Il y a moins d'options qu'avec GNU find, mais il y en a quand même un paquet!

Ah, en y pensant, c'est mieux de rajouter -maxdepth 1 aux options de find, sinon find va se plaindre la deuxième fois…

Un truc comme :

find -name '*.JPG' -exec convert {} -verbose -resize 600x -quality 85 resized/{} \;

Après c'est pas vraiment plus court ;)