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é).
[^] # Re: GCU-Squad
Posté par Aldoo . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 4.
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é).