Doléances sur le Zmarkdown de la V27

Absolument aucun.

@A-312 oui c’est possible

@Heziode si on se fie à ton travail, c’est dû au fait que le parseur créee un élément paragraph autour de l’élément abbr dans le cas où il y a une ligne blanche entre les deux lignes.

Donc il y à visiblement quelque chose de pas net.

EDIT: issue créée

Désolé si ça a été abordé, mais je viens de découvrir qu’un bloc dans un autre, les deux ayant des titres, celui le plus à l’intérieur n’a pas a bonne couleur de titre.

Exemple concret :

#include <iostream>
#include <limits>

template <typename T, typename Predicat>
void entree_securisee(T & variable, Predicat predicat)
{
    while (!(std::cin >> variable) || !predicat(variable))
    {
        std::cout << "Entrée invalide. Recommence." << std::endl;
        std::cin.clear();
        std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
    }
}

int main()
{
    int jour { 0 };
    std::cout << "Quel jour es-tu né ? ";
    entree_securisee(jour, [](int jour) -> bool { return jour > 0 && jour <= 31; });

    int mois { 0 };
    std::cout << "Quel mois ? ";
    entree_securisee(mois, [](int mois) -> bool { return mois > 0 && mois <= 12; });

    int annee { 0 };
    std::cout << "Quelle année ? ";
    entree_securisee(annee, [](int annee) -> bool { return annee > 1900; });

    double taille { 0.0 };
    std::cout << "Quelle taille ? ";
    entree_securisee(taille, [](double taille) -> bool { return taille > 0.0; });

    std::cout << "Tu es né le " << jour << "/" << mois << "/" << annee << " et tu mesure " << taille << "m." << std::endl;
    return 0;
}

template <typename T, typename Predicat>
void entree_securisee(T & variable, Predicat predicat)

Désolé informaticienzero, j’ai pas compris le problème

En gros, quand un bloc est utilisé au sein d’un autre et que les deux ont des titres, le titre du bloc intérieur a la même couleur que celui à l’extérieur.

Si tu regarde les exemples que j’ai mis, dns le premier, le titre du bloc question est rouge, alors que normalement il est bleu.

Dqnd le deuxième, le bloc information devrait avoir un titre bleu, mais il est gris comme celui du bloc secret.

C’est sûrement la faute d’un ">" manquant dans le selecteur css.

Plop !

Je viens de constater un autre truc. Dans le cas de deux citations distinctes, celles-ci sont regroupées en une seule, je peux mettre autant de retours à la ligne que je le souhaite, il faut un caractère visible pour que ce soit séparé.
J’en veux pour exemple ici, où on voit d’ailleurs que la source de la première citation est embarquée dans ce qui a été une fusion.

Le comportement n’est pas lié à la présence de Source.

C’est normal de ne pas avoir de target="_blank" pour les liens externes ?

On n’en a jamais eu.

Ça a même été l’objet d’un débat tout au début du projet. Ce qu’il en était sorti à l’époque c’est que l’utilisateur a le moyen de choisir s’il veut son lien (interne ou externe) dans un nouvel onglet ou sur la même page, et donc qu’on a pas à lui imposer une forme de navigation.

Par exemple inversé, j’ai souvent plusieurs onglets de ZdS ouverts.

Pour une citation :

> [1]:https://zestedesavoir.com/forums/sujet/11003/referencement-des-zestes/?page=2#p184073
> [2]:https://zestedesavoir.com/forums/sujet/11003/referencement-des-zestes/?page=2#p184125

Quel est le problème @A-312 ?

Sinon à propos de target="_blank". C’est connu comme un problème de sécurité important. Si vous souhaitez vraiment le mettre, n’oubliez pas rel="noopener noreferrer" mais si je me souviens bien, certaines anciennes version (de chaque navigateur) ne supporte pas cet attribut. Le meilleurs moyen pour ne pas avoir de problème de sécurité, c’est quand même de ne pas même target="_blank". Ça me semble raisonnable que ce soit à l’utilisateur de choisir s’il veut ou non ouvrir dans un nouvel onglet.

Les liens de type [lien][1] sont mal supportés dans une citation.

text

?

Ce que tu essayes de dire, c’est que si

[2]:https://zestedesavoir.com/forums/sujet/11003/referencement-des-zestes/?page=2#p184125

Apparaît dans un texte normal, c’est interpréter. Alors que si c’est dans une citation, ça ne l’est pas ?

Oui

Re-plop !

Je suis content de trouver le langage console dans les possibilités de blocs de code, mais pour une raison ou une autre, la classe hljs n’est pas ajoutée, ce qui fait que, comme les blocs de code sont embarqués dans un <figure> quand il y a une légende, le code est centé — et en décalage avec le centrage de la légende du fait de la numérotation des lignes.

Test

Je constate aussi que le surlignement qui est documenté n’est actuellement plus rendu. Je trouve un peu dommage, je me reposais dessus pour pouvoir mentionner « les lignes mises en évidence » et n’avoir à changer que du code le cas échéant.

Sur un autre plan, je trouve que la coloration syntaxique de PHP est un peu "pauvre". Apparemment, ce qui est actuellement coloré se limite aux "balises" ouvrantes et fermantes <?php ?>, mots-clés, commentaires et chaînes de caractères. Il serait possible de colorer aussi au moins les variables, j’imagine ?

Je vais volontiers créer les tickets dans les repos adéquats, j’ai déjà jeté un oeil à ce qui est présent sur zMarkdown, je ne crois pas avoir vu ces points.

Je constate aussi que le surlignement qui est documenté n’est actuellement plus rendu. Je trouve un peu dommage, je me reposais dessus pour pouvoir mentionner « les lignes mises en évidence » et n’avoir à changer que du code le cas échéant.

Déjà remonté, c’est lié au nouveau markdown qui fonctionne différement pour le highlight et qui n’est pas intégré. J’avais investigué le sujet il y a quelques mois.