Effectivement, le logiciel Troff est l'interpréteur du langage de formatage de texte du même nom. Le langage est décrit dans 54.ps.gz, dont un lien est donné plus haut.
À partir de ce langage, on créé des macros, dont les macros man, et mdoc. Troff déplie chaque macro pour interpréter les commandes qui la composent.
Le logiciel mandoc est un logiciel qui met en page les macros man et mdoc, sans en passer par le langage Troff : le résultat de ces macros est connu, il suffit d'imiter Troff pour afficher les manuels. Cela permet à Mandoc d'être plus performant.
Mandoc connaît néanmoins un sous ensemble du langage Troff, car bien souvent, des commandes Troff sont insérées dans les pages de manuel.
Deux raisons ont motivés OpenBSD à migrer vers Mandoc: les performances et la licence, car Mandoc est sous licence BSD. Les licences des autres Troff, sont d'un esprit proche de la licence GNU – hormis le troff original, libéré par Caldera, mais celui demanderait probablement trop de travail pour être remis aux goûts du jour.
Mais à ma connaissance, l'idée d'utiliser un autre troff que Groff n'a pas été beaucoup discutée par les développeurs d'OpenBSD.
Mais pour écrire cette dépêche, j'avais déniché de nombreux liens qui n'ont pas été publiés. Tu me rappelles que je ferais bien de les partager avant de ne les perdre.
Certes, des contenus disparaissent, mais le problème, c'est surtout que ceux qui restent ne sont plus correctement indexés dans les moteurs de recherche. La méthode de la recherche historique sur le réseau n'est pas la même que celle de la recherche quotidienne.
Par exemple, une recherche sur l'histoire de troff et sur les logiciels qui l'accompagnait lorsqu'il était largement utilisé ne donne a première vue rien. Mais sur la liste de discussion de groff, sur celle de plan9, sur la vieille page personnelle de Brian Kernighan, sur les vieilles forge, telle celle d'Open Solaris, ou sur les sites d'entreprises, tel sur celui de Caldera, on peut retrouver les sources de divers outils et macros aujourd'hui oubliés, ou celles de troff telles qu'elles étaient en 90. En fouillant le net, on trouve aussi de la vieille documentation, des interviews…
Assez étonnamment on peut remonter le temps sur internet.
Non, je sais très bien qu'il y a des alternatives, qui sont d'ailleurs très attractives.
À titre personnel, je me demande si je choisirai un alternative, et si oui, laquelle.
D'une manière plus générale, je me demande si l'orientation que prend Arch (je persiste à croire que c'est un changement, même si nous ne somme pas d'accord là-dessus) satisfait ses utilisateurs.
Pour l'ensemble des qualificatifs sympathiques qui assaisonnent ton commentaire : je constate jour après jour être de plus en plus réactionnaire en informatique. Mais je ne crois pas l'être pour la technique pure, et je m'extasie souvent devant une nouvelle solution à un problème. Je ne rejette donc pas tout ce qui est neuf. Mais parfois, sous un progrès technique, je vois des régressions concernant certains principes.
Ces principes, j'ai du mal à les définir mais tu dois voir de quoi je parle : Ils touchent à une veille notion d'ergonomie, un certain rapport entre l'homme et la machine, rapport qui s'est exprimé dans la philosophie unix, mais aussi dans le logiciel libre. Ils touchent à la possibilité pour moi d'être en mesure de comprendre et de modifier mon environnement informatique. Ils touchent à l'idée que l'informatique relève du langage, donc du dialogue. Idée selon laquelle l'informatique est de l'ordre du sens, sens que je suis en mesure de m'approprier et que je peux exprimer à mon tour. D'une certaine manière, le mot low-tech pourrait convenir.
Le fichier rc.conf était un bel exemple de cet esprit.
Arch décide de respecter l'upstream parce qu'elle a décidé d'être KISS, et qu'elle définissait le KISS par l'exemple.
Le jour ou l'upstream s'éloigne à ce point de ce que Arch définissait comme KISS, il se créé une tension. En suivant l'upstream, Arch respecte certains de ses principes tout en en reniant d'autres.
Ce qui fait la richesse d'une langue, ce n'est pas les mots, mais la combinaison des mots. C'est comme si tu me disais que parler ne sert à rien, car que je dise « attention ! », « eingousef ! » ou « Aaaiiiiih ! », il n'y a pas grande différence, car dans tous les cas je préviens mon interlocuteur de quelque chose d'imminent.
Trouve un exemple à trois commande avec un tube et une substitution de paramètre, et tu verras que l'interface graphique paraît tout de suite exigüe.
Et si ce n'est pas pour Mme Michu, c'est que comme tout langage, un langage shell s'apprend, et demande à être pratiqué pour faire autre chose que du bafouillage. Mme Michu a réussi à apprendre le français, elle réussira à apprendre le shell si elle s'en donne les moyens. C'est moins difficile que n'importe quelle langue vivante.
Écrire sur les réseaux sociaux, c'est en fait plus rigolo que d'écrire sur mon blog. Et même légèrement plus rigolo que d'écrire sur Linuxfr.
Pourtant, sur linuxfr:
Interaction directe: Je n'ai pas l'impression d'écrire ex-cathedra. Un post est finalement uniquement le départ d'une discussion dans les commentaires.
Dans le fichier .xinitrc, il faut lancer openbox avec la commande openbox-session (qui lance openbox et autostart.sh) et non pas seulement openbox (qui ne lance que openbox).
En ce moment, installer debian stable avec gnome aux nouveaux utilisateurs est un non-sens, car toute l'interface sera transformée dans six mois (passage à gnome 3), ce qui peut être douloureux pour les personnes qui font déjà le saut vers linux.
En attendant, j'ai installé ubuntu avec gnome-shell, mais sans conviction.
Enfin, heureusement, ça juste marche, et gnome 3 fait maintenant partie du quotidien des utilisateurs, qui en sont satisfait.
Je ne suis pas certain que ce ne soit qu'un effet de mode. J'ai au contraire l'impression que cela relève d'une sorte de bonne pratique. Cela ressemble à un usage imprévu mais efficace d'une base SQL.
Le contenu du journal sera intéressant pour peu qu'il soit un minimum travaillé : philosophie de la distribution, présentation des principaux contributeurs, fonctionnement collaboratif choisi par l'équipe, choix techniques, etc.
S'il y a des difficultés techniques particulières, mettez les en avant, cela motivera les plus expérimentés. Si vous avez besoin de petites mains, expliquez comment vous pouvez encadrer les moins expérimentés.
Désamorcez le troll du moment (« il y a trop de distributions ») en expliquant pourquoi zenwalk, en quoi elle est différente, et pourquoi vous aimez y travailler.
Je crois constater à la lecture de cet article qu'une base NoSQL réunit deux conditions:
Une manière non relationnelle de stocker les données,
Un code qui gère ces données libéré de certaines contraintes dues au relationnel.
On voit d'emblée qu'il y a d'autres façons d'articuler ces conditions:
On pourrait imaginer une base relationnelle qui tempère les contraintes de la relation pour privilégier les performances, et accepte un taux de validité faible sur ses données (peut-être qu'il y a des conditions particulières ou cela serait utile).
On peut aussi imaginer utiliser une base relationnelle et y stocker les données en vrac.
Fossil, par exemple, utilise étrangement sa base sqlite: il stocke toutes les données, quelles qu'elles soient, en vrac, dans une unique table. Dans un second temps, il génère, à partir de ces données, des vues en relation les unes avec les autres. De fait, si la structure des vues est cassée, ou doit être changée, il suffit de lancer une commande pour reconstituer celles-ci à partir du vrac. Cf les pages Formats de fichiers de fossil et fossil est une base NoSQL.
je trouvais cpold bien plus simple pour des micro-projets que de se forcer à gérer proprement des versions et tout le toutim
Essaye RCS, c'est une sorte de cpold: il te fait une copie de ton fichier dans le répertoire dudit fichier (ou dans le sous répertoire RCS s'il existe), et il y archive tes modifications.
Pour un usage basique, on n'utilise que trois commandes :
- ci -l monfichier : archive de la version courante (check-in).
- co -l monfichier : écrase la version courante par la version archivée (check-out).
- rcsdiff monfichier : diff entre la version courante et celle qui est archivée.
Merci pour ton riche retour d'expérience et tes précieux conseils.
Aujourd'hui je génère mon site et mes manuels à partir d'une moulinette perso qui prend des sources type Markdown
J'ai l'impression que c'est finalement la solution la plus simple et la plus souple pour les petits projets. Je crois que je vais m'orienter vers une solution de ce genre.
L'autre solution sur laquelle j'ai planché (et pas mal avancé) consistait à adapter le fichier wikiformat.c et à recompiler fossil. Je ne connais pas javascript, et l'idée de faire du navigateur un interpréteur de script ne me plaît pas, mais c'est probablement une solution plus simple.
La documentation de mon projet est destinée à être conséquente. De fait, pendant un temps, plutôt que de chercher une forge, je cherchais un système de publication de documentation. J'avais trouvé sphinx, mais aussi manserver, et j'ai jeté un coup d'œil aux moteurs de wiki.
C'est là qu'est apparu mon problème: pour publier de la documentation proprement, mieux vaut utiliser les logiciels qui conviennent. Pour publier les sources, ce sont d'autres logiciels.
Ainsi, non seulement j'hésite sur le choix de la technologie à utiliser, mais en plus, je ne suis pas certain que ces technologies me fassent gagner du temps.
J'ai travaillé bidouillé sur deux forges modernes: mercurial et fossil.
J'ai trouvé Mercurial trop complexe pour le temps que j'étais prêt à lui consacrer. Même la chose la plus simple (pousser une modification) me semblait inutilement compliqué. Il était couplé avec Redmine pour l'affichage sur le net, et j'ai bien vu que la maintenance de l'ensemble était assez lourde.
Fossil me semble plus simple et accessible. Je l'ai justement essayé pour mon projet personnel, car il intègre un wiki et un système de tickets. Mais ça m'a semblé disproportionné pour mon minuscule projet qui n'aura jamais qu'un contributeur. Les forges servent à gérer collaborativement le code source, et toute leur interface – tant du point de vue du développeur que du point de vue du visiteur du site – mettent en avant cette fonctionnalité.
Ce dont j'ai besoin, c'est surtout d'une interface dédiée à la publication du projet. Ce ne sont pas tant les sources que la documentation que je veux mettre en avant. À la limite, la « timeline » n'est rien de plus que de la documentation dans l'optique d'un petit projet. Or, les forges ne sont pas ergonomiques pour la documentation.
À titre d'exemple, le wiki de fossil utilise l'html comme syntaxe et la page d'accueil du wiki n'est pas configurable. Fossil ne sait pas transformer une page de manuel en html, il faut donc dupliquer l'information. Bref, il faut s'adapter à l'interface plutôt qu'utiliser une interface adaptée à ses besoins. Et à ma connaissance, fossil est la seule forge qui permette de documenter son projet.
Si c'est la seule solution, j'utiliserai fossil, mais à reculons.
En vérité, savoir quels guillemets utiliser à l'intérieur des chevrons est très discuté par les typographes: certains préfèrent ré-utiliser les chevrons, d'autres les chevrons simples, d'autres les guillemets anglais, d'autres les allemands… Bref cela relève plus du choix que d'une règle donc.
En outre, reste la question de savoir avec quelles espaces utiliser les guillemets anglais.
[^] # Re: Mandoc dans OpenBSD
Posté par Sygne (site web personnel) . En réponse à la dépêche À la recherche des sources de Troff. Évalué à 3.
Effectivement, le logiciel Troff est l'interpréteur du langage de formatage de texte du même nom. Le langage est décrit dans 54.ps.gz, dont un lien est donné plus haut.
À partir de ce langage, on créé des macros, dont les macros man, et mdoc. Troff déplie chaque macro pour interpréter les commandes qui la composent.
Le logiciel mandoc est un logiciel qui met en page les macros man et mdoc, sans en passer par le langage Troff : le résultat de ces macros est connu, il suffit d'imiter Troff pour afficher les manuels. Cela permet à Mandoc d'être plus performant.
Mandoc connaît néanmoins un sous ensemble du langage Troff, car bien souvent, des commandes Troff sont insérées dans les pages de manuel.
Deux raisons ont motivés OpenBSD à migrer vers Mandoc: les performances et la licence, car Mandoc est sous licence BSD. Les licences des autres Troff, sont d'un esprit proche de la licence GNU – hormis le troff original, libéré par Caldera, mais celui demanderait probablement trop de travail pour être remis aux goûts du jour.
Mais à ma connaissance, l'idée d'utiliser un autre troff que Groff n'a pas été beaucoup discutée par les développeurs d'OpenBSD.
La même question est posée sur le wiki de NetBSD.
[^] # Re: Mémoire?
Posté par Sygne (site web personnel) . En réponse à la dépêche Appel à contributions : Archives et contenus BBS et Minitel. Évalué à 4.
L'histoire elle-même est résumée dans une vieille dépêche.
Mais pour écrire cette dépêche, j'avais déniché de nombreux liens qui n'ont pas été publiés. Tu me rappelles que je ferais bien de les partager avant de ne les perdre.
J'essaie donc de publier ça rapidement.
[^] # Re: Mémoire?
Posté par Sygne (site web personnel) . En réponse à la dépêche Appel à contributions : Archives et contenus BBS et Minitel. Évalué à 3.
Est-ce bien un problème de mémoire?
Certes, des contenus disparaissent, mais le problème, c'est surtout que ceux qui restent ne sont plus correctement indexés dans les moteurs de recherche. La méthode de la recherche historique sur le réseau n'est pas la même que celle de la recherche quotidienne.
Par exemple, une recherche sur l'histoire de troff et sur les logiciels qui l'accompagnait lorsqu'il était largement utilisé ne donne a première vue rien. Mais sur la liste de discussion de groff, sur celle de plan9, sur la vieille page personnelle de Brian Kernighan, sur les vieilles forge, telle celle d'Open Solaris, ou sur les sites d'entreprises, tel sur celui de Caldera, on peut retrouver les sources de divers outils et macros aujourd'hui oubliés, ou celles de troff telles qu'elles étaient en 90. En fouillant le net, on trouve aussi de la vieille documentation, des interviews…
Assez étonnamment on peut remonter le temps sur internet.
[^] # Re: L'immobilisme c'est mal.
Posté par Sygne (site web personnel) . En réponse au journal Arch et le tournant. Évalué à 2.
Non, je sais très bien qu'il y a des alternatives, qui sont d'ailleurs très attractives.
À titre personnel, je me demande si je choisirai un alternative, et si oui, laquelle.
D'une manière plus générale, je me demande si l'orientation que prend Arch (je persiste à croire que c'est un changement, même si nous ne somme pas d'accord là-dessus) satisfait ses utilisateurs.
Pour l'ensemble des qualificatifs sympathiques qui assaisonnent ton commentaire : je constate jour après jour être de plus en plus réactionnaire en informatique. Mais je ne crois pas l'être pour la technique pure, et je m'extasie souvent devant une nouvelle solution à un problème. Je ne rejette donc pas tout ce qui est neuf. Mais parfois, sous un progrès technique, je vois des régressions concernant certains principes.
Ces principes, j'ai du mal à les définir mais tu dois voir de quoi je parle : Ils touchent à une veille notion d'ergonomie, un certain rapport entre l'homme et la machine, rapport qui s'est exprimé dans la philosophie unix, mais aussi dans le logiciel libre. Ils touchent à la possibilité pour moi d'être en mesure de comprendre et de modifier mon environnement informatique. Ils touchent à l'idée que l'informatique relève du langage, donc du dialogue. Idée selon laquelle l'informatique est de l'ordre du sens, sens que je suis en mesure de m'approprier et que je peux exprimer à mon tour. D'une certaine manière, le mot low-tech pourrait convenir.
Le fichier rc.conf était un bel exemple de cet esprit.
[^] # Re: même avis
Posté par Sygne (site web personnel) . En réponse au journal Arch et le tournant. Évalué à 4.
Arch décide de respecter l'upstream parce qu'elle a décidé d'être KISS, et qu'elle définissait le KISS par l'exemple.
Le jour ou l'upstream s'éloigne à ce point de ce que Arch définissait comme KISS, il se créé une tension. En suivant l'upstream, Arch respecte certains de ses principes tout en en reniant d'autres.
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Sygne (site web personnel) . En réponse au journal Arch et le tournant. Évalué à 7.
D'accord, vous m'avez convaincu pour Grub2.
[^] # Re: L'avis d'Eben Moglen
Posté par Sygne (site web personnel) . En réponse au journal L'esprit UNIX, une culture des mots. Évalué à 4.
man pic; man pic2plot
De rien.
[^] # Re: L'avis d'Eben Moglen
Posté par Sygne (site web personnel) . En réponse au journal L'esprit UNIX, une culture des mots. Évalué à 7.
Ce qui fait la richesse d'une langue, ce n'est pas les mots, mais la combinaison des mots. C'est comme si tu me disais que parler ne sert à rien, car que je dise « attention ! », « eingousef ! » ou « Aaaiiiiih ! », il n'y a pas grande différence, car dans tous les cas je préviens mon interlocuteur de quelque chose d'imminent.
Trouve un exemple à trois commande avec un tube et une substitution de paramètre, et tu verras que l'interface graphique paraît tout de suite exigüe.
Et si ce n'est pas pour Mme Michu, c'est que comme tout langage, un langage shell s'apprend, et demande à être pratiqué pour faire autre chose que du bafouillage. Mme Michu a réussi à apprendre le français, elle réussira à apprendre le shell si elle s'en donne les moyens. C'est moins difficile que n'importe quelle langue vivante.
[^] # Re: Comme son nom l'indique
Posté par Sygne (site web personnel) . En réponse au message cherche exemples de documentation avec belle mise en page. Évalué à 2.
Non, c'est pas parfait en fait: il n'y a que du html, pas de documentation en pdf…
[^] # Re: Comme son nom l'indique
Posté par Sygne (site web personnel) . En réponse au message cherche exemples de documentation avec belle mise en page. Évalué à 2.
Parfait ce lien, merci !
[^] # Re: La meillor !
Posté par Sygne (site web personnel) . En réponse au message cherche exemples de documentation avec belle mise en page. Évalué à 2.
Ah, j'ai oublié l'essentiel: format pdf (j'ai trouvé le lien).
C'est vrai qu'elle est bien la version html de cette doc, mais je suis moins convaincu par le pdf, que je trouve trop dense et parfois un peu confus.
T'en as pas une autre?
# linuxfr
Posté par Sygne (site web personnel) . En réponse au journal Abandonner son blog pour les réseaux sociaux, pourquoi pas ?. Évalué à 10.
Pourtant, sur linuxfr:
Contrôle de mes données. On ne peut me censurer:)
[^] # Re: oui
Posté par Sygne (site web personnel) . En réponse au message Syntaxe de document troff. Évalué à 3.
Merci :)
[^] # openbox-session
Posté par Sygne (site web personnel) . En réponse au message [OpenBox] fichier autostart. Évalué à 2.
Dans le fichier .xinitrc, il faut lancer openbox avec la commande
openbox-session(qui lance openbox et autostart.sh) et non pas seulementopenbox(qui ne lance que openbox).# Période charnière
Posté par Sygne (site web personnel) . En réponse au sondage Quelle distribution de logiciels libres installez-vous aux copains non geeks?. Évalué à 2.
En ce moment, installer debian stable avec gnome aux nouveaux utilisateurs est un non-sens, car toute l'interface sera transformée dans six mois (passage à gnome 3), ce qui peut être douloureux pour les personnes qui font déjà le saut vers linux.
En attendant, j'ai installé ubuntu avec gnome-shell, mais sans conviction.
Enfin, heureusement, ça juste marche, et gnome 3 fait maintenant partie du quotidien des utilisateurs, qui en sont satisfait.
# Coquille
Posté par Sygne (site web personnel) . En réponse à la dépêche Actu ACTA, tac, tac, tac, tac et tract. Évalué à 3.
[^] # Re: Intervalle entre SQL et NoSQL
Posté par Sygne (site web personnel) . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 4.
Je ne suis pas certain que ce ne soit qu'un effet de mode. J'ai au contraire l'impression que cela relève d'une sorte de bonne pratique. Cela ressemble à un usage imprévu mais efficace d'une base SQL.
# écrivez un journal
Posté par Sygne (site web personnel) . En réponse au message Zenwalk à besoin de nouveaux contributeurs. Évalué à 6.
Parce que les forums sont moins lus.
À mon avis (ce n'est qu'un avis):
# Intervalle entre SQL et NoSQL
Posté par Sygne (site web personnel) . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 5.
Je crois constater à la lecture de cet article qu'une base NoSQL réunit deux conditions:
On voit d'emblée qu'il y a d'autres façons d'articuler ces conditions:
Fossil, par exemple, utilise étrangement sa base sqlite: il stocke toutes les données, quelles qu'elles soient, en vrac, dans une unique table. Dans un second temps, il génère, à partir de ces données, des vues en relation les unes avec les autres. De fait, si la structure des vues est cassée, ou doit être changée, il suffit de lancer une commande pour reconstituer celles-ci à partir du vrac. Cf les pages Formats de fichiers de fossil et fossil est une base NoSQL.
[^] # Re: Keep it...
Posté par Sygne (site web personnel) . En réponse au journal Publication de petits projets. Évalué à 5.
Essaye RCS, c'est une sorte de cpold: il te fait une copie de ton fichier dans le répertoire dudit fichier (ou dans le sous répertoire RCS s'il existe), et il y archive tes modifications.
Pour un usage basique, on n'utilise que trois commandes :
- ci -l monfichier : archive de la version courante (check-in).
- co -l monfichier : écrase la version courante par la version archivée (check-out).
- rcsdiff monfichier : diff entre la version courante et celle qui est archivée.
Bref, que du bonheur.
[^] # Re: Keep it...
Posté par Sygne (site web personnel) . En réponse au journal Publication de petits projets. Évalué à 4.
Merci pour ton riche retour d'expérience et tes précieux conseils.
J'ai l'impression que c'est finalement la solution la plus simple et la plus souple pour les petits projets. Je crois que je vais m'orienter vers une solution de ce genre.
[^] # Re: Voyage dans le temps
Posté par Sygne (site web personnel) . En réponse au journal Publication de petits projets. Évalué à 3.
Ah oui, bien vu, je n'avais pas pensé à ça.
L'autre solution sur laquelle j'ai planché (et pas mal avancé) consistait à adapter le fichier wikiformat.c et à recompiler fossil. Je ne connais pas javascript, et l'idée de faire du navigateur un interpréteur de script ne me plaît pas, mais c'est probablement une solution plus simple.
[^] # Re: Sphinx ?
Posté par Sygne (site web personnel) . En réponse au journal Publication de petits projets. Évalué à 2.
La documentation de mon projet est destinée à être conséquente. De fait, pendant un temps, plutôt que de chercher une forge, je cherchais un système de publication de documentation. J'avais trouvé sphinx, mais aussi manserver, et j'ai jeté un coup d'œil aux moteurs de wiki.
C'est là qu'est apparu mon problème: pour publier de la documentation proprement, mieux vaut utiliser les logiciels qui conviennent. Pour publier les sources, ce sont d'autres logiciels.
Ainsi, non seulement j'hésite sur le choix de la technologie à utiliser, mais en plus, je ne suis pas certain que ces technologies me fassent gagner du temps.
[^] # Re: Voyage dans le temps
Posté par Sygne (site web personnel) . En réponse au journal Publication de petits projets. Évalué à 3.
J'ai
travaillébidouillé sur deux forges modernes: mercurial et fossil.J'ai trouvé Mercurial trop complexe pour le temps que j'étais prêt à lui consacrer. Même la chose la plus simple (pousser une modification) me semblait inutilement compliqué. Il était couplé avec Redmine pour l'affichage sur le net, et j'ai bien vu que la maintenance de l'ensemble était assez lourde.
Fossil me semble plus simple et accessible. Je l'ai justement essayé pour mon projet personnel, car il intègre un wiki et un système de tickets. Mais ça m'a semblé disproportionné pour mon minuscule projet qui n'aura jamais qu'un contributeur. Les forges servent à gérer collaborativement le code source, et toute leur interface – tant du point de vue du développeur que du point de vue du visiteur du site – mettent en avant cette fonctionnalité.
Ce dont j'ai besoin, c'est surtout d'une interface dédiée à la publication du projet. Ce ne sont pas tant les sources que la documentation que je veux mettre en avant. À la limite, la « timeline » n'est rien de plus que de la documentation dans l'optique d'un petit projet. Or, les forges ne sont pas ergonomiques pour la documentation.
À titre d'exemple, le wiki de fossil utilise l'html comme syntaxe et la page d'accueil du wiki n'est pas configurable. Fossil ne sait pas transformer une page de manuel en html, il faut donc dupliquer l'information. Bref, il faut s'adapter à l'interface plutôt qu'utiliser une interface adaptée à ses besoins. Et à ma connaissance, fossil est la seule forge qui permette de documenter son projet.
Si c'est la seule solution, j'utiliserai fossil, mais à reculons.
[^] # Re: Guillemets
Posté par Sygne (site web personnel) . En réponse au journal Les fautes des Linuxfriens. Évalué à 2.
En vérité, savoir quels guillemets utiliser à l'intérieur des chevrons est très discuté par les typographes: certains préfèrent ré-utiliser les chevrons, d'autres les chevrons simples, d'autres les guillemets anglais, d'autres les allemands… Bref cela relève plus du choix que d'une règle donc.
En outre, reste la question de savoir avec quelles espaces utiliser les guillemets anglais.