• # Voir aussi, même thème

    Posté par  (site web personnel) . Évalué à 2 (+0/-0).

    https://noyaml.com/ en Anglais
    (Avec Ublock-Origin, vous pouvez tout bloquer. Les ressources tierces apportent seulement la coloration syntaxique)

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # Précédemment sur linuxfr

    Posté par  (site web personnel) . Évalué à 7 (+5/-0).

    https://linuxfr.org/users/anonyme/liens/the-yaml-document-from-hell

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Précédemment sur linuxfr

      Posté par  . Évalué à 7 (+5/-0).

      J'avais loupé ce premier épisode et comme les commentaires et votes sont fermés, je me permet de souligné ce fil de commentaire "J'aime le yaml" qui exprime particulièrement bien mon avis et mon vécu.

      Bien sûr rien est parfait, il y a des petits ratés mais quand on compare à d'autres formats, on est sur du moins pire.

      J'ai construit une base de connaissance avec du yaml (structuré) contenant du markdown (pour la mise en forme des champs texte long) le tout dans du Git. Pour générer divers outputs, dont un site statique. Ça a très bien fonctionné y compris avec des contributeurs pas techos.

      • [^] # Re: Précédemment sur linuxfr

        Posté par  . Évalué à 2 (+2/-1).

        Je sais pas si c'est pertinent de comparer YAML et JSON.
        JSON n'est (il me semble) pratiquement utilisé que pour le Javascript/Typescript, et ce pour des raisons évidentes.

        Du coup, effectivement que si on aime bien (comme moi) pouvoir mettre des commentaires et avoir des blocs bien aérés à la Python, YAML semble un meilleur choix.

        Par contre je pense que tu va plutôt choisir un format en fonction de ton langage, de ses bibliothèques et de l'influence de l'environnement.
        J'ai pas de stats sous la main, mais je suis certain de que le fait que Cargo utilise toml a une influence sur les projets Rust, à fortiori libres.

        • [^] # Re: Précédemment sur linuxfr

          Posté par  (site web personnel, Mastodon) . Évalué à 0 (+3/-4).

          Par contre je pense que tu va plutôt choisir un format en fonction de ton langage, de ses bibliothèques et de l'influence de l'environnement.

          J'espère pas. Tous les langages gèrent tous les formats. Le XML est a fuir. Le JSON est pas mal pour la stérilisation lisible. Il est pratique pour les appels Ajax et Api et autres.
          Mais clairement pour la configuration, Yaml est le meilleur choix.
          Pour la stérilisation et les appels api optimisé, protobuf est le meilleur.
          Évidemment en PHP, tu peux utiliser le .INI, en Rust le toml mais à la marge par simplicité.

          Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

          • [^] # Re: Précédemment sur linuxfr

            Posté par  . Évalué à 6 (+4/-0).

            Mais clairement pour la configuration, Yaml est le meilleur choix.

            Je ne suis pas de cet avis. C'est beaucoup trop complexe pour les utilisateurs de base. La syntaxe des fichiers de type « ini» est bien plus simple et tout aussi lisible (configurations via systemd-networkd vs netplan par exemple).

            • [^] # Re: Précédemment sur linuxfr

              Posté par  . Évalué à 5 (+4/-1).

              Je suis d'accord avec la complexité du Yaml, il y a des pièges un peu partout dont on n'a pas conscience. Et puis les syntaxes où les caractères invisibles (l'indentation) changent la signification du contenu, très peu pour moi…

              Donc vive le format Toml, en effet. La seule chose que je regrette un peu dans le Toml, ce sont les sous-sections: l'arboresence est très peu visible au premier coup d'oeil sur le document.

              • [^] # Re: Précédemment sur linuxfr

                Posté par  (site web personnel) . Évalué à 2 (+2/-2).

                les syntaxes où les caractères invisibles (l'indentation) changent la signification du contenu, très peu pour moi

                Pour qui veut les voir, ils sont tout à fait lisibles (par exemple LibreOffice offre de les afficher, en un clic).

                Adhérer à l'April, ça vous tente ?

                • [^] # Re: Précédemment sur linuxfr

                  Posté par  . Évalué à 4 (+2/-0). Dernière modification le 25 mai 2025 à 20:22.

                  Tu connais beaucoup de gens qui modifient des fichiers YAML dans LibreOffice ? 😆

                  Bon sans rire, on peut afficher les espaces dans vim ou dans nano mais comme c'est un truc dont on a rarement besoin, il faut chercher dans la doc pour savoir comment faire et cela n'améliore pas forcément la lisibilité. Le seul intérêt serait éventuellement d'éviter une espace en moins ou en trop.

                  • [^] # Re: Précédemment sur linuxfr

                    Posté par  (site web personnel) . Évalué à 4 (+2/-0).

                    Tu connais beaucoup de gens qui modifient des fichiers YAML dans LibreOffice ? 😆

                    C'est pourtant pas plus saugrenu que définir la (non)spec de yaml.

                    Je pensais plutôt que le fait que ce soit accessible en un clic dans LibreOffice (Writer plus précisément) illustrait à quel point c'est une fonctionnalité de base. Fonctionnalité que j'ai connu de base ailleurs, il y a bien longtemps, dans une galaxie logicielle lointaine, très lointaine. (Et cette fonctionnalité qui consiste à expliciter l'implicite ne prends pas ses origines que dans la métaphysique…)

                    Le seul intérêt serait éventuellement d'éviter une espace en moins ou en trop.

                    Pas seulement. Par exemple pour différencier efficacement les espèces d'espaces (un vrai zoo : j'en vois pas moins de 6 en bas du formulaire de commentaire). Et par ailleurs il existe de nombreux caractères « non imprimables » dont la visualisation rend la pratique plus confortable selon le contexte. Je ne dis pas souvent du bien de Writer mais là encore il est à la pointe. ;)

                    Adhérer à l'April, ça vous tente ?

                    • [^] # Re: Précédemment sur linuxfr

                      Posté par  . Évalué à 6 (+4/-0).

                      Utiliser un traitement de texte pour modifier ce type de fichier c'est justement le meilleur moyen pour avoir des espaces normales automatiquement remplacées par des espaces fines insécables pour obéir aux règles typographiques.

                      Un fichier de configuration ce n'est pas un document à modifier dans un traitement de texte. Jamais.

                      • [^] # Re: Précédemment sur linuxfr

                        Posté par  (site web personnel, Mastodon) . Évalué à 3 (+0/-0).

                        Mais on peut voir les différentes espaces justement et contrôler ce qu'on fait.

                        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                        • [^] # Re: Précédemment sur linuxfr

                          Posté par  . Évalué à 4 (+2/-0).

                          On peut également les voir dans les éditeurs de texte dédiés à cela : vim, emacs, nano, gedit, kate, etc. sans risquer qu'elles soient modifiées automatiquement. Avec en plus pour certains l’indentation automatique et la vérification syntaxique.

                        • [^] # Re: Précédemment sur linuxfr

                          Posté par  (site web personnel) . Évalué à 3 (+1/-0).

                          je suis plutôt d'accord avec Voltairine<

                          Un traitement de texte est fait pour gérer un document, pas du code1. Pour de la visualisation oui, ça va le faire.

                          C'est à l'éditeur de texte de fournir les outils adéquats, c'est le cas de gedit (avec le paquet gedit-plugins) qui a un greffon Indicateur d'espaces — accessible via les préférences — qui affiche les espaces et les tabulations2, bon pour vi et emacs ya aussi des greffons^W configurations3

                          1. cela m'a valu nombre de problèmes avec des docs d'exploitation où l'infogérant copiait-collait les commandes avec espace insécable ou tirets modifiés genre  —help au lieu de --help /o\ forcément ça fonctionnait moins bien. On est d'accord que c'est un problème de maîtrise du doc' pour le coup et que LibreOffice a des extensions pour l'afficher correctement dans le corps du texte, par exemple code highlighter 2 https://extensions.libreoffice.org/en/extensions/show/5814 ↩

                          2. pour gedit c'est bien visuel https://vi.stackexchange.com/questions/422/how-can-i-display-tabs-as-characters ↩

                          3. ya vi, emacs et vscodium qui ont leurs approches ;-) https://vi.stackexchange.com/questions/422/how-can-i-display-tabs-as-characters ↩

                          • [^] # Re: Précédemment sur linuxfr

                            Posté par  . Évalué à 5 (+2/-0).

                            cela m'a valu nombre de problèmes avec des docs d'exploitation où l'infogérant copiait-collait les commandes avec espace insécable ou tirets modifiés genre —help au lieu de --help /o\ forcément ça fonctionnait moins bien.

                            Moi j'ai eu la blague avec des commandes et des clés copiés dans le teams, si on fait pas gaffe ce dernier se permet de faire des remplacements, et d'un coup la clé (publique faut pas déconner) ssh fonctionne moins bien :P

                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                        • [^] # Re: Précédemment sur linuxfr

                          Posté par  (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 27 mai 2025 à 07:56.

                          Sur du texte en français / anglais / etc., LibreOffice / Grammalecte vont me dire s'il s'agit d'espaces sécables ou pas, éventuellement discuter de leur largeur, etc.

                          Sur du code, en général je n'ai besoin que d'espaces « basiques / simples / normaux / classiques » (sauf à avoir des chaînes de caractères au milieu pour écrire en français / anglais / etc.). Et mon principal souci c'est les espaces insécables que j'introduis par erreur en ne relâchant pas assez vite AltGr en tapant un # ou | suivi d'un(e) espace sur un Azerty, ce qui donne un espace insécable et qui parfois est bloquant pour le compilateur / interpréteur / linter qui passe derrière (pour un titre Markdown, pour un commentaire, pour une commande shell après un pipi, etc.). Et je lutte contre avec des configurations d'éditeur (pour vim set list listchars=nbsp:!), avec des « hooks de pre-commit » pour les détecter avant de les soumettre, avec des tests dans la chaîne de compilation, etc.

                          • [^] # Re: Précédemment sur linuxfr

                            Posté par  . Évalué à 4 (+1/-0).

                            on principal souci c'est les espaces insécables que j'introduis par erreur en ne relâchant pas assez vite AltGr

                            m'en parle pas avec la dernière mise à jour d'ubuntu ça n'arrête pas

                            cut -d'%' -f 2 | grep 'machin'
                             grep : commande introuvable

                            bon j'ai corrigé la blague pour grep en faisant un alias, mas après c'est les cut, et autre qui déconnent. Faut vraiment que je trouve là config pour que altGr+espace => espace et non l'insécable.

                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                    • [^] # Re: Précédemment sur linuxfr

                      Posté par  . Évalué à 4 (+2/-0).

                      Georges Perec

                      "Si tous les cons volaient, il ferait nuit" F. Dard

              • [^] # Re: Précédemment sur linuxfr

                Posté par  . Évalué à 5 (+3/-0).

                La seule chose que je regrette un peu dans le Toml, ce sont les sous-sections: l'arboresence est très peu visible au premier coup d'oeil sur le document

                C'est justement ce que je trouve rédhibitoire.

                TOML:

                [a]
b = 1

[a.c]
d = [ 1, 2, 3,]

                YAML:

                a:
  b: 1
  c:
    d: [ 1, 2, 3 ]

                JSON:

                {
  "a": {
    "b": 1,
    "c": {
      "d": [ 1, 2, 3 ]
    }
  }
}

                Y a pas photo IMHO : toml est peu clair, json plus verbeux que nécessaire, yaml ok.

                Et encore, j'ai été gentil avec toml en ne mélangeant pas les sections.

          • [^] # Re: Précédemment sur linuxfr

            Posté par  . Évalué à 2 (+1/-1).

            Tous les langages gèrent tous les formats. Le XML est a fuir. Le JSON est pas mal pour la sérialisation lisible. Il est pratique pour les appels Ajax et Api et autres.

            Oui je suis d'accord.

            "Si tous les cons volaient, il ferait nuit" F. Dard

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.