karchnu a écrit 414 commentaires

Tout le monde n'est pas sous Linux, et même sous Linux tu n'es pas forcé d'utiliser les outils GNU. Là je suis sur OpenBSD et apporter un peu d'amour aux autres OS ne fait pas de mal.

Ton od a des extensions qui ne sont pas portables. Je n'ai pas --width par exemple.

Attention, soelim est fourni de base avec troff, et pourrait être réimplémenté en 5 lignes de code. ;) Et au pire, tu peux t'en passer et faire un grep -R, ce sera juste pas dans l'ordre.

Quant à XPath, ça ne permet pas que de récupérer les noms de programmes dans le texte mais aussi les noms de programmes mentionnés dans les see also ou en tant que termes d'un glossaire.

Je n'ai pas compris. Je ne connais pas le fonctionnement de DocBook.

Je suppose que see also est une section balisée comme telle dans DocBook. Si c'est le cas, il n'y a pas d'équivalent à ce que tu dis dans troff. Cette section pourrait être implémentée entre deux appels de macros .SEE_ALSO1 et .SEE_ALSO2 et à l'intérieur tu pourrais y mettre l'appel à .APPLICATION comme partout ailleurs.

Pour moi l'utilisation de XML est rédhibitoire. Même en tant que simple format intermédiaire de sérialisation je suis contre.

Pour troff, récupérer des noms de programmes dans le texte :

soelim doc.ms | grep "^.APPLICATION"

Pas besoin d'outils spécialisés.

J'aimerai bien utiliser od, mais je n'ai pas su lui faire sortir une entrée en une colonne hexadécimal. Je trouve cet utilitaire très bizarre d'ailleurs, je ne comprends pas le choix de mettre plein d'options pour spécifier une sortie octale avec 1, 2 ou 4 caractères par ligne, des options pour des sorties hexa avec 2 ou 4 caractères par ligne, une option -N pour ne convertir qu'un certain nombre de caractères là où on a déjà d'autres outils pour faire ça (comme head)… c'est un peu le foutoir.

Du coup, si quelqu'un arrive à faire, avec des outils de base, l'équivalent de xxd -p -c 1 pour convertir l'entrée en hexa sur une seule colonne et xxd -p -r qui fait l'inverse, je suis preneur !

Je suppose qu'il y a un coup à jouer avec od suivi de awk et sed si on serait joueur, mais c'est quand même plus long et pas très lisible, donc bon… j'hésite.

Oui, il est possible qu'il ré-encode pour le découpage, et oui on peut utiliser copy. Je ne m'étais pas trop posé la question jusqu'à présent. Peut-être que ffmpeg se met automatiquement en copy quand les fichiers d'entrée et de sortie sont dans le même format. Je n'ai jamais entendu de différence de qualité.

En tout cas, je préférerai ne pas dépendre d'un autre logiciel que ffmpeg.

J'apprécie ce qu'il est possible de faire avec l'outil, mais je préfère l'approche de troff. Lout est un bon logiciel, mais comment rivaliser avec le charme des outils unix ?

Je me demande quel est l'apport fonctionnel de Lout par rapport à troff. Des formats de pages plus complexes en gardant un code simple ? Un niveau de précision plus important concernant les dessins ? Des tableaux plus complexes ? Des graphes plus évolués ?

En regardant la section que tu as mentionné, en effet, il y a quelques constructions intéressantes, comme la gestion des séquences. C'est bel et bien un type de dessins qu'on pourrait vouloir dans un document. Maintenant, est-ce que l'approche de Lout est la meilleure pour ça ? Je préférerai de très loin une extension de pic pour faire la même chose.

J'ai déjà vu cet outil, mais je n'arrive pas à voir en quoi il serait intéressant. De plus, il m'a l'air quand même bien plus verbeux que troff.

Dommage qu'il n'y ait pas plus d'exemples, notamment pour faire des diagrammes, des dessins, des graphes…

Pic est génial, et si tu lis les autres commentaires, tu verras à la fois de code des exemples que j'ai fournis, et une liste d'outils similaires à pic (pour avoir des outils similaires dans d'autres contextes, ou avec quelques fonctionnalités différentes tout en conservant la simplicité de l'outil).

graphviz c'est très bien quand on a un ensemble de données que l'on veut visualiser sans se soucier du placement. Pic est un peu plus comme dia, pour faire des schémas.

Ce serait dommage de ne s'arrêter qu'à pic par ailleurs, le reste est également excellent. Sans compter que certaines limitations que j'ai exprimées dans le journal sont levées en utilisant mom plutôt que ms (vieil ensemble de macros, un peu trop limité).

En tout cas, bonne chance !

pic et les outils que tu présentes sont de pures beautés. Je ne comprends pas comment on peut se farcir des outils comme LibreOffice Draw pour faire des schémas qui peuvent se faire en quelques lignes avec pic.

À la limite, de nos jours, pic pourrait être amélioré pour intégrer des images, par exemple. Je vois éventuellement quelques améliorations possibles comme ça, mais la base est tellement solide ! C'est une telle déception de voir des horreurs de complexité là où, il y a 50 ans, on faisait déjà mieux.

Et pour ceux qui se demandent, voici la diffraction circulaire.

.\" Radius for different circles.
rad_large_circle = 0.6
rad_empty_space  = 0.5
rad_light_source = 0.3
rad_aperture     = 0.1

.\" Light intensity.
fill_large_circle = 0.1   # Very bright.
fill_empty_space  = 0.6   # Little bright.
fill_light_source = 0     # Completely bright.

arrow_x_shift = 0.05
txt_y_shift = 0.25   # Allow space for text.

.\" Circles.
HALO:     circle                   rad rad_large_circle  fill fill_large_circle
EMPTY:    circle with .c at HALO.c rad rad_empty_space   fill fill_empty_space 
SOURCE:   circle with .c at HALO.c rad rad_light_source  fill fill_light_source
APERTURE: circle with .c at HALO.c rad rad_aperture fill fill_light_source dashed

.\" Legend.
TAPERTURE: "Aperture, where light can pass through" ljust at HALO.e + (0.3, 0)
TSOURCE:  "Main visible light source, very bright"  ljust at Here + (0, -txt_y_shift)
TEMPTY:   "Empty space, very little light"          ljust at Here + (0, -txt_y_shift)
THALO:    "Halo, thin light"                        ljust at Here + (0, -txt_y_shift)

.\" Arrows.
arrow from TAPERTURE + (-arrow_x_shift,0) to APERTURE chop 0 chop rad_aperture
arrow from TSOURCE   + (-arrow_x_shift,0) to SOURCE   chop 0 chop rad_light_source
arrow from TEMPTY    + (-arrow_x_shift,0) to EMPTY    chop 0 chop rad_empty_space
arrow from THALO     + (-arrow_x_shift,0) to HALO     chop 0 chop rad_large_circle


.\" Let's cheat a little: centering the figure.
false_line_x = 2.7
line from SOURCE + (false_line_x,0) to SOURCE + (false_line_x,0)

.ps 14
"Circular diffraction" at HALO.s + (1, -1)

Là encore, on peut voir qu'un objet de l'image correspond à une ligne. Il y a quelques exceptions à cela, comme les variables (des distances par exemple) ou des requêtes troff pour changer ce qui n'est pas relatif à pic spécifiquement (comme la taille des polices avec .ps 14), mais c'est parfaitement raisonnable.

Au final on se retrouve avec des images de bonne qualité en quelques lignes, entièrement générées par troff. Pas besoin de programme externe.

Et je tiens à noter, même si c'est hors sujet, que la personne qui fait mom est aussi celle qui a fait le script d'ajout de polices pour groff. Merci à lui !

Même avec des implémentations non vanilla, il ne fait pas ce que je peux faire avec troff (ne serait-ce que pour la gestion sémantique de la typographie, rien que ça il le fait pas). Si j'ai écarté markdown, c'est pas pour rien. Le fait que ce soit utilisé massivement par ailleurs me fait une belle jambe si je peux pas faire ce que je veux faire avec.

Et ça c'est sans compter que la complexité qu'il n'y a pas dans la syntaxe du document source se paie par ailleurs. Notamment en invoquant LaTeX pour la gestion des équations, l'usage de plein d'outils sans intégration au document pour faire des graphes et autres schémas, mais aussi la gestion bibliographique… là où tout est parfaitement intégré et tellement simple en roff.

Les développeurs de roff ont réussi en 1970 là où en 2022 on échoue. C'est sans appel (et un peu triste, on va pas se le cacher).

Markdown pour mon usage, c'est moins bien. Et je pense qu'une partie des utilisateurs de markdown l'utilisent à défaut de connaître des alternatives, mais ça c'est une histoire pour une autre fois.

Les macros mom sont dédiées à des sorties PDF et PS. De ce que je peux lire de la documentation introductive, c'est un ensemble de macros spécifiquement pour les débutants : on peut même oublier les requêtes bas niveau de roff pour se concentrer sur le contenu du document. Et vu le nombre de choses que mom fait, c'est probablement vrai.

À mon avis pour un débutant qui veut juste produire des documents rapidement, c'est très bien. Ces macros répondent même à certains problèmes que j'ai avec les macros ms, par exemple les liens PDF et les références intra-document sont disponibles de base. La documentation est deux fois plus longue, mais s'ils ont réussi à faire des macros qui remplissent toutes les fonctionnalités qu'on attend, tu gagnes un peu de temps.

Les noms des macros sont également plus humaines, on peut voir ça avec les noms de chapitres (ou sections) :

.HEADING 1 NAMED intro "Introduction"

Voilà, en une ligne on a une nouvelle section, en précisant le niveau de section (1), un mot clé pour le référencement (intro) et le titre. Le tout avec une macro ayant un nom explicite.

Pour la petite histoire, j'ai débuté avec les macros ms seulement parce que j'avais lu qu'elles étaient plus simples, c'est tout. Au final j'ai jonglé entre différentes documentations (troff, groff et ms) pour comprendre comment tout fonctionnait; et à part les limitations que j'ai vu plus haut, ms c'est très bien aussi. Mais si tu veux te lancer et avoir globalement tout qui fonctionne d'emblée, avec ce que je viens de lire, je pense que c'est plus intéressant de débuter avec mom.

Si quelqu'un a un retour d'expérience avec mom, hésitez pas.

Ha, si seulement je pouvais like 10 fois ton message…

Si on ne prend que la contrainte de sortir un PDF, markdown, comme toutes les autres technos, ça passe.

Différentes contraintes, différents choix. Logique.

Si vous voulez utiliser markdown dans vos projets, faites vous plaisir. Vous avez peut-être de bonnes raisons de le faire. Dans mon cas, avec mes contraintes, markdown ne passe pas. Je crache pas dessus pour autant.

Devinez quoi ? Il y a des gens qui écrivent des papiers voire leur thèse avec Word. Peu importe. Ça ne répond pas à mes critères.

J'ai bien précisé mon objectif, pourquoi j'écartais Markdown (sémantique et typographie) et LaTeX (trop lourd) ou encore le HTML (documents éphémères, technos trop changeantes, etc.). J'ai précisé à chaque fois que ce sont mes goûts et mes choix pour mon objectif personnel.

Et à cela, tu viens me dire qu'il ne faut pas écarter Markdown car on peut en faire du HTML grâce à Python et générer du PDF avec le combo pandoc et LaTeX, et que c'est pratique pour du travail collaboratif.

Oui, avec plein de contraintes différentes, très bien, markdown c'est super. Mais pour moi c'est hors sujet. Là je parle vraiment de mes documents.

Je ne voulais pas que l'article soit un tutoriel, ça aurait été trop lourd et plutôt loin de mon objectif.

Voici le code, commenté pour l'occasion, de la lentille gravitationnelle.

.\" vs = vertical space (l'espace entre les lignes)
.\" ps = point size (la taille du texte)
.vs 9p
.ps 7
reset

.\" direction du dessin : quand on bouge, on descend
down

.\" ajuste la taille du dessin
scale = 1.4


.\""""""""""""""""""""""""""""""""""""""""""
.\" variables pour ajuster certains éléments

.\" distances x et y des objets agrandis à l'objet massif
mag_obj_x = 1.4
mag_obj_y = -1

.\" rayons des objets célestes
rad_obs         = 0.3
rad_massive_obj = 0.5
rad_mag         = 0.4
rad_dist        = 0.27

.\" distance du rayon de lumière de l'objet distant au centre de l'objet massif
dist_beam_massive_obj = 0.32


.\""""""""""""""""""""""""""""""""""""""""""""""""""
.\" dessin des objets célestes (planètes, galaxies…)

.\" observateur, objet massif et objet distant
OBSERVER:    circle radius rad_obs "Observer"
move
MASSIVE_OBJ: circle radius rad_massive_obj "Massive" "object"
move
TARGET:      circle radius rad_dist "Distant" "object"

.\" Nous pouvons abréger "radius" en "rad", ce que je ferais dans la suite. ;)

.\" illusions perçues par l'observateur
MAGNIFIED1: circle rad rad_mag "Magnified" "distant" "object" at MASSIVE_OBJ + ( mag_obj_x, mag_obj_y)
MAGNIFIED2: circle rad rad_mag "Magnified" "distant" "object" at MASSIVE_OBJ + (-mag_obj_x, mag_obj_y)

.\" lignes, des objets agrandis vers l'observateur
.\" chop = les lignes dessinées s'arrêtent en bordure des cercles,
.\"        elles ne vont pas jusqu'au centre

line from MAGNIFIED1 to OBSERVER chop rad_mag chop rad_obs dashed
line from MAGNIFIED2 to OBSERVER chop rad_mag chop rad_obs dashed

.\" flèches, de l'objet distant à l'observateur
.\" Note : .e = east, .w = west.
spline -> from TARGET to MASSIVE_OBJ.e + (dist_beam_massive_obj,0)  to OBSERVER chop rad_dist chop rad_obs
spline -> from TARGET to MASSIVE_OBJ.w + (-dist_beam_massive_obj,0) to OBSERVER chop rad_dist chop rad_obs

.\" (rappel) ps = point size. Ici on agrandit la taille de la police.
.ps 14
"Gravitational lensing" at TARGET + (0,-0.7)

Comme je l'ai dit dans le journal : sémantique et typographie.

Avec markdown, on oublie toute sémantique. C'est pourtant un point crucial pour moi. Rien que pour ça, c'est éliminatoire.

De plus, je veux pouvoir contrôler la typographie de mon document. Et je parle d'un document au format PDF, pas html, que je veux en double colonnes, en précisant moi-même les polices et leurs tailles, la taille du pied de page, etc.

Et je suis contre l'usage d'un éditeur spécialisé. Ce sont des gadgets, lourds et inutiles, tout ce que je fuis. Mon éditeur c'est vis, point. Après avoir écrit (ou trouvé sur le net) quelques macros, on peut retrouver la simplicité d'écriture recherchée par markdown tout en ayant un environnement correct pour écrire de longs documents.

Je trouve markdown très bien pour un mail ou un commentaire sur le net, pas pour des documents sérieux.

Merci pour tes précisions.

Et oui, la suite roff est plus légère. La totalité des outils roff ainsi que les fichiers de configuration et les fonts représentent même pas 15 Mo sur ma machine. Même en admettant que je ne compte pas tout, soyons fous, doublons ce chiffre pour être sûr, on arrive à 30 Mo. Avec LaTeX on arrive rapidement à plus d'un giga voire deux. Et là, j'utilise groff qui est probablement la plus grosse implémentation, et j'ai installé des fonts personnalisées. La différence est colossale.

Après, bien entendu LaTeX fait plus de choses, mais faut en avoir l'usage.

Je veux bien considérer Tex, seul, comme étant un outil pouvant rivaliser avec roff. Pour l'instant je n'ai pas joué avec donc je n'ai pas d'avis tranché sur la question. D'un autre côté, en connaissant roff et en étant satisfait des résultats produits, j'ai du mal à voir l'utilité derrière Tex. Je suppose que les références intra-document sont gérées de base, puisqu'il n'y a pas de gestion de document ligne-par-ligne, mais c'est un peu du détail, àmha.

Dans un tout autre style, j'aimerais bien regarder SILE. Ici le gros avantage est de gérer très finement (et simplement) du texte avec des placements qui sortent de l'ordinaire. Je pense que c'est un très bon outil pour faire des pages de magazines par exemple. En tout cas, je suis curieux.

Je pense que c'est un bon exemple pour montrer de la programmation fonctionnelle, voir le parallèle avec des technologies "modernes" et se rendre compte que c'était là depuis le début ! [musique dramatique]

Ce n'est pas un projet mort, mais oui, il bouge assez peu et comme toi je me retrouve avec pas mal de commandes qui me manquent. Je voulais surtout montrer quelque-chose qui sort du lot, et je pense qu'il ne manquerait pas grand chose pour remplacer mon vim complètement.

Attention, j'ai bien précisé que pour beaucoup ça se résume à l'interface. C'est bien normal pour les non expérimentés. À partir de là, il est assez évident que je parlais pour les autres dans la suite de mon commentaire.

Et ce que je disais concernant l'interface par défaut, notamment du fait que ça ne devrait pas trop jouer dans le choix de la distribution, est justement là pour dire que le changement de l'interface ne devrait pas être compliqué. Personne ne veut passer du temps sur ça, mais si la distribution ne permet pas de changer facilement, c'est peut-être un problème de conception de la distribution.

Je comprends que pour beaucoup, l'interface de la distribution permettant son administration est important. Du moins, pour les opérations assez simples de gestion des programmes (installation, suppression, blah blah) ainsi que quelques paramètres concernant l'écran, la disposition du clavier, etc.

Cependant, une distribution est bien plus que cela. C'est une gestion de services, une gestion des programmes (et paquets), une documentation, ainsi qu'une manière de contribuer… Par exemple, est-ce simple de créer puis d'ajouter un paquet ? Comment obtenir de l'aide ? Est-ce que les programmes sont à jour et comment est pensé la politique de mise à jour ? Quel est le choix des outils bas niveau (par exemple les outils de gestion du réseau installés par défaut) ?

Tout ceci ne peut être "testé" en un après-midi. L'interface fournie par défaut ne devrait pas être un critère de choix du système, et s'il est compliqué de changer d'interface sur le système, peut-être que ça en dit long sur le système en question.

Voilà, mon avis.

Alors, c'est très peu connu pour l'instant, mais l'éditeur que j'utilise en ce moment pour écrire du Crystal, mes mails, des scripts, et tout un tas d'autres trucs, c'est vis.

Pour faire simple : c'est vim mais sans le code historique, avec

1. une gestion des curseurs multiples qui est géniale
2. une bonne gestion de la coloration syntaxique (basée sur les LPeg de Lua)
3. une rapidité d'exécution enfin digne de ce qu'on pourrait attendre d'un éditeur (oui, même vim est beaucoup trop lent selon moi, c'est peut-être lié à des modules que j'ai mais j'en suis pas certain)
4. une interface réellement simple et générique (l'interface où on tape des commandes est vu comme un simple buffer où on écrit du texte, comme pour n'importe-quel fichier, pour ne donner qu'un exemple)
5. des expressions rationnelles régulières

Et les développeurs ont aussi déterminé des non-objectifs clairs qui me font dire qu'ils vont dans le bon sens (pour un éditeur de code, pour la simplicité du code, pour garder un éditeur qui ne fait qu'éditeur, etc.).

Je reconnais cependant que tant qu'on n'aura pas implémenté le Language Server Protocol, il restera moins intéressant que n'importe-quel autre éditeur pour ceux qui veulent un outil les aidant à l'écriture de code.

Mais voilà, pour moi c'est une vraie bonne piste.