Aldoo a écrit 2794 commentaires

Le xterm en 80 colonnes s’en sort très bien : il va à la ligne tout seul quand on
dépasse.
Et puis, pour moi, du texte brut, c’est du texte sans mise en forme ! Si on ajoute des retours à la ligne sans valeur sémantique, ce n’est plus du texte brut, mais du texte formaté, mis en page, comme tu l’admets toi-même.
Du coup, tous les arguments que tu avances sont pour moi des arguments contre le préformatage statique en 80 colonnes.
Ainsi, les petits terminaux sont tout à fait adaptés au texte brut tel que je l’entends (mais pas au PDF en A4, par exemple !).
La vraie question, c’est s’il existe encore des clients qui ne peuvent pas faire par eux-mêmes ce niveau 1 de la mise en page. Sans doute, mais ils me semblent plus que marginaux, au vu des désagréments occasionnés par les 80 colonnes statiques dans les autres cas.

Un cas un peu à part est celui des messages avec citations imbriquées. Le symbole « > », utilisé pour la citation a une valeur sémantique qui est en dehors du champs du texte brut (comme je l’entends moi). Je pense que la seule manière un tant soit peu censée de les gérer est celle de Thunderbird, où ces symboles disparaissent au profit d’une (ou plusieurs) barre bleue à gauche, qui n’est pas gérée comme des caractères. Si au cours de l’édition, la ligne dépasse la taille de la fenêtre, il y a retour à la ligne dynamique, avec conservation de l’information qui dit qu’on est dans une zone de citation.
Le message envoyé in fine aura bien un (ou plusieurs) « > » au début de chaque ligne des zones de citation.
De ce point de vue là, kmail (que j’utilise pourtant, KDEiste invétéré que je suis) est une catastrophe, car il considère justement qu’il a affaire à du texte brut. Pire, jusqu’à récemment, il ne proposait pas la coupure dynamique (les développeurs ayant plus ou moins les mêmes arguments que les pro-80 colonnes qui s’expriment ici, peu importe que 99% des MUA aient cette fonctionnalité).

Ça me rappelle pas mal le blog de Shelley, tout ça. Le doute sur le degré qui plane jusqu’au moment où on lit la petite note.
http://www.shelleytherepublican.com/

En quoi des retours à la lignes dynamiques seraient-ils moins bien qu’une coupure statique à xx colonnes ? Au moins, là, on est sûr de ne pas avoir de barre de défilement, quelle que soit la taille de la zone d’affichage.

La coupure à 80 a été introduite pour pallier une insuffisance technique historique. Par politesse, il était bien de respecter cet usage.
Aujourd’hui l’utilité est beaucoup moins évidente. Pire, l’usage provoque des désagréments dans de nombreuses situations.
La logique voudrait qu’on fasse comme dans le temps : qu’on adapte l’usage aux besoins et à la technique, et non l’inverse.

C’est comme si à l’époque du charbon, on avait imposé un médicament contre, disons l’asthme, et qu’aujourd’hui un effet secondaire révélé par le rayonnement des bornes GSM nous donnait des boutons. Le bon sens voudrait qu’on arrête de prendre ce médicament. Toi tu dis qu’il n’y a qu’à mettre de la pommade en plus.
C’est complètement absurde.

Regarde comment ça marche dans un client mail bien foutu, tu seras surpris !

Je confirme que c’est pertinent, enfin juste, en tout cas !

J’ai ouvert dans kwrite parce que mon navigateur était configuré comme ça par défaut. Ce n’est pas nécessairement le meilleur choix, mais c’est éventuellement un choix légitime.
Cela n’empêche que l’argument du navigateur web est bidon : le navigateur web fait aussi le dynamic word wrap. Est-ce que DLFP est formaté en 80 colonnes, par exemple ?
Au pire, si tu veux limiter la largeur, il y a CSS (car, comme le dit Briaeros, le browser n’est pas fait, normalement, pour afficher du TXT, même si heureusement il permet de le faire !).
Et quoiqu’il en soit, si je veux lire du texte sur mon téléphone portable, j’espère bien que j’arriverai à le passer en moins de 80 colonnes de manière propre, même si je ne suis pas « la plupart des gens » !

Halte aux fournisseurs de contenu qui décident à ma place ce qui est mieux pour moi ! Le choix de la largeur doit appartenir au lecteur !

N’importe quel éditeur moderne fait le formatage dynamiquement.
Même le vieux notepad de Windows l’a toujours fait !
Je ne vois pas pourquoi le texte deviendrait illisible après quelques citations. Si personne n’ajoute met de retour à la ligne de la mise en forme, qui, lui, risque de parasiter le retour à la ligne dynamique.

Cette « recommandation » n’aurait de sens que si la proportion des utilisateurs qui édite encore ses textes sur un logiciel ne faisant pas la mise en page dynamique était majoritaire, car elle est en effet susceptible d’embêter à peu près tous les autres. Ceci est vrai en particulier dans le contexte actuel où les terminaux sont de plus en plus diversifiés. Je doute que mon téléphone portable puisse afficher 80 colonnes, par exemple !

Chez moi aussi il s’affiche correctement, enfin, tel qu’un fichier de 80 colonnes est censé s’afficher sur une largeur plus petite — c’est à dire en coupant avant, et en gardant malgré tout les sauts de ligne artificiels du fichier. En désactivant le retour à la ligne dynamique — ce qui est bien dommage pour la plupart des fichiers — on obtient bien un affichage 80 colonnes, mais aussi une barre de défilement horizontale, ce qui n’est guère mieux.

Le problème, ce n’est pas l’éditeur. Le problème, c’est le fait de formater un texte à largeur fixe.

M’enfin ce n’est pas si grave. Ce qui l’est plus, c’est de revendiquer cela comme une bonne pratique. Je veux bien croire que cela l’ait été dans le temps, à cause de contraintes techniques qui ne sont plus. Maintenant, il faut un peu vivre avec son temps. Ou bien il faut m’expliquer pourquoi cela serait digne de figurer encore dans la nétiquette de 2008 (au lieu de moinsser bêtement ! Cela dit, j’admets être hors-sujet, mais je guettais depuis quelque temps une occasion de pousser ce coup de gueule).

PS : quant à l’agressivité, faut pas pousser ! Ça s’appelle juste un coup de gueule. Je te prie de « remballer » ton ordre de remballage déplacé !
Est-ce que quelqu’un ici se sent réellement blessé par mon message, franchement ?

Tiens, tu surfes avec wget ?

Et ça se la pète avec cette f***ue règle des 80 colonnes !
Un fichier texte devrait se contenter du texte. Au logiciel utilisé pour le lire de faire un formatage aux oignons pour l’utilisateur, avec toutes les éventuelles contraintes d’accessibilité !
Là, chez moi, exemple con : le fichier s’est ouvert dans kwrite, qui pour je ne sais quelle raison a créé une fenêtre relativement petite, en tout cas avec environ 70 colonnes de texte. Vous imaginez le résultat : une ligne de 70, une de 10, une de 70, etc.

Il est grand temps que l’intégrisme de l’accessibilité déloge l’intégrisme des nostalgiques du VT100 !

Le pauvre, il ne faut pas l’accabler, non plus !

Ton raisonnement sur les bits prouve une seule chose : pour l’affichage final, 8 bits par canal suffisent amplement.
Le problème c’est quand tu veux traiter une photo 8 bits et que le résultat final reste potable.
Cas d’école : photo sous-exposée, on veut augmenter la luminosité et le contrate.
Sur l’image de départ, supposons qu’aucun pixel n’a une valeur supérieure à 2⁴ sur les 2⁸ possibles.
On aura beau appliquer toutes les transformations qu’on veut afin d’étaler les valeurs sur tout le spectre des valeurs, il restera que seules 2⁴ valeurs seront utilisées au total (sur 3 canaux, ça fait 4096 couleurs… ça fait peu).
Si on avait eu une photo en 16 bits, on aurait pu avoir un résultat final en qualité 8 bits.

Ce raisonnement est aussi utilisé pour l’audio, avec les cartes sons actuelles qui gèrent l’échantillonnage 24 bits à 192 kHz ou plus, là où le CD se contente de 16bits à 44,1 kHz.

Moui, mais le fait de devoir aller chercher le site est aussi un test de motivation. C’est déjà un filtre aux vœux et suggestions futiles et impulsives. Ne restent que les requêtes un minimum sérieuses.

Les forums Ubuntu, c’est typiquement :
A — À l’aide, j’ai un problème : je n’arrive pas à faire X.
A — up !
A — up !
B — tu as essayé de faire Y ?
C — me too, X' ne marche pas !
D — moi j’ai fait Z (NDLR : qui n’a rien à voir), et X" marche
E — me too !
F — me too !
A — ça ne marche pas !
… et souvent :
A — Ah ça y est, j’ai trouvé comment faire.
… et optionnelement, 6 mois après
G — j’ai le même problème, A, comment tu as fait pour le résoudre ?
En général, ça en reste là.

Malgré tout, si on s’en tient aux forums, c’est quand même avec ceux d’Ubuntu qu’on a le plus de chance de trouver une réponse, question de masse critique.
Mais les wiki de gentoo, c’est quand-même un peu plus efficace !
(même si Ubuntu et les autres distros ont aussi des wikis, il est rare qu’ils rivalisent de précision et d’exhaustivité avec ceux de gentoo !)

Quand ça pue, vaut mieux regarder où on marche !
(j’espère que c’était le pied gauche, paraît que ça porte bonheur !)

Ah non, c’est « verstanden », le participe passé :-p !

Et la somme « maudique », c’est sans doute la malédiction du pouvoir d’achat !

Oui, ça se branche et ça se débranche... comme les plugins npapi, par exemple… (qu’est-ce qu’on peut galérer à relancer 1000 fois son browser jusqu’à avoir enfin la bonne version de flash ou de java dans son about:plugins !)
Non, franchement, greffon n’était pas si mal.

Euh ? Moi je l’aime bien cette traduction !
Pas de barbarisme (genre mél ou cédérom !).
Clarté (on comprend le concept, et en même temps, il n’y a pas de sources de confusion dans le domaine informatique).
Que demander de plus ?

Non, vraiment, il y a de meilleurs exemples de traductions horribles.

M’enfin il s’est sans-doute dit qu’il valait mieux ça que douiller des bides !

Que ce soit un contre-exemple, je veux bien.
De là à dire qu’il est faux que l’anglais a un vocabulaire plus riche que le français, il y a un pas (mais je ne vais pas entrer dans le débat, c’était juste pour soulever ce point de logique) !

À mon sens bidouilleur suffit largement. Il n’y a pas de raisons de cantonner le terme à l’informatique.
J’ai l’impression que traduire hacker par bidouilleur et vice-versa marche quasiment toujours. Sauf évidemment pour l’usage abusif de hacker à la place de cracker (pour ne pas dire pirate, mais ce dernier terme est tout autant abusé !).

Je crois que tu n’as pas compris ce que je disais.
Certes l'espérance de vie était plus courte autrefois. Certes, il y avait des tonnes d’exemples de gens ayant vécu vieux (après tout, c’est normal : il suffit d'avoir eu de la chance et de ne rien avoir attrapé de grave, le fait d’avoir une bonne hygiène augmentant ces chances).
Mais ma petite phrase pointait aussi deux autres faits :
1 - si on meurt jeune, quelle qu’en soit la raison, certaines maladies n’ont pas le temps de se développer (certains cancers, en particulier).
2 - la société d'autrefois n'était pas aussi procédurière que la notre, et de toute façon avait bien moins d’exigences du côté de la sécurité et de l'hygiène. Quand on tombait malade, on ne pouvait s’en prendre qu’à soi-même (ou au bon dieu, ou à la providence).

Quant au quand, peu importe. J’ai dit trente ans, c’était juste un exemple. Chez les hommes des cavernes, c’était peut-être vingt, et au Moyen-Âge, quarante. Cela ne change rien au propos. Je ne crois pas qu’une société semblable à celle des cinquante dernières années ait déjà existé auparavant.

J’aimais bien aussi le coup des 5/2 qui répondaient avant que l’énoncé ne soit écrit entièrement. Impressionnant, vu le nombre d’énoncés différents qui existent !