Suivi — Syntaxe markdown export markdown

#2026 Posté par Gil Cot ✔ (site web personnel, Mastodon) le 14 février 2022 à 03:30. État de l’entrée : corrigée. Assigné à Adrien Dorsaz. Licence CC By‑SA.

Étiquettes :

fév.

2022

Bonjour/Bonsoir/Bonnenuit,

J'ai posté récemment un journal, puis je viens d'en télécharger le markdown pour voir la différence d'avoir mon source en local.

Seconde surprise : le contenu a adopté des fin du ligne CRLF alors que dans ma rédaction ce n'était que du LF. Je suppose que c'est lié au "textarea" et/ou un traitement du site avant d'enregistrer en base ? Passons sur ce détail.

Première surprise : il y a des lignes avant le contenu, avec des fins de ligne LF… Et ça ressemble à ceci :

URL:     https://linuxfr.org/users/gilcot/journaux/retrospective-sur-la-mise-en-page-en-console
Title:   rétrospective sur la mise en page en console
Authors: Gil Cot
Date:    2022-02-05T12:15:49+01:00
Tags:    culture_unix, philosophie_unix, documentation, ligne_de_commande, nostalgie, bsd et linux
Score:   42


# le contenu commence ici

Pour l'avoir rencontré d'autres systèmes, le YAML Front Matter devrait commencer et se terminer par le triple tiret ? Par ailleurs, les "tags" devraient se présenter comme une liste (voir ci-après) ou une chaîne de mots séparés par une espace. Même remarque pour les "authors" des dépêches (tandis que pour un journal on devrait mettre au singulier.) Bref, j'aurais vu quelque chose comme :

---
URL:     https://linuxfr.org/users/gilcot/journaux/retrospective-sur-la-mise-en-page-en-console
Title:   rétrospective sur la mise en page en console
Author:  Gil Cot
Date:    2022-02-05T12:15:49+01:00
Tags:    
         - culture_unix
         - philosophie_unix
         - documentation
         - ligne_de_commande
         - nostalgie
         - bsd
         - linux
Score:   42
---


# le contenu commence ici

Édition : ou en mode plus compact pour la liste de tags

---
URL:     https://linuxfr.org/users/gilcot/journaux/retrospective-sur-la-mise-en-page-en-console
Title:   rétrospective sur la mise en page en console
Author:  Gil Cot
Date:    2022-02-05T12:15:49+01:00
Tags:    [culture_unix, philosophie_unix, documentation, ligne_de_commande, nostalgie, bsd, linux]
Score:   42
---


# le contenu commence ici

Nota : je vois le traitement de "Authors", pour les dépêches, comme celui de "Tags" ; tandis que ce devrait être juste "Author" pour les journaux (et le reste.)

Dites moi si j'ai loupé quelque chose, ou s'il y a une limitation avec Ruby.
Merci.

# L'entête est juste du texte

Posté par Adrien Dorsaz (site web personnel, Mastodon) le 14 février 2022 à 07:42. Évalué à 3 (+0/-0).

L'entête n'est pas du yaml, simplement du texte pour les humains :)

Pour le CR/LF, il faudrait que je vérifie avec un bon éditeur de texte (je n'en ai pas sur mon téléphone), mais je suis quasiment sûr que ce n'est que du LF (il est par contre peut-être doublé), car il n'y a pas de Windows pour servir LinuxFr.

Répondre
- [^] # Re: L'entête est juste du texte
  
  Posté par Gil Cot ✔ (site web personnel, Mastodon) le 15 février 2022 à 09:26. Évalué à 3 (+0/-0).
  
  Par ailleurs, les "tags" devraient se présenter comme une liste (voir ci-après) ou une chaîne de mots séparés par une espace.
  
  L'entête n'est pas du yaml, simplement du texte pour les humains :)
  
  OK, ça peut justifier de ne pas présenter Tags et Authors comme des listes, mais ça n'empêche que le « et » dans les étiquettes m'a un peu perturbé.
  
  Bien que ce ne soit pas du yaml, je trouve quand même bien d'avoir les triples tirets : beaucoup d'éditeurs GUI gèrent ça (possibilité de masquer/afficher, ou affichage comme des commentaires, et surtout non ajouté dans le rendu/aperçu/exportPDF —bref c'est distingué du contenu proprement dit.) Et pour les éditeurs qui ne gèrent pas encore cela, il y a des filets que je trouve mieux que de juste rajouter un paragraphe cryptique au début.
  
  “It is seldom that liberty of any kind is lost all at once.” ― David Hume
  
  Répondre
- [^] # Re: L'entête est juste du texte
  
  Posté par Adrien Dorsaz (site web personnel, Mastodon) le 17 février 2022 à 21:44. Évalué à 3 (+0/-0).
  
  Pour le CR/LF, il faudrait que je vérifie avec un bon éditeur de texte (je n'en ai pas sur mon téléphone), mais je suis quasiment sûr que ce n'est que du LF (il est par contre peut-être doublé), car il n'y a pas de Windows pour servir LinuxFr.
  
  J'ai vérifié avec vim et oui, tu as raison, il y a des CR qui trainent dans la seconde partie. C'est vraiment étrange 🤔
  
  Répondre
  - [^] # Re: L'entête est juste du texte
    
    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 17 février 2022 à 23:15. Évalué à 2 (+0/-0).
    Héhé :) C'est pour ça que je me suis dit que c'est peut-être introduit par le textarea (mais je n'avais pas retrouvé comment c'est normalisé…) …ou alors le traitement avant l'enregistrement en base (en fait maintenant je sais que c'est indépendant…)
    - https://www.generacodice.com/en/articolo/233974/do-line-endings-distinctions-apply-for-html-forms
    - https://stackoverflow.com/questions/19349924/line-endings-in-a-form-textarea
    “It is seldom that liberty of any kind is lost all at once.” ― David Hume
    Répondre
  - [^] # Re: L'entête est juste du texte
    
    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 19 février 2022 à 02:34. Évalué à 2 (+0/-0).
    
    S'il n'est pas simple de sauvegarder le contenu en LF, il reste l'autre approche : générer les entêtes ajoutées en CRLF… histoire que l'ensemble de l'export soit cohérent et que les outils n'en soient pas perturbés.
    
    “It is seldom that liberty of any kind is lost all at once.” ― David Hume
    
    Répondre
  - [^] # Re: L'entête est juste du texte
    
    Posté par Benoît Sibaud (site web personnel) le 05 juillet 2023 à 10:20. Évalué à 3 (+0/-0).
    
    Autre piste: HTTP amène des CR/LF, à voir si on convertit CR/LF en LF systématiquement ou pas.
    
    Répondre
    - [^] # Re: L'entête est juste du texte
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 19 avril 2024 à 16:30. Évalué à 2 (+0/-0).
      Si c'était HTTP, tout le fichier aurait des CR/LF, là, ce n'est que le contenu Markdown.
      
      Par exemple, le template pour le markdown des entrées de suivi, c'est:
      
      <%= render "nodes/front_matter", :content => @tracker %> <%= raw @tracker.wiki_body %>
      
      Le premier tag fait un rendu avec des LF.
      
      Le second tag qui contient "raw" fait un rendu avec des CRLF => je me demande si dans la base de donnée mysql, les colonnes textes sont stockées (ou lues) avec des CRLF.
      Répondre
      - [^] # Re: L'entête est juste du texte
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 19 avril 2024 à 16:42. Évalué à 2 (+0/-0).
        
        D'après DBEaver, le texte stocké dans cette colonne contient bien les CRLF.
        
        Ça serait donc au moment où on insert les données que les CRLF sont ajoutés, mais je ne comprends pas bien, car le "wiki_body" devrait être le contenu du text area.
        
        Bon, ce n'est pas un simple text area, car il y a l'éditeur javascript autour, c'est peut être lui le problème.
        
        Répondre
        
        [^] # Re: L'entête est juste du texte
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 19 avril 2024 à 17:30. Évalué à 2 (+0/-0). Dernière modification le 19 avril 2024 à 17:30.
        
        J'ai testé en désactivant l'éditeur markitup et ce n'est pas lui le problème. Apparemment, c'est le textarea et la normalisation HTML qui utilise du CRLF: https://stackoverflow.com/questions/14217101/what-character-represents-a-new-line-in-a-text-area
        
        Pour faire un markdown propre, il faudrait remplacer les CRLF par des LF au moment de la génération du fichier Markdown, comme ça on est sûr de ne pas impacter le reste de l'application.
        
        Répondre
        
        [^] # Re: L'entête est juste du texte
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 19 avril 2024 à 17:37. Évalué à 2 (+0/-0).
        
        Pour faire un markdown propre, il faudrait remplacer les CRLF par des LF au moment de la génération du fichier Markdown, comme ça on est sûr de ne pas impacter le reste de l'application.
        
        Ah voilà, c'est possible avec Ruby 1.9.
        
        Par exemple, on devrait patcher comme ça, le fichier "show.md.erb" pour les trackers:
        
        <%= render "nodes/front_matter", :content => @tracker %> <%= raw @tracker.wiki_body.encode(@tracker.wiki_body.encoding, universal_newline: true) %>
        
        J'ai testé ça et ça produit un fichier uniquement avec des LF.
        
        Répondre
        
        [^] # Re: L'entête est juste du texte
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 19 avril 2024 à 19:15. Évalué à 2 (+0/-0).
        
        Ah en lisant la doc, je vois que l'on peut même faire plus propre:
        
        <%= render "nodes/front_matter", :content => @tracker %> <%= raw @tracker.wiki_body.encode(universal_newline: true) %>
        
        Répondre
# Doublon

Posté par Adrien Dorsaz (site web personnel, Mastodon) le 19 avril 2024 à 16:21. Évalué à 2 (+0/-0).

Hello,

Un doublon pour la partie CRLF a été ouvert. C'est toujours étrange 🧐

Répondre
# Fait

Posté par Benoît Sibaud (site web personnel) le 14 janvier 2026 à 23:02. Évalué à 3 (+0/-0).

https://github.com/linuxfrorg/linuxfr.org/pull/392 fusionné et déployé (merci Trim)

Répondre

Envoyer un commentaire

Suivre le flux des commentaires

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