dr_home a écrit 107 commentaires

Portable ? C’est totalement spécifique à TeX. UTF-8 a pour lui d’être utilisable en toutes circonstances (comme sur ce site web, par exemple).

Je veux dire que c'est de l'ASCII, supporté par la totalité des systèmes au monde ou probablement pas très loin.

Ton "œ", même en UTF-8, il faut que le destinataire utilise une police qui le contienne pour le voir, contrairement à "\oe".

Encore une fois, comme sur ce site par exemple, où nous n‘avons pas besoin d’un système de composition pour afficher les caractères que nous avons — c’est-à-dire, que j’ai ;) — envie d’afficher.

Mais la manière dont ce site web va s'afficher n'a rien à voir avec la locale. Firefox en locale C est capable de t'afficher de l'UTF-8...

Au fond ta locale va affecter le rendu de très peu de choses ; dès que tu vas sortir du texte brut, il y a de grandes chances que tu ne t'en aperçoives pas.

De plus, ce n'est pas UTF-8/Unicode en lui-même que je mets en cause, je trouve ça très bien, moi, UTF-8 ! ce que je mets en cause c'est le fait qu'on dise que c'est automatiquement meilleur que Latin9 et qu'en dehors de lui point de salut.

Sur un P.II avec moins de 100Mo de RAM, la question peut se poser, je trouve. D'autant si pour l'utilisateur le texte brut qu'il tape est du source (ex. LaTeX, Groff, HTML, etc. ) ou du README (contenu purement informationnel). Personnellement, je trouve que la mise en forme en texte brut est une plaie (quand il faut insérer un item dans une liste ordonnée, quand il faut se taper la re-justification des paragraphes -- avec qui plus est l'absence d'insécable qui génère d'horrible lignes commençant par un chevron ou deux points -- quand il faut insérer des notes en bas de pages, etc. ) qui selon moi ne donne que des résultats de qualité médiocre. C'est pourquoi, quand je veux une sortie léchée, je préfère prendre les outils faits pour ça.

Du coup, écrire un tchèque parfait en texte brut me paraît une lubie pas plus ni moins censée que pour d'autres vouloir économiser une poignée de secondes d'exécution sur un script.

Là où je ne suis absolument pas d’accord avec toi, c’est quand tu sembles dire que des contraintes techniques (ici, l’encodage des caractères) doivent dicter les comportements de l’utilisateur (ici, la façon d’écrire). Moi, je veux que ma machine s’adapte à mes lubies et non l’inverse, d’où mon choix de l’UTF-8 et de ses désagréments.

Non, le sens de mon message c'est que l'absence de contrainte ne fait pas des choses automatiquement meilleures et qu'on peut faire beaucoup avec peu, ce principalement parce que la technologie est secondaire par rapport à l'intelligence.

Tu n'as qu'à penser à l'anglais "international", par exemple, c'est plutôt approximatif du point de vue grammatical et formel, mais ça marche quand même bien quand on voit le nombre de gens qui arrivent à communiquer grâce à lui. Ce qui -- pour poursuivre l'analogie et être totalement clair, même si sur le fond je crois qu'on est d'accord -- ne veut évidemment pas dire que je considère à l'inverse les parfaits anglophones comme des pédants nuisibles.

je n’ai pas regardé, mais je suppose sur un système dont la locale est en_US.UTF-8, il considère que les pièces jointes sont en UTF-8 par défaut, ce qui est exactement ce que je veux (si je me mettais à utiliser un autre encodage, là je serais sans doute obligé de le spécifier manuellement — c’est exactement ce que je ne veux pas).

Pas du tout, une locale fr_FR est Latin1, une locale fr_FR@euro est Latin9. Les langues ont un encodage par défaut, ISO-8859-1 pour le français, mais POSIX prévoit qu'on peut spécifier un encodage à la fin de la locale, ce que tu fais quand tu choisis fr_FR@euro ou fr_FR.utf8.

Mon client envoie par ailleurs les mails dans l'encodage qu'il juge le plus approprié : ASCII quand j'écris en anglais, ISO-8859-1 si aucun caractère Unicode n'est requis.

Avec un raisonnement comme le tien, Donald Knuth se serait contenté du rendu médiocre de son livre The Art of Computer Programming que lui proposaient les logiciels de composition des années 70, et il n’aurait jamais écrit TeX…

Et qu'était-ce alors TeX, si ce n'est un moyen d'avoir une typo de qualité à partir de l'ASCII ? Relativement à l'histoire de TeX, ça ne fait pas si longtemps qu'on peut mettre de l'UTF-8 dans les codes sources au lieu d'écrire \moncaracterespecial, qui reste la solution la plus portable (mais la moins pratique, j'en conviens).

TeX vise à produire des documents imprimés de qualité, c'est tout autre chose que le texte brut qui ne sera jamais optimal (n'es-tu pas sensible aux ligatures, aux indentations, et à la justification des paragraphes ? )

À chaque sortie ses exigences, que les écrivains rendent un tapuscrit non typographiquement soigné n'implique pas que l'édition finale le sera. Ça n'empêche juste pas de produire des choses intéressantes.

Mais dans la vie réelle (© 2011 dr_home), tes besoins et tes attentes ne sont pas ceux de tout le monde.

Ai-je jamais soutenu autre chose ? ai-je même contesté que tu puisses arbitrer qu'écrire le Tchèque en texte brut est une raison suffisante pour passer à l'UTF-8 ? c'est vous qui depuis le départ contestez que Latin9 est un choix aussi rationnel et valable qu'UTF-8...

Personnellement, je préfère accepter de perdre un chouia de performances pour ne pas avoir à me poser la question de l’encodage. L’ordinateur n’est-il pas là pour me simplifier la vie ? Quand j’écris avec un stylo sur du papier, je n’ai pas à me demander quel encodage je dois utiliser pour tracer tel caractère…

Tu n'auras pas le choix, tu te poseras toujours la question de l'encodage. Un fichier texte, tant que tu n'en connais pas l'encodage, c'est juste du binaire. UTF-8 n'y change rien. C'est pas pour rien que sur une page HTML bien formée, tu as une déclaration de l'encodage qui doit arriver le plus tôt possible... Quand des applications doivent manipuler des documents extérieures, UTF-8 ou pas, il est essentiel de déclarer les encodage de ceux-ci (qui après peut être latin1, UTF-16, UTF-32 ou ce que tu veux).

Je ne parle pas un mot de serbe, de suédois ou de polonais, ce qui n’empêche pas ma bibliographie de comporter des travaux de dénommés Radosavljević, Čuboňová, Meşe, Kågedal, Macůrek ou Chełstowska. Autant de noms que je peux avoir avois besoin de citer dans un document bien franco-français destinés à des seuls francophones de France.

Biographie que tu publies en texte brut ? non, tu le feras en PDF ou en HTML, langages dans lesquels tu n'auras aucun soucis et qui n'impliquent aucune locale spécifique.

De plus, combien de gens vont connaître la différence de prononciation entre Macůrek et Macurek ? est-ce un crime impardonnable décrire « Dostoïevski » au lieu de «Достоевский» ? la latinisation des noms a-t-elle jamais été un frein aux échanges culturels ? un bonne partie du français lui-même, pour pousser encore plus loin, n'est-elle pas juste une latinisation du grec ?

Enfin, n'oublie pas également que des générations d'écrivains ont employé des machines à écrire à disposition azerty, puis des traitements de texte avec des encodages limités (pas de cadratin &cie.). Ça ne les a pas empêché d'écrire du français correct, ni de faire évoluer la littérature. Le double-guillemet droit en lieu et place du chevron fait sûrement s'étrangler les vieilles barbes de l'Académie Française, il n'empêche pas le français d'être du français.

Je ne parle pas spécialement pour toi, mais les VRP du progrès ne laisseront de me fasciner : à les entendre, aujourd'hui est déjà hier et hier est juste impossible. :)

Tu n'as toujours pas démontré que dans l'ensemble, ça a un impact significatif sur les perfs globales de la machine

Je sèche, homme admirable, as-tu une idée de comment mesurer une telle chose ? si je te disais démontre-moi qu'UTF-8 n'a aucun impact global, que pourrais-tu répondre à part que ça paraît globalement fluide ?

Or globalement, ça signifie en mode graphique et en console. En mode graphique, c'est impossible à quantifier pour des raisons déjà évoquées. Par exemple, si sur un même navigateur tu charges la même page en laissant un écran blanc jusqu'à ce que la page soit entièrement calculée ou en affichant progressivement d'abord les cadres les uns au dessous des autres, puis les cadres positionnés, puis les images, le deuxième rendu va te paraître aller plus vite que le premier.

Pour ce qui est de la console, c'est très différent car on n'est pas dans quelque chose de continu. On admet en général qu'on perd l'impression de fluidité aux alentours d'une demi-seconde de traitement. Donc, UTF-8 va avoir beaucoup plus d'impact sur le ressenti en console, d'autant que la machine est faible. Moi qui utilise la console intensivement (le nombre d'applications graphiques que j'utilise régulièrement se compte sur les doigts d'une main) et scripte énormément je le constate très fréquemment. C'est pourquoi si j'avais une petite/vieille machine, j'étudierais sérieusement l'option 8bits pour en tirer le meilleur parti.

Ton dernier commentaire: 1323 octets en Latin-9, 1367 octets en UTF8. "Perte" de 3%. Quelle misère!

Sur un disque de moins d1Go où tu dois précautionneusement arbitrer entre le système et les données, ça peut être non négligeable. Et puis je pourrais faire comme toi: démontre-moi que mon commentaire est représentatif de ce qu'on écrit globalement en français. Peut-être que ce n'est pas 3 mais 10 ou 15% de pénalité dans la réalité !

C'est exactement le genre d'optimisation comme ceux qui compilent pour un CPU super-précis par rapport au défaut "c'est pour optimiser, c'est démontré", juste que c'est pas du tout rentable et il reste juste quelques rares masochistes à le faire, pareil pour garder Latin-9 : tout va bien, jusqu'au jour où tu devras partager le fichier avec un gus qui n'a pas cette locale (si si, ça arrive, on vit dans un monde qui s'afranchit des frontières), alors qu'avoir UTF-8 simplifie grandement la vie au prix d'un pauvre 3% de plus en espace disque et à peine plus de CPU. Heureusement qu'il y en a qui regardent l’intérêt réel, maintenant à a toutes nos distros en UTF-8.

Sauf que dans la vie réelle, ma glibc me permet de décoder/encoder les fichiers comme je veux (fais un iconv -l, pour t'en convaincre) et donc de partager avec n'importe qui.

Sauf que dans la vie réelle, j'en n'aurai même pas besoin parce que vim me permet d'éditer avec l'encodage de mon choix.

Sauf que dans la vie réelle, la seule langue que je baragouine à part le Français c'est l'Anglais, donc afficher le Cyrillique, les Kanjis ou l'Arabe, ça ne m'avance pas beaucoup par rapport à une pâtée 8bits.

Sauf que dans la vie réelle, les distros pour vieilles machines balancent les locales à part POSIX/en_US pour gagner de la place.

Sauf que dans la vie réelle, j'ai passé des années en Latin9 sans en souffrir plus que ça.

Est-ce qu'au moins, dans la vie réelle, tu te rends compte que tu en es à prétendre connaître mieux que moi mes besoins et l'usage que j'ai de ma machine ?

Apparemment, il est résolu.

Tant mieux, ça faisait un bout de temps que ça traînait. Bon après, il faudrait voir en usage réel. Si tu veux t'amuser, tu peux essayer ce petit bout de AWK, qui simule ce que les perleux connaissent bien sous le nom de "slurp" (le fichier est traité comme une chaîne):

BEGIN { RS="\033"}
{BUFFER = BUFFER $0}
END{
  while(match(BUFFER, /e/)) {
    sub(/e/, "", BUFFER)
  }
}

time awk -f funny.awk /etc/services 

real    0m36.394s
user    0m34.407s
sys     0m0.019s

time LC_ALL=C awk -f funny.awk /etc/services 

real    0m0.910s
user    0m0.905s
sys     0m0.002s

time LC_ALL=C oawk -f funny.awk /etc/services 

real    0m3.633s
user    0m3.619s
sys     0m0.004s

L'implémentation GNU awk a en général une très bonne tenue, on voit même ici que dans un environnement 8bits, elle se comporte mieux que celle de Kernighan (AWK = "Aho Weinberger Kernighan", ses fondateurs), qui n'a pas de support pour les caractères multi-octets.

La nette dégradation des performances vient du fait que pour positionner la variable implicite RSTART (le début dans la chaîne principale de la sous-chaîne décrite par la regex), awk est obligé de savoir ce qu'est un caractère et donc de sortir du confortable "1 octet = 1 caractère". Bref, dès qu'on a vraiment besoin (c'est une longue chaîne) de s'appuyer sur une représentation UTF-8, on paye le prix (par bonheur, on peut souvent se contenter d'une représentation 8bits).

J’admets volontiers que la période de transition, quand on a des trucs déjà en UTF-8 d’un côté et d’autres trucs encore en latin-1 de l’autre, est délicate, surtout quand le support d’UTF-8 par les logiciels est encore fragmentaire

Disons qu'une fois que c'est fait, on n'a plus vraiment envie de se retaper tout dans le sens inverse. :)

Oui, le problème de grep est connu depuis longtemps, mais doit être lié à la manière dont la commande est codée, de telle sorte qu'il n'est pas simple de le résoudre. C'est néanmoins un cas intéressant car grep reste une commande très utilisée malgré ça.

Pour les autres benchs, c'est sûr que sur une machine "normale", ça n'a pas d'impact sensible hormis quand on fait des scripts élaborés. Et encore, une fois qu'on a pris le coup de systématiquement forcer la locale à C (ce qui est malheureusement impossible avec AWK), on résout pas mal de soucis ; ce sont juste des petits trucs à savoir.

En fait, ma position ici vient du fait que je suis passé de Latin9 à UTF-8 et que, rétrospectivement, je trouve que ça m'a apporté (relativement) plus de complications que d'avantages concrets. C'est très vivable au quotidien -- à part mes scripts et des trucs comme xdvi et xmessage, pas de ralentissement majeur à déplorer -- mais si c'était à refaire aujourd'hui, ça me paraîtrait tout aussi sensé de rester en Latin9. C'est pourquoi je pense que c'est une option d'autant plus à étudier si on a une machine un peu vieille avec un petit processeur et un espace disque limité (un fichier encodé en UTF-8 prend plus de place que sa contre-partie ISO, la faute aux caractères non-ASCII codés sur deux octets au lieu d'un).

Encore une fois, merci de bien vouloir lire (ie. essayer de comprendre le sens et les nuances de ce que l'autre a voulu faire passer) avant de critiquer.

(alors qu'il y en a, par exemple la compatibilité avec les programmes ne supportant pas UTF-8).

Ça tombe bien, je l'ai évoqué dans mon premier message.

Ca gène d'autres personnes qu'on écrive "ss" à la place de ß. Et toi, tu es prêt à écrire hospital à la place d'hôpital car on aurait la flemme de mettre le o avec accent circonflexe dans Unicode et dans ton clavier?

Il se trouve que l'ISO-8859-15 permet d'écrire un français que je juge très correct (et même de l'allemand, si tu veux, il y a le estzett -- dont les les Suisses se passent visiblement très bien), ce n'est pas une supposition, c'est un fait. Donc, la question de rester ou non en ISO-8859-15 pourrait se poser (par rapport à l'usage du système, à la configuration matérielle, etc. )

Je rappelle de plus qu'on parle ici de la locale, qui n'affecte en rien le support d'Unicode par les applications qui en on vraiment besoin (navigateurs, clients mail, etc. )

La base de la programmation Shell, jusqu'à preuve du contraire, consiste à récupérer la sortie d'une commande -- une sortie texte, donc -- pour la traiter avec une autre commande (c'est pour ça qu'on a inventé le tube). Ce que je montre touche donc le cœur de la programmation Shell, et tous les scripts seront donc plus ou moins touchés. Évidemment, si pour toi un script Shell, c'est deux mv et trois cp, ça pas changer grand chose, mais ça, ce n'est pas de la programmation Shell.

Concernant Perl, j'ai écrit que c'était sa grande spécialité, pas sa spécialité exclusive. Être agressif est une chose, mais ce serait sympa de lire les messages en entier au préalable.

Concernant les distros UTF-8, ça ne ce voit pas pour la bonne raison que la locale est généralement positionnée en toute fin d'init et qu'au fond il y a peu d'outils Shell dont on se sert intensivement et quotidiennement*, sauf à les programmer soi-même. Par ailleurs, la plupart des utilisateurs emploient des interfaces graphiques, où évidemment ça ne se sent peu ou pas (tu n'attends pas de retour de prompt, et beaucoup de chose sont montées et gardées en mémoire avec la première exécution).

* un contre-exemple, si tu veux : Slackware, dont les outils de gestion sont en Shell et qui du coup force certaines opération à être en locale C.

Comme je le dis, c'est une question d'équilibre entre besoins et désagréments (je ne suis pas en train de crier « vive l'ISO ! » ). Moi ça ne me gène pas d'écrire "--", "...", et "ss" au lieu de cadratin, trois petits points et Etset. De toute manière mon clavier ou/et ma police ne me permettront pas de couvrir tout Unicode (je ne sais même pas faire un cadratin sur le mien), donc j'aurais besoin tôt ou tard d'un outil (autre que vim) pour abstraire tout ça. À chaque fin le bon moyen, c'est tout ce que je soutiens ici, en fait.

Oui. Comme la mise en forme. Supprimons tout!

Comme la conclusion de mon message, tu veux dire (on n'a pas tous des super-machines de la mort) ?

Je sais pas ce que tu fais de tes scripts, mais au pif je dirai que 99% des scripts se contrefoutent de la locale.

Prends les scripts qui font du traitement de chaînes (ce qui est un peu la base du Shell) :

$ seq 10000 >/tmp/out
$ time grep 7 /tmp/out >/dev/null

real    0m3.196s
user    0m3.190s
sys     0m0.002s

$ time LANG=C grep 7 /tmp/out >/dev/null 

real    0m0.003s
user    0m0.001s
sys     0m0.001s

$ time sed /7/p -n /tmp/out >/dev/null 

real    0m0.015s
user    0m0.011s
sys     0m0.003s

$ time LANG=C sed /7/p -n /tmp/out >/dev/null 

real    0m0.010s
user    0m0.008s
sys     0m0.001s`

$  time  awk '{print length($0)}' /tmp/out >/dev/null

real    0m0.020s
user    0m0.018s
sys     0m0.002s

$ time  LANG=C awk '{print length($0)}' /tmp/out >/dev/null

real    0m0.012s
user    0m0.008s
sys     0m0.002s

Tous les utilitaires sont plus ou moins ralentis. Et là dans ces tests, je suis mignon parce que ce sont de toutes petites chaînes, mais plus les chaînes traitées vont être longues (genre quand tu traites un fichier comme une seule chaîne), plus ça va se sentir (il m'arrive de compter la différence en minutes lorsque ça se couple avec de la recherche intensive de fichiers). Or, on a rarement besoin de s'appuyer sur une représentation correcte des caractères qui ne sont pas dans l'ASCII.

Note également que je ne suis pas le seul à mentionner le coût d'UTF-8, Perl, dont c'est pourtant la grande spécialité, le documente même dans perlunicode :

Speed
   Some functions are slower when working on UTF-8 encoded strings than on byte encoded strings.  All
   functions that need to hop over characters such as length(), substr() or index(), or matching regular
   expressions can work much faster when the underlying data are byte-encoded.

   In Perl 5.8.0 the slowness was often quite spectacular; in Perl 5.8.1 a caching scheme was introduced
   which will hopefully make the slowness somewhat less spectacular, at least for some operations.  In
   general, operations with UTF-8 encoded strings are still slower. As an example, the Unicode properties
   (character classes) like "\p{Nd}" are known to be quite a bit slower (5-20 times) than their simpler
   counterparts like "\d" (then again, there 268 Unicode characters matching "Nd" compared with the 10
   ASCII characters matching "d").

Je prends n’importe quel ouvrage en anglais sur mes étagères, n’importe quelle page et n’importe quel paragraphe, je tombe instantanément sur plusieurs caractères ne figurant pas dans une table ASCII.

En « texte brut », oui, mais en général les ouvrages ne peuvent se permettre d'être écrits en "texte brut". Ils ont besoin de mises en forme beaucoup plus élaborées qui supposent des outils auxquels les caractères "spéciaux" (disons "précis") ne posent aucun problème.

Je trouve de plus qu'en ISO-8859-15 (fr_FR@euro), on arrive quand même à écrire très correctement le français. Suffisamment, en tous les cas, pour se demander s'il est souhaitable de passer en UTF-8. Car UTF-8 a un coût au niveau des performances générales, n'importe quel script shell allant plus vite avec une locale forcée à "C" (ASCII). C'est certes vivable au quotidien, mais quand même sensible (enfin, sur mon vieux P.IV, avec un dual ou quadri-Grouik, je ne sais pas). Bref, il n'y a pas àmha de bonne solution dans l'absolu, juste un équilibre à faire entre les besoins réels de précision et les désagréments qu'on est prêt à supporter (commandes plus lentes ou qui ne marchent tout simplement pas).

Soutenir l'anarcho-aristotélisme contre un anarchisme strictement platonique, il fallait oser.

Pour les allergiques à Thunderbird qui veulent quelque chose de simple à l'usage, il y aussi Sylpheed qui est très bon : [http://sylpheed.sraoss.jp/en/features.html] :)

C'est pas possible de définir des raccourcis claviers ? ou mieux, de lancer les applications usuelles automatiquement au démarrage de la session ?

Personnellement, je sais que quand ma fluxbox m'a lancé dès le démarrage mon client de courriel, mon navigateur web et un terminal, j'ai a peu près tout le nécessaire ; pour le moins commun, j'ai les raccourcis clavier ou un menu clic-droit tellement étique qu'il est difficile de s'y perdre.

J'ai vraiment du mal à saisir ces histoires de concepts ergonomiques... quand j'ai à faire un bureau pour un utilisateur qui n'ira pas creuser au delà de ce qu'il a sous le nez, je mets juste une fluxbox avec un menu clic-droit contenant juste le nécessaire et rappelant pour chaque item le raccourci clavier qui lui est associé (une vingtaine d'applications doit couvrir à peu près tout ce qu'on fait usuellement ou moins usuellement avec un PC) ; suis-je vraiment si à côté de la plaque que ça en terme de simplicité et d'ergonomie ? :\

Oui, à part l'encombrement du disque, je ne vois guère ce qui plaide en faveur de Lout au regard de LaTeX : la syntaxe est au moins aussi verbeuse, le maintien du processeur nettement plus incertain, et les performances de ce que j'ai vu très moyennes (chez moi la compilation du manuel d'utilisation, bourrée de références croisées, prend des plombes et harasse le CPU, qui pour sa part titre quand même à 2.66Ghz)...

Quant à la macro ms, je l'ai d'abord choisie ici parce qu'est c'est celle que j'utilise. Et je l'utilise parce que lorsque j'ai commencé à étudier groff, il m'a semblé que c'était la macro la plus simple pour commencer - et finalement, je n'en ai pas essayé d'autres.

Effectivement, ça cadre avec ce qui ressort des quelques bribes d'infos qu'on trouve à ce sujet sur le net ; à savoir que ms est moins puissant que mm, mais qu'il demeure suffisant dans la plupart des cas et est plus facile à apprendre. Merci pour ces précisions. :)

+1

Markdown est vraiment bien pensée, àmha ; partir du mail était vraiment une bonne idée. Les seuls reproches que je lui ferais sont de contraindre l'indentation du source en en faisant une clé de formatage pour le verbatim (j'ai horreur qu'on contraigne l'indentation du texte que je tape), et peut-être, mais c'est moins grave, d'avoir un formatage de base flottant (on peut par exemple user de ** ou de * pour produire du gras).

Par contre, je ne suis pas sûr qu'on la retrouve aussi fréquemment que ça. Il faut bien voir que les clés de balisage doivent être prises dans l'ASCII de base pour être portables ; ce qui une fois qu'on a retiré l'alphabet et les chiffres doit laisser tout au plus une trentaine de caractères ; il n'est partant guère étonnant que toutes les syntaxes wiki se ressemblent. :)

De rien. :)

Pour ce qui est de la comparaison avec la syntaxe LateX, il serait plus fair-play de faire une comparaison avec TeX, question de génération. Mais même avec LaTeX, il suffit de jeter un œil à par exemple article.cls (fichier de classe), pour être saisi d'effroi.

Au delà, c'est question de goût ; personnellement et tout en me débrouillant avec la fabrication de macros et de classes , je trouve LaTeX trop verbeux et j'ai de plus en plus en horreur le balisage via contre-obliques, crochets et accolades (sur un clavier azerty, ça relève de la torture). *roff tombant quant à lui plus ou moins dans les mêmes travers (l'obligation de mettre les macros en début de ligne étant àmha sa tare propre), j'ai tendance à mettre les deux formats à égalité.

En fait, je les pratique plus comme format cible que comme format source, car ce n'est guère difficile de faire des choses à la markdown (traiter le formatage courant en wiki et laisser passer le code plus complexe) avec ce type de format ; il suffit de savoir ce qu'on veut obtenir en sortie.

Marrant, personnellement j'ai plus de problèmes à employer les macro .B, .BI, etc. que les opérateurs de fonte. Ceci me paraît plus naturel :

Du \fBtexte gras\fR en démo.

Que cela :

Du
.B texte gras
en démo.


Question d'habitude, sans doute (les opérateurs font plus « langage à balise » ). En parlant de question, une petite en passant : pourquoi avoir choisi les macros ms, alors que mm paraît aussi complet, si ce n'est plus, à parcourir leurs manuels respectifs ? :)

Je doute que txt2tags fasse des pages manuel en natif... il doit tout au plus faire du texte formaté selon un jeu de macros *roff (man) qui, utilisé par *roff, permet de formater des pages de manuel. Il est donc au mieux au dessus de *roff, mais en aucun cas ne s'y substitue ; je parierais même qu'il n'offre qu'une petite partie des possibilités du jeu man.

Pour ce qui est de LaTeX, il y a de bons arguments en faveur de Groff : peu d'encombrement par rapport à une distro LaTeX (rapport 1 contre 200, même avec une installation LaTeX au cordeau), disponible quasiment partout en standard pour les macros basées troff et, surtout, la possibilité d'une sortie sur terminal ; pour tous les petits documents, c'est vraiment génial de pouvoir les lire directement sans passer par un format et un lecteur (pdf, dvi, html) intermédiaires.

Bien sûr, la syntaxe paraît horrible, mais un texte de base LaTeX est aussi une horreur dès qu'on cherche à faire quelque chose de chiadé ; c'est pas pour rien qu'il y tant de classes de document et de paquets de macros LaTeX, mais tout simplement parce que la maîtrise des macros est indispensable pour se servir sérieusement de ce genre d'outil et commencer à s'amuser. De plus l'exemple *roff montré est issu d'un très vieux paquet de macros, maintenu tel quel en raison de vieilles compatibilités ; man est beaucoup plus propre et parfaitement utilisable en direct.

Merci à l'auteur de la dépêche d'avoir pris le temps de mettre en avant les macros ms, ça fait longtemps que je cherche un moyen décentralisé de formater et lire mes notes sans me coltiner la synchronisation source <-> sortie et passant outre la rigidité formelle de man . La seule chose un peu gênante, qui l'est déjà avec man, c'est qu'il semble impossible de spécifier dans le document source l'encodage de celui-ci ; résultat, sur un device utf8, un source UTF-8 est encodé deux fois lors de l'affichage... enfin, ça doit pouvoir se contourner, et c'est indéniablement une piste à creuser. :)

* « 2 + 2 = 5 » (à ce slogan, Winston réagit sur son journal en déclarant : « La liberté, c'est la liberté de dire que deux plus deux font quatre. »)

Ce n'est pas un slogan, mais une citation des Carnets du sous-sol de Dostoïevski. Le narrateur soutien exactement l'inverse de Winston (ce qui n'est guère étonnant), à savoir que si tu arrivais avec la même force que l'axiome 2 + 2 = 4 à démontrer à un homme que le bonheur est de suivre telle voie, il s'évertuerait malgré cela à faire comme si 2 + 2 était égal à 5, juste pour exercer sa liberté et être encore un homme. :)

ben je ne sais pas, mais à mon avis tu n'as pas dû l'utiliser de façon très intensive, pour penser ça
:D
Faudra que je la ressorte celle-là : -- Moi les épinards, je trouve ça dégueu ! -- Tu dis ça, c'est juste parce que t'en as pas mangé intensivement.

Mais non, effectivement, je ne l'ai pas employé beaucoup. C'était peut-être au niveau du HTML que c'était pas top top. Honnêtement je ne sais plus et je concède tout à fait que ça ait pu changer depuis.

Les contextes spécifiques permettent justement de créer un syntaxe spéciale suivant les besoins, soit en fonction d'un document particulier (divers sites internet par exemple), soit en fonction de la sortie (un livre papier, un ebook, une page internet)

J'ai bien compris, mais c'est la pauvreté de l'approche que je critique. Loin de moi l'idée que faire une farandole de awk et de sed soit une panacée en terme de gestion de document, c'est justement pourquoi faire de la regex ligne à ligne en amont et en aval en baptisant ça "système de macros" me dérange.

La ligne en tant que clé de manipulation, c'est vraiment la misère. Ça manque àmha d'abstraction, qui permettrait de définir et de manipuler des structures. Évidement, cela suppose que la syntaxe ait une certaine rigidité, des limites claires, que l'emploi du preproc empêche précisément..

Bref, vu ses connaissances dans ces 3 domaines, s'il a imaginé txt2tags en incluant les regex directement dedans, je pense pouvoir lui faire confiance, c'est qu'il a dû trouver cela plus pratique que de dire à ses utilisateurs RTFM sed et awk.

On sent effectivement une approche très shell des choses... avec un langage comme python, plutôt que le présent bricolage, j'aurais pensé une extensibilité par script, en héritant les objets de base pour adapter proprement la syntaxe à ses besoins.

À part ça je trouve l'argument "il a beaucoup fréquenté" assez moyen. Prends quelqu'un comme Brian Kernighan, qui a entre autres accompagné le développement d'UNIX, co-écrit la bible du C avec l'auteur du langage Dennis Ritchie, et enseigne aujourd'hui la programmation à Princeton. Tout cela n'empêche pas que dans le manuel de son implémentation de AWK (le "K", c'est lui) on trouve :

BUGS
There are no explicit conversions between numbers and strings. To force an expression to be treated as
a number add 0 to it; to force it to be treated as a string concatenate "" to it.
The scope rules for variables in functions are a botch; the syntax is worse.


Connaître un domaine "à fond" n'a jamais empêché d'avoir de mauvaises intuitions, ni heureusement l'humilité de le reconnaître...

Ce qui veut dire que le code ne sera pas interprété en HTML par exemple, je me trompe ?

D'où, on en revient à ce que je disais plus haut, la source unique pour n sorties tient du mythe. Txt2tags me fait plutôt penser à un Markdown qu'on peut appliquer au choix à telle ou telle sortie qu'à un véritable système de documentation universel (qui -- en admettant que ce soit possible -- ne peut être de mon point de vue qu'une usine à gaz, tant cela suppose un niveau d'abstraction poussé). Je me demande en fait si on aurait pas gagné en ergonomie et en qualité de syntaxe en limitant clairement a priori les sorties supportées...

Txt2tags permet également de modifier les exportations finales grâce à un puissant système de macros et de regex, étendant de façon illimitée les possibilités de bases.

Si j'en crois le tutoriel qu'a écrit l'auteur de la dépêche sur le site du Zéro, en gros ça réinvente le tube shell. Parce que le preproc et le postproc qui appliquent une regex ligne par ligne, chez moi ça s'appelle sed et awk (et encore, c'est faire peu d'honneur à ces deux merveilleux outils).

À mes yeux, txt2tags se heurte aux mêmes écueils que les autres pour ce qui est de la course au Saint Graal (une source légère et n sorties de qualité), à savoir que plus il y a de sorties, plus est petit leur dénominateur commun, et donc plus la syntaxe intermédiaire va être soit pauvre (on colle à ce qu'on peut aisément décrire dans tous les langages), soit incohérente (on crée des contextes spécifiques à certaines sorties, ce que précisément ladite syntaxe visait à éviter).

Je trouve ça gros de faire passer le B-A-BA de la moulinette depuis que la moulinette est moulinette pour une super-fonctionnalité : il suffit que le soft lise depuis stdin et écrive sur stdout pour obtenir la même chose, avec en plus les outils de son choix et sans cradouiller la syntaxe en amont. Parce que le preproc est àmha vraiment ce qui ressemble le plus à une fausse bonne idée ; avec un système comme ça, il est impossible de connaître a priori la structure d'un document t2t et donc d'envisager manipuler le format avec un outil tiers.

Bref, je ne dis pas que txt2tags est un outil sans valeur (même si pour l'avoir testé il y a quelques années, j'avais été déçu par la qualité des sorties), mais je ne vois pas trop ce que ça apporte de révolutionnaire en terme d'approche et de qualité d'implémentation par rapport à une énième compilation de moulinettes.

Mes 2¢

... c'est un Arthur Martin. Sept boutons, pas de fioriture, pas de superflu, je mets la vaisselle dedans, le liquide de nettoyage, je le démarre et roule ma poule, quand je sors la vaisselle, elle est propre.

Voilà, je tenais à ce qu'on sache que pour la vaisselle, Arthur Martin, c'est bien mieux que Linux.

Ah oui, et puis j'ai un ordinateur aussi... mais si ! vous savez, une des ces grosses calculatrices qui a mal tourné. Et là, bin sous Linux, sous Windows, sous BSD, il compte... même sous Plan9, il fait son boulot, il compte. Faudrait qu'un jour, j'arrive à déterminer exactement tout ce que je veux qu'il compte et comment, comme ça je pourrai parler d'autre chose que de la vaisselle sous Linux...