markdown dans les titrailles de section ?

a marqué ce sujet comme résolu.

En effet. Je n’ai pas grand chose à ajouter car c’est le cas, ce n’est pas rendu.

Il est prévu de rendre le markdown partout à terme, mais il n’y a pas d’ETA (ça va dépendre de si quelqu’un se motive — hé, c’est Hacktoberfest !). Ce pourrait être assez simple à réaliser potentiellement (enfin pas trop complexe en tout cas).

+1 -0

Merci pour le retour @Amaury ; je vais adapter ma rédaction en conséquence.

Pour la simplicité, j’ai un doute car :

  • il faudrait ne rendre que les formatage inline (quoique je ne sais pas si on peut facilement mettre une liste ou un tableau par exemple dans ce un champ uniligne) d’une part,
  • tout en évitant certains cas (par exemple commencer par un ou plusieurs #/> suivi d’espace),
  • et il faudrait retirer ce formatage pour créer le slug d’autre part. (tiens, faut que je vérifie que le cas est déjà traité avec les ancres de titres)

C’est pas un problème trivial en réalité, parce que le markdown qui a du sens dans un titre n’est qu’une toute petite partie de l’ensemble :

  1. Exposant, indice de façon certaine.
  2. Gras, italique, barré, code en ligne, pourquoi pas (bien que je puisse trouver des arguments contre très facilement).
  3. Des choses comme les formule en ligne, les abréviations ou les définitions de sigles pourraient être intéressante dans les titres qui sont dans le corps de texte, mais posent problème dans les tables des matières.

… et c’est à peu près tout. En particulier, on ne peut pas mettre de lien dans un titre, parce que les titres sont déjà des liens lorsqu’ils sont sous la forme d’une table des matières.

D’autre part, les points 3 et sans doute 2 imposent un traitement différent lorsque le titre est rendu dans le corps de texte et dans la table des matières.

Ce que vous dites est juste, mais… de fait, on a déjà un système en place pour faire du rendu Markdown exclusivement inline. zmd, notre moteur de rendu Markdown, le supporte (option opts.inline), et on l’utilise sur le site pour le rendu markdown des signatures.

Il faudrait vérifier l’étendu du mode inline, mais potentiellement, ce serait assez simple à gérer s’il est compatible en l’état avec les pré-requis. Ou reprendre le système existant de zmd pour en faire un autre encore plus restreint (ça implique la coopération de zmd mais c’est pas insurmontable a priori), car l’ensemble proposé par SpaceFox est encore plus restreint, de fait (liens notamment). De fait, je n’avais pas pensé à ces derniers, impliquant qu’on a un ensemble plus restreint que le mode inline.

Concernant le slug, c’est une bonne remarque. C’est potentiellement facile en prenant le rendu HTML et en retirant les balises (ce que Django permet de faire nativement).

En secondaire, ça pose la question d’un contexte global Markdown qui n’existe pas actuellement (par exemple pour définir des abréviations de façon globale, et en fait je ne vois pas d’autre application). Sinon je ne vois pas trop comment vous voulez mettre des abréviations dans un titre, par essence monoligne.

+0 -0

C’est bon à savoir, qu’il existe opts.inline. Je crains cependant (mais ceci est au doigt mouillé sans avoir lu le code) qu’il soit probablement nécessaire d’avoir un opts.title plus restreint.

Ah oui, s’il n’y a pas de contexte global, les auteur-e-s doivent donc rappeler les abréviations d’une section à une autre actuellement ? Ou alors le lectorat doit se rappeler de la section où l’abréviation apparait pour la première fois…

Concernant opts.inline vs opts.title, je pense aussi.

En l’état c’est ça oui, pour les abréviations. Ou alors il faut les répéter dans chaque section, car elles sont rendues indépendamment. Avoir un moyen d’en déclarer globalement ferait sens, mais ce n’est pas possible actuellement.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte