Journal frundis : un langage de balisage sémantique qui mûrit !

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
37
3
juin
2017

Bonjour Nal,

Il y a un peu plus de deux ans, je t'avais parlé d'un langage de balisage sémantique, appelé frundis, qui permettait de produire du LaTeX, de l'HTML et des EPUB; un langage à mi-chemin entre les langages dits « légers » (comme markdown) et les langages plus « lourds » vers lesquels il exporte.

Depuis, le langage a fait son petit bout de chemin !

Déjà, j'ai réécrit le programme en Go l'année dernière (avant c'était du Perl). La réécriture m'a permis de repenser un peu l'architecture du programme pour faciliter l'export vers de nouveaux formats : on peut donc aussi exporter maintenant vers markdown et groff mom. L'export vers ces formats est un peu seconde-classe et donc pas aussi mûr ni complet que celui vers LaTeX, HTML et EPUB, mais peut s'avérer parfois bien pratique. Par exemple, un truc chouette, c'est produire des pdfs de qualité avec groff mom lorsque le géant TeX Live n'est pas installé sur la machine.

(go)frundis est maintenant plus facile à installer aussi : il n'y a aucune dépendance en dehors de la librairie standard de Go. Le détail des instructions pour l'installer se trouve sur la page github du projet : en gros, il s'agit juste de configurer la variable d'environnement GOPATH puis de faire un go get du projet ; en fait, même pas besoin de configurer GOPATH à partir de go 1.8.

D'autres changements plus ou moins en vrac :

  • Possibilité de spécifier des attributs pour un élément lors de l'export HTML ou EPUB, ou des options en LaTeX.
  • La séparation entre le fond et la forme (au cœur de la philosophie du langage !) a fait l'objet d'un petit peu d'attention.
  • Des améliorations côté macros utilisateur, comme la possibilité d'utiliser des arguments nommés ou un nombre variable d'arguments.
  • Quelques améliorations diverses : interpolation de variables d'environnement, simplification du système de références croisées et quelques changements divers visant à rendre le langage plus simple et orthogonal.
  • Plus de tests (autour de 95% du code couvert par des tests), moins de bugs (ou alors ils se cachent mieux maintenant), et frundis est de plus en plus rusé pour deviner où est-ce qu'on s'est planté avec la syntaxe, et de plus en plus pédagogique dans sa façon de nous le dire.

Un petit exemple de document frundis pour la route :

.Sh Titre de section
Texte dans un premier paragraphe.
.P
Texte dans un deuxième paragraphe.
.Sm Texte en emphase .
.Sh Autre Section
etc.
.Tc \" table des matières

Un exemple plus détaillé et en couleurs se trouve . Les pages man d'utilisation du programme et du langage (en anglais) décrivent en détail tout ce qu'il faut savoir ; enfin, sans doute pas tout mais beaucoup :)

PS : frundis est aussi plutôt énergique et est capable d'exporter des fichiers à plus de cent mille lignes par seconde sur ma machine (voire plusieurs centaines de milliers pour les fichiers simples) ; pas forcément super utile comme feature, surtout lorsqu'on exporte vers LaTeX qui est capable d'éclipser n'importe qui avec son allure lente et majestueuse, mais ça peut pas faire de mal :)

  • # GOPATH

    Posté par  . Évalué à 2.

    Hello,
    La configuration de la variable d'environnement GOPATH n'est plus nécessaire depuis go 1.8.
    Si elle n'est pas configurée, alors la valeur ${HOME}/go est utilisée.
    https://github.com/golang/go/issues/17262

    • [^] # Re: GOPATH

      Posté par  (site Web personnel) . Évalué à 1.

      en fait, même pas besoin de configurer GOPATH à partir de go 1.8.

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

    • [^] # Re: GOPATH

      Posté par  (site Web personnel) . Évalué à 3.

      J'avais vu passer le truc, par contre merci pour le lien, je savais pas que le sujet avait été débattu aussi longuement, en prenant compte des stats d'utilisation des différents paths et tout :) Ceci dit, je vais laisser les instructions telles quelles pour le moment, go 1.8 date à peine d'il y a quelques mois.

  • # roue.com

    Posté par  . Évalué à 5.

    Restons classique avec la fameuse question : pourquoi encore un autre langage markup ? Asciidoc et assimilés ne sont pas bien ?

    Le markdown est ultra limité dès que l'on dépasse le cadre du readme, mais il existe d'autres alternatives.

    • [^] # Re: roue.com

      Posté par  (site Web personnel) . Évalué à 10.

      Question classique en effet :) Et pas forcément facile, tellement il y a d'arguments d'ordres différents, allant du technique au subjectif et parfois les deux en même temps, un peu comme pour les langages de programmation !

      Ceci dit, un point de départ pour comprendre les spécificités de frundis, c'est qu'initialement l'objectif étant de pouvoir exporter des romans à la fois en LaTeX et EPUB, il fallait surtout ceci :

      • Des tags sémantiques spécifiques à un projet : DocBook est très centré documentation uniquement ; là il fallait pouvoir définir facilement des tags pour nom de lieu, pensée, nom de plante, etc. Pas forcément beaucoup d'éléments sémantiques pour un document donné, mais pas évidents à prévoir. Du coup, en frundis on écrit une espèce de feuille de style simplifiée pour chaque format d'export.
      • J'avais par contre besoin aussi de poèmes, et DocBook faisait pas ça la dernière fois que j'ai regardé.
      • Personaliser facilement et finement les exports LaTeX et EPUB, c'est-à-dire pouvoir donner soi-même facilement des commandes pour un préambule LaTeX ou les fichiers d'en-tête EPUB au besoin, tout en fournissant des trucs raisonnables par défaut également. Pour le coup, je sais pas si avec asciidoc/DocBook on peut faire ça, peut-être, pas vérifié vu qu'il manquait d'autres trucs.
      • Macros textuelles et variables, surtout pour éviter certaines redites, partager et structurer des choses entre divers documents ; mais macros limitées : pas de macros qui définissent des macros ou d'autres horreurs du style, parce que ça rend moins accessibles les messages d'erreurs et le langage en soi ; bon, « horreur », c'est relatif, mais pour mes utilisateurs actuels ça le serait :)

      Et puis, arguments techniques ou subjectifs, ou les deux, je sais pas :

      • Langage simple. Au sens, la documentation complète doit être accessible (donc aussi suffisamment courte) à quelqu'un qui connait un peu LaTeX et HTML, mais ne sait pas forcément programmer ni a de connaissances techniques poussées. Il ne faut donc pas que le langage définisse des éléments spécifiques de base : à chacun de définir ceux dont il a besoin pour son projet ; du coup, ça veut dire que ça doit être facile à faire, sinon c'est raté.
      • Gestion des erreurs de syntaxe intuitive, rapide et qui nous protège d'erreurs non intentionnelles. Il s'agissait donc un peu de la philosophie opposée à markdown, où tout fichier texte est valide : avec frundis il s'agit d'avoir des garanties que les éléments sont correctement fermés, etc., pas de typos qui gâche un paragraphe sans faire exprès : vérifier un texte court, ça va, mais vérifier tout un roman à la main, ça fait un peu plus peur ;)
      • Rapide : utile pour refaire tous les fichiers HTML d'une page web et avoir un retour immédiat. Aussi quand on exporte vers LaTeX : on a les messages d'erreurs avant, ça évite d'essayer de compiler avec LaTeX quand c'est perdu d'avance parce que frundis à râlé ; enfin, frundis fait de son mieux pour corriger et produire des trucs corrects même quand le fichier source ne l'est pas.
      • Facile à installer : pas de dépendances (je me répète un peu avec le journal).
      • Documenté avec le langage mdoc pour faire des pages man que j'adore ! (d'ailleurs on sent un tout petit peu l'influence dans frundis…)

      …Et puis sans doute d'autres trucs auxquels je pense pas de suite, moins importants ou que je sais pas comment dire.

    • [^] # Re: roue.com

      Posté par  . Évalué à 2.

      je trouve justement que txt2tags permet de dépasser toutes les limitations du markdown, surtout que l'on peut créer ses propres balises pour étendre le langage (c'est prévu dans les spécifications http://txt2tags.org/userguide/preproc.html#8_4 )

      • [^] # Re: roue.com

        Posté par  (site Web personnel) . Évalué à 2.

        Toutes, toutes, j'ai pas l'impression, au point que je sais pas par où commencer :)

        Déjà, j'ai écrit le fichier suivant (avec des espaces au début pour les headers) :

        =Title=                                             
        
        =Title==                                                                                                                                          
        
        A test file with //emphasis.                                                                                                                       
        
        A test file with //emphasis/.                                                                                                                      
        
        A test file with /emphasis//.
        

        Eh bien, j'ai aucun message d'erreur. Tout est correct ! Le premier titre apparaît balisé, le deuxième apparaît tel quel avec les signes =, et dans le texte on a les / tels quels. Même sans imaginer le cas où on utilise plusieurs fois de l'emphase dans un même paragraphe… on est pas sortis de l'auberge pour trouver des erreurs dans un gros document !

        Et puis, les extensions du langage, c'est à coup de substitutions… pas étonnant aussi, le langage est implémenté à coup d'expressions régulières ;) Mais ça ne fait que accentuer cette impression qu'on peut pas faire trop confiance au résultat et qu'il faut tout vérifier à la main à chaque changement. Et d'ailleurs, pas étonnant du coup non plus que ça rame un peu. Pour un fichier avec seulement A test file with //emphasis//. répété cent mille fois, c'est 7 secondes, là où pour la même chose frundis fait une demi-seconde ; et il y a des chances que si on se met à utiliser ses propres substitutions par dessus le langage de base, ça ne fasse qu'empirer.

        Ceci dit, je suis d'accord qu'il y a des trucs positifs par rapport au markdown, comme pouvoir inclure des fichiers facilement et le fait qu'il n'y a qu'une seule implémentation, donc une seule variante du langage. On dirait que c'est ok aussi niveau dépendances. Mais ça reste un langage « léger », c'est-à-dire un monde à part optimisé pour des usages différents, avec les avantages, mais aussi les inconvénients qui vont avec. Ceux qui me tiennent particulièrement à cœur sont l'absence de messages d'erreurs et la grammaire compliquée et irrégulière ; il en découle aussi qu'en l'absence d'un langage plus formel on se retrouve à inventer des syntaxes ad hoc pour les extensions et la configuration, qui ne simplifient pas spécialement le langage. Enfin, aussi, il y a le coté très « forme mélangée avec le fond » : dans les éléments de balisage par défaut du langage, la plupart s'intéressent à la forme (gras, italique, etc.), ils ne sont pas sémantiques, ça n'encourage pas ni n'aide à faire des documents cohérents d'un point de vue balisage.

        PS: j'ai pas vu d'export EPUB, donc je suppose qu'il faudrait d'abord exporter vers autre chose puis utiliser un deuxième outil. Un peu étonnant, parce que quand on sait faire de l'html, il n'y a plus grand chose à faire pour produire de l'EPUB.

        • [^] # Re: roue.com

          Posté par  . Évalué à 2.

          Et d'ailleurs, pas étonnant du coup non plus que ça rame un peu. Pour un fichier avec seulement A test file with //emphasis//. répété cent mille fois, c'est 7 secondes, là où pour la même chose frundis fait une demi-seconde ;

          ok, par contre on est d'accord, tu disais que le but c'était de donner des outils pour qu'un écrivain puisse écrire en particulier des romans ou des poésies, contrairement à LaTeX qui est plus généraliste et moins spécialisé. Du coup la lenteur (relative), ça ne sera pas trop un problème finalement. Peut-être qu'un jour un contributeur zélé réécrira txt2tags en go !

          100 000 itérations, ça fait beaucoup pour un seul auteur, même si je sais que Kaoseto est particulièrement prolifique !! Mais je te l'accorde, quand je génère des documents avec txt2tags (ou les extensions que j'ai développées), ça prend un peu de temps, même si au final le vrai goulot d'étranglement ça va être LaTeX pour le PDF ou Calibre pour l'ePUB.

          j'ai pas vu d'export EPUB, donc je suppose qu'il faudrait d'abord exporter vers autre chose puis utiliser un deuxième outil.

          oui. Par exemple j'ai fait une css spécifique pour exporter une version spéciale html dans calibre. Calibre permet de bien normaliser l'ePUB, autant utiliser un outil dédié à ça, qui le fera correctement. Et mes ePUB générés par ce biais seront sans doute plus propre qu'une bonne partie des ePUB commerciaux qui font souvent n'importe quoi.

          =Title==

          Eh bien, j'ai aucun message d'erreur. Tout est correct

          Effectivement. Il n'y a pas de garde-fou tout simplement par ce que le système ne saura pas si tu veux utiliser un des marqueurs pour définir une balise ou pour écrire quelque chose de signifiant avec (vouloir juste écrire Title= en tant que titre). C'est l'éternel débat entre une syntaxe non intrusive ou utiliser des balises plus verbeuses, on va dire que chacun va faire selon sa sensibilité. Cela dit, il existe des outils de coloration syntaxique qui vont mettre en valeur le balisage, et éventuellement les erreurs qu'on aurait pu faire. Sans doute qu'un script qui analyserait plus finement le texte pour souligner expressément tout ce qui lui semble hors norme.

          • [^] # Re: roue.com

            Posté par  (site Web personnel) . Évalué à 2.

            Peut-être qu'un jour un contributeur zélé réécrira txt2tags en go !

            Peut-être :) Ceci dit, c'est pas sûr que le système d'extension par substitutions deviendrait rapide pour autant : outre des questions de langages, c'est le principe en soi qui est problématique, les expressions régulières de Go sont pas plus rapides que celles de Python. Mais je t'accorde que c'est pas du tout ce qui m'a fait écrire frundis qui, au début, a servi à remplacer pandoc et la question de la performance m'était même pas venue à l'esprit et, pourtant, c'était bien plus lent que txt2tags ;) (qui au fond, vu son fonctionnement, est relativement rapide).

            Et mes ePUB générés par ce biais seront sans doute plus propre qu'une bonne partie des ePUB commerciaux qui font souvent n'importe quoi.

            C'est bien possible, j'avoue ne pas avoir réussi à produire de l'EPUB valide du premier coup, ni du deuxième :) Mais vu que l'EPUB, c'était quand même le format le plus important pour frundis, je voulais pouvoir contrôler le truc et pas dépendre d'un outil tiers comme Calibre ; remarque en passant, Calibre garantit que l'EPUB est correct uniquement si le XHTML source l'est, il faut donc quand même vérifier avec epubcheck après.

            Sans doute qu'un script qui analyserait plus finement le texte pour souligner expressément tout ce qui lui semble hors norme.

            C'est un peu comme les langages de programmation, d'un côté ceux qui offrent des garanties à la compilation et puis les autres qui se contentent d'heuristiques, donc effectivement, il est un peu question de sensibilité :) Mon impression, c'est que c'est un peu plus dur de tester automatiquement des textes que du code, mais j'avoue ne pas m'être penché sur la question sérieusement ; j'ai bien quelques scripts vite-faits pour détecter des trucs suspects que frundis détecterait pas lui-même —scripts qui ont bénéficié du fait que le langage soit facile à parser—, mais c'est tout.

            • [^] # Re: roue.com

              Posté par  . Évalué à 2.

              Calibre garantit que l'EPUB est correct uniquement si le XHTML source l'est, il faut donc quand même vérifier avec epubcheck après.

              pas bête le test avec epubcheck. Avant Calibre, j'utilise tidy sur mes fichiers html, pour les nettoyer. Visiblement c'est efficace car tous mes ePUB semblent correctement formés au final :

              Vérifications faites en utilisant les règles de la version epub 2.0.1.
              Aucune erreur ou avertissement détecté.
              epubcheck terminé

  • # gofpdf

    Posté par  . Évalué à 2.

    As-tu étudié la possibilité de générer un pdf avec gofpdf histoire de diminuer encore plus les dépendances ? En bonus c'est d'une rapidité déconcertante.
    https://github.com/jung-kurt/gofpdf

    • [^] # Re: gofpdf

      Posté par  (site Web personnel) . Évalué à 3.

      Il me semblait avoir vu passer ça, mais sur le moment j'ai cru que c'était un peu trop bas niveau. En fait, il me semble qu'il y a à peu près tout ce dont j'aurais besoin. Ceci dit, vu que j'ai l'export vers mom déjà pour les cas où TeX Live n'est pas installé, ça refroidit un peu mon enthousiasme :) Un autre détail, c'est que ça s'éloigne peut-être un peu de la philosophie du langage, qui est d'exporter vers d'autres langages et permettre à l'utilisateur, s'il connaît le langage cible, de pouvoir peaufiner. Mais je vais y penser, merci du pointeur !

  • # Et Org-mode

    Posté par  . Évalué à 1.

    Bon, c'est pas troll mais une question sérieuse.

    Je ne suis pas informaticien et j'écris beaucoup (texte scientifique en sciences humaines, documentations, traduction, etc)… des documents complexes (notes de bas, références, citations, etc) mais simplement pas vraiment de maths. Par contre, des tableaux, des graphiques à insérer oui…

    Et mon expérience de 10 ans a été : openoffice --» libreoffice --» LaTex --» Zim Wiki --» Org-mode. Et souvent des usages croisés.

    Et en fait je suis comblé aujourd'hui avec Org-mode ( que je n'utilise pas de manière aussi poussée que certains écrivains - Jay Dixit notamment) qui me permet de prendre toutes mes notes dans un langage assez simple et d'avoir une variété d'export assez grande.

    Par contre, je reconnais que c'est par toujours simple de gérer les réglages de l'export. Par contre, mes documents et notes sont désormais en .org et j'ai bon espoir de pouvoir les conserver de longues années grace à ça.

    • [^] # Re: Et Org-mode

      Posté par  (site Web personnel) . Évalué à 3.

      Bon, c'est pas troll mais une question sérieuse.

      Pas de soucis :)

      Je connais un peu org-mode aussi et c'est assez plein de fonctionnalités, en effet. Par contre, ça reste un langage de balisage léger très « dynamique » si on peut dire ça comme ça, pas très formel et qui protège peu des erreurs de balisage (pas prévu pour à la base, en même temps). Et, pour autant que je sache, il propose pas de moyen simple de faire du balisage sémantique flexible, même si j'imagine bien que, vu que c'est essentiellement lié à emacs (les équivalents sur d'autres éditeurs font pas le dixième et sont peut-être même pas compatibles), il doit peut-être y avoir moyen de l'étendre pour faire à peu près ce qu'on veut si on sait programmer en Emacs Lisp.

      Donc, je dirais, pour résumer, que les fonctionnalités et les caractéristiques d'org sont plutôt différentes de celles que l'on trouve dans frundis : c'est du balisage léger, avec syntaxe plus complexe qui protège moins des erreurs, dépendances vis-à-vis d'Emacs et Emacs Lisp, des fonctionnalités initialement plus orientées vers TODO list et autres, et qui petit à petit s'étendent, donnant au final un langage assez complexe, mais qui pourtant ne fait pas facilement du balisage sémantique ; frundis, en comparaison, plus léger, a des objectifs plus ciblés et il est possible d'apprendre le langage dans sa totalité assez vite. Le seul point qui réduit peut-être l'accessibilité, c'est que la documentation est dans des pages de manuel et que j'ai l'impression que ça a tendance à faire un peu peur, peut-être (troll inside) un traumatisme de pages man d'outil gnu décrivant trente-six mille options en vitesse et renvoyant à la fin sans exemples vers la page info, je sais pas :)

      • [^] # Re: Et Org-mode

        Posté par  . Évalué à 0.

        Je te suis assez sur ton constat pour Org-mode mais je dirais que la grande force est la fluidité de l'intégration dans emacs. Avec Org-capture pour les notes, Org-protocol pour récupérer des données en cours de navigation web… j'arrive à un workflow (en bon français) effectivement assez dynamique.

        Si j'ai bien suivi, Frundis n'est à ce stade utilisable qu'en ligne de commande avec un export pandoc ?

        À vrai, dire je serais assez preneur de voir un document un peu gros dans ce langage voir l'usage qui en est fait dans une vidéo.

        J'ai bien envie d'aller y mettre le nez en tout cas. Merci pour ce travail.

        • [^] # Re: Et Org-mode

          Posté par  (site Web personnel) . Évalué à 2.

          Si j'ai bien suivi, Frundis n'est à ce stade utilisable qu'en ligne de commande avec un export pandoc ?

          On peut exporter depuis la ligne de commande vers LaTeX, HTML, EPUB et, depuis plus récemment, vers markdown et groff mom. frundis, c'est juste un langage + l'outil en ligne de commande, il n'est pas lié à un éditeur ou interface particulière, n'importe quel éditeur de texte fait l'affaire, et la coloration syntaxique pour des documents roff (utilisé entre autre pour les pages de manuel sous linux) fait l'affaire pour frundis (la syntaxe de frundis étant un sous-ensemble simplifié).

          À vrai, dire je serais assez preneur de voir un document un peu gros dans ce langage voir l'usage qui en est fait dans une vidéo.

          Alors, des vidéos, j'ai pas ça sous la main. En exemples, il y a l'exemple sur la page du site et, en document plus gros, tu peux regarder les sources d'un des livres de kaoseto, celui-ci est assez simple (par contre, je sais pas si la version qui se trouve là est à jour totalement sur le langage, ça date d'il y a deux ans). Il permet de voir quand même dans le préambule qu'on peut inclure certains blocs uniquement pour l'export LaTeX (pour mettre en page plus joliment un poème dans la version LaTeX), tout en ayant un document qui permet d'exporter aussi vers les autres formats.

          • [^] # Re: Et Org-mode

            Posté par  (site Web personnel) . Évalué à 2.

            assez simple

            Enfin, il n'est pas si simple, parce qu'il inclut un fichier declarations.frundis commun à la plupart des autres livres, qui définit le style d'export de quelques éléments sémantiques et dans lequel sont utilisés aussi quelques variables ; pour un document simple, on peut faire beaucoup plus simple, ici c'est vraiment pour faire de la réutilisation entre divers documents pour un projet de plusieurs livres. Mais j'ai rien de mieux sous la main, donc j'espère que ça te donnera une idée des choses :)

            • [^] # Re: Et Org-mode

              Posté par  . Évalué à 0.

              Ok. Merci pour ton retour.

              C'est effectivement lisible sans trop de difficulté. La seule chose qui me gène toujours (mais c'est sûrement parce que je suis pas développeur) c'est l'obligation d'un retour à la ligne à chaque emphase (par ex)… ça casse un peu la lecture pour moi.
              Mais tu as fait un super boulot.
              J'ai bien envie de m'y essayer sur un projet d'atelier d'écriture qui commence bientôt. Tu utilises quel éditeur pour gérer la coloration au mieux ? Cela dit, je resterai bien sous emacs pour le reste (tâches, notes, etc).
              Par ailleurs, j'ai installé Go via le package sous Fedora 25 (c'est la version 1.7 de Go)… tu aurais un tuto un peu plus détaillé pour savoir ce qu'il y a à faire ensuite ?
              Belle journée.

              • [^] # Re: Et Org-mode

                Posté par  (site Web personnel) . Évalué à 2.

                C'est effectivement lisible sans trop de difficulté. La seule chose qui me gène toujours (mais c'est sûrement parce que je suis pas développeur) c'est l'obligation d'un retour à la ligne à chaque emphase (par ex)… ça casse un peu la lecture pour moi.

                Au tout début je m'étais fait la même remarque. Après, je me suis dit que si d'autres aimaient ceci, c'était qu'on s'y faisait. Je trouve après coup que c'est le cas, on s'y fait et, par rapport à LaTeX, on finit par apprécier le style plus épuré avec moins d'accolades et la distinction claire entre ce qui est balisage et le texte normal. Les deux styles ont leur plus et leur moins, je dirais, mais en pratique on s'y fait.

                J'ai bien envie de m'y essayer sur un projet d'atelier d'écriture qui commence bientôt. Tu utilises quel éditeur pour gérer la coloration au mieux ? Cela dit, je resterai bien sous emacs pour le reste (tâches, notes, etc).

                Dans les sources il y a un fichier de coloration syntaxique vim spécifique pour frundis, mais, honêtement, si tu connais emacs, reste sur emacs : le nroff-mode fait parfaitement l'affaire. Je connais pas très bien emacs, mais un commentaire du genre .\" -*-nroff-*- en haut d'un fichier devrait activer le mode (je suppose qu'il y a moyen de lui dire aussi que tout fichier avec l'extension .frundis doit utiliser le mode nroff).

                Par ailleurs, j'ai installé Go via le package sous Fedora 25 (c'est la version 1.7 de Go)… tu aurais un tuto un peu plus détaillé pour savoir ce qu'il y a à faire ensuite ?

                Alors, dans le .bashrc, tu écris :

                export GOPATH="$HOME/go"
                export PATH="$GOPATH/bin:$PATH"
                

                Ça dit que tous les programmes go seront installés dans le répertoire $HOME/go, et après on ajuste la variable PATH pour que bash trouve les exécutables.

                Et ensuite (après avoir fait source ~/.bashrc) juste lancer la commande : go get github.com/anaseto/gofrundis/bin/frundis. Il n'y a rien d'autre à faire, la commande frundis et alors disponible normalement.

                Les pages de manuel, par contre, il faut les placer manuellement à un endroit où man les trouve (ou sinon, plus simple, juste les lire sur le site, ou bien lancer man ./frundis.1 en spécifiant le chemin).

                • [^] # Re: Et Org-mode

                  Posté par  . Évalué à 1.

                  Merci de ton retour.

                  Dans les sources il y a un fichier de coloration syntaxique vim spécifique pour frundis, mais, honêtement, si tu connais emacs, reste sur emacs : le nroff-mode fait parfaitement l'affaire. Je connais pas très bien emacs, mais un commentaire du genre .\" --nroff-- en haut d'un fichier devrait activer le mode (je suppose qu'il y a moyen de lui dire aussi que tout fichier avec l'extension .frundis doit utiliser le mode nroff).

                  Alors, effectivement, il suffit dans rajouter dans le fichier de configuration d'emacs (.emacs ou init.el la plupart du temps)

                  ;;;;;;;; Pour associer l'extension .frundis au mode de coloration nroff-mode ;;;;;;;;;
                  (add-to-list 'auto-mode-alist '("\\.frundis\\'" . nroff-mode))

                  Pour le reste, l'installation semble fonctionner. Je vais faire quelques tests. Pour ne pas polluer les commentaires, as-tu déjà l'idée de créer un canal IRC freenode dédié ? ou autre chose ?

                  • [^] # Re: Et Org-mode

                    Posté par  (site Web personnel) . Évalué à 2.

                    Pour le reste, l'installation semble fonctionner. Je vais faire quelques tests. Pour ne pas polluer les commentaires, as-tu déjà l'idée de créer un canal IRC freenode dédié ? ou autre chose ?

                    Ayant juste, à ma connaissance, que quelques utilisateurs, je n'y ai pas trop réfléchi encore, à vrai dire, mais il faudrait, oui :) En attendant, il est possible de créer des tickets sur github ou juste m'envoyer un mail, les deux me vont, qu'il s'agisse d'un bug ou juste une question ou autre. D'ailleurs, quand on se pose une question, c'est souvent que quelque chose n'est pas suffisamment bien expliqué dans la doc, donc ça m'intéresse !

                    • [^] # Re: Et Org-mode

                      Posté par  (site Web personnel) . Évalué à 2.

                      mais il faudrait, oui :)

                      Voilà, j'ai du coup créé une liste de diffusion pour les utilisateurs de frundis chez tuxfamily. J'explique maintenant ici comment s'y inscrire.

                      • [^] # Re: Et Org-mode

                        Posté par  . Évalué à 0.

                        Ok, super. Je me inscris. ;)

                        • [^] # Re: Et Org-mode

                          Posté par  . Évalué à 0.

                          Je profite de l'espace ici pour documenter un souhait à la communauté linuxfr…

                          Frundis pourrait devenir un intermédiaire entre markdown et LaTeX à condition que quelqu'un s'empare de son intégration dans les éditeurs existants. À bon entendeur… !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.