• # Ô ironie, quand tu nous tiens…

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Le projet Gemini est intéressant d’un point de vue technique, mais je ne crois pas à son utilisabilité au quotidien. Le meilleur exemple est que l’article en lien utilise beaucoup de fonctionnalités qui ne sont pas disponibles dans Gemtext, en particulier : la mise en emphase (en gras et en italique) et les liens « embarqués dans un paragraphe » avec du texte alternatif – je suis gentil, je pars du principe que les smileys sont gérés comme des caractères et que les « blocs de citation » permettent le code « inline » qui est beaucoup utilisé dans l’article.

    Je ne sais pas trop pourquoi Gemtext a été simplifié à ce point, au point d’en devenir inutilisable même pour un simple « texte bien conçu en-dehors de toute considération de style d’affichage », sachant que la simple gestion du protocole TLS (obligatoire) doit être beaucoup plus consommatrice en terme de ressources (CPU, RAM, réseau) que les deux points de mise en forme que je mentionne plus haut.

    Bref, ça me semble être un projet d’ingénieur rigolo, mais qui par conception ne semble pas pouvoir aller plus loin.

    La connaissance libre : https://zestedesavoir.com – Le saviez-vous ? Le drapeau Français est aussi de gauche.

    • [^] # Re: Ô ironie, quand tu nous tiens…

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 13 avril 2023 à 12:59.

      l’article en lien utilise beaucoup de fonctionnalités qui ne sont pas disponibles dans Gemtext, en particulier : la mise en emphase (en gras et en italique) et les liens « embarqués dans un paragraphe » avec du texte alternatif

      Le gras et l'italique sont effectivement absents de la version Gemtext de l'article.

      Pour les liens il n'y en a pas tellement d'intégrés directement dans les paragraphes de cet article-là (par contre dans mes autres articles c'est un festival 😅️), mais ça n'est pas vraiment un problème pour moi puisque ma bibliothèque rst2gemtext fait le travail de les sortir automatiquement en dessous du paragraphe (j'ai encore quelques améliorations à faire sur ce point je pense, comme numéroter les liens internes aux paragraphes mais c'est un détail).

      je suis gentil, je pars du principe que les smileys sont gérés comme des caractères et que les « blocs de citation » permettent le code « inline » qui est beaucoup utilisé dans l’article.

      Les smileys sont effectivement des caractères Unicode donc tout à fait utilisables dans un document Gemtext.

      Pour ce qui est du code inline (au sein d'un paragraphe), c'est comme pour le gras et l'italique, ça n'existe tout simplement pas dans la syntaxe Gemtext. Par contre, pas besoin de « bloc de citation » pour représenter des blocs de code, il y a bien une syntaxe prévue pour le texte préformaté. :)

      Je ne sais pas trop pourquoi Gemtext a été simplifié à ce point, au point d’en devenir inutilisable même pour un simple « texte bien conçu en-dehors de toute considération de style d’affichage », sachant que la simple gestion du protocole TLS (obligatoire) doit être beaucoup plus consommatrice en terme de ressources (CPU, RAM, réseau) que les deux points de mise en forme que je mentionne plus haut.

      La raison principale semble plutôt être la simplicité d'implémentation que la légèreté dans ce choix. Voici une citation extraite de la FAQ du projet (au sujet de l'absence de lien inline) :

      Because text/gemini is an entirely new format defined from scratch for Gemini, client authors will typically need to write their own code to parse and render the format from scratch, without being able to rely on a pre-existing, well-tested library implementation. Therefore, it is important that the format is extremely simple to handle correctly. The line-based format where text lines and link lines are separate concepts achieves this. There is no need for clients to scan each line character-by-character, testing for the presence of some special link syntax.


      Au final je ne pense pas que le format soit adapté à tous les contenus, mais pour tout ce qui est très « littéraire » (fiction, billet d'humeur, réflexions,…) ça fonctionne plutôt bien. On retrouve d'ailleurs nombre de capsules contenant des textes de fiction, comme Cosmic Voyage (gemini://cosmic.voyage/) par exemple.

      • [^] # Re: Ô ironie, quand tu nous tiens…

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Merci pour ces détails !

        La justification de Gemtext me conforte dans ce que je pensais : c’est complètement un projet d’ingénieur, qui part d’une considération technique (ici la simplicité d’implémentation) et pas d’un besoin fonctionnel. Ça ne le rends pas moins légitime, mais pour moi c’est un frein à son adoption à « grande » échelle.

        Pour les textes littéraires, personnellement je rajouterais quand même au moins un mode d’emphase (et idéalement les deux, même si le gras est plus rare que l’italique), des notes en bas de page, une différenciation entre « saut de ligne » et « saut de paragraphe » et la possibilité d’avoir un « séparateur » (en général trois étoiles * * * centrées sur une ligne).

        La connaissance libre : https://zestedesavoir.com – Le saviez-vous ? Le drapeau Français est aussi de gauche.

        • [^] # Re: Ô ironie, quand tu nous tiens…

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Et, je ne sais pas si Gemini fait ça, un sommaire pour les articles. C'est vraiment une fonctionnalité essentielle. Je parle d'un sommaire par articles, pas du contenu du site/

          Cela dit, je vais rester à mon SPIP :-) Les traqueurs et autres pubs c'est, avant tout, un choix de conception du site. Ce n'est pas lié au CMS.

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

          • [^] # Re: Ô ironie, quand tu nous tiens…

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

            Et, je ne sais pas si Gemini fait ça, un sommaire pour les articles.

            Cette fonctionnalité ne fait pas partie de Gemtext pour une bonne raison : c'est au client d'implémenter ce genre de choses.

            C'est d'ailleurs le cas du navigateur Lagrange qui peut afficher un sommaire basé sur les titres. Voici un exemple avec l'article dont il est question ici (volet à gauche) :

            Capture d'écran du sommaire dans Lagrange

            Les traqueurs et autres pubs c'est, avant tout, un choix de conception du site.

            En effet, mais puisque c'est possible, la majorité des sites le font, plus ou moins volontairement (analytics, scripts et fonts chargés depuis des CDN, captcha de chez Google, etc.). :(

      • [^] # Re: Ô ironie, quand tu nous tiens…

        Posté par  . Évalué à 2.

        je rédige la plupart de mes documents et notes en gemtext, je publie ça sur gemini, ssh pour accéder à mon serveur, petits scripts pour réaliser l'index etc c'est rapide et pratique

        Je dois dire que je suis assez frustré de ne pas pouvoir utiliser gras ou italique, ou plus d'expressivité de manière générale (en plus j'aime peu le markdown).

        Dans les faits, j'arrive quand même à m'en passer, au prix de quelques bidouilles, du genre utiliser

        la citation pour de l'emphase

        Ça apprend aussi à s'organiser.

        Je pense quand même que la raison de rendre 'simple' l'implémentation de la syntaxe est un peu bidon, vu que parser des blocs de code type ``` n'est pas vraiment plus simple non plus…

        j'utilise htmgem pour publier aussi sur le web (il n'y a qu'un seul serveur, qu'une seule source) :
        https://linuxfr.org/users/sbgodin/journaux/htmgem-v1-0-0-un-client-gemini-en-php

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

        • [^] # Re: Ô ironie, quand tu nous tiens…

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Je dois dire que je suis assez frustré de ne pas pouvoir utiliser gras ou italique, ou plus d'expressivité de manière générale (en plus j'aime peu le markdown).

          …pourtant c'est un sous-ensemble strict de markddown je trouve.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Ô ironie, quand tu nous tiens…

            Posté par  . Évalué à 2.

            oui, c'est ça, c'est un peu la double peine, mais je trouve que le pire de markdown c'est justement d'avoir choisi 1 * ou 2 * selon le type d'emphase, donc vu que ce n'est pas disponible, ça le rend presque moins pire car je déteste utiliser ça :)

            Le # pour l'entête n'est pas très futé non plus, vu que c'est utilisé également en commentaire dans certains langages et pour les hashtags, dans certains contextes ça peut faire des clashs mais bon…

            « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

            • [^] # Re: Ô ironie, quand tu nous tiens…

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Quel caractère aurais-tu utilisé …et qui ne risque pas d'être utilisé en commentaire dans un langage existant ? :D

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

              • [^] # Re: Ô ironie, quand tu nous tiens…

                Posté par  . Évalué à 2.

                en txt2tags ou créole (ainsi que sur wikipedia), c'est = qui est utilisé. À ma connaissance, ça n'est pas utilisé en commentaire ailleurs, et de toute façon c'est utilisé des 2 côtés du titre, ce qui limite la casse :

                = Titre 1 =

                == Titre 2 ==

                etc

                « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

                • [^] # Re: Ô ironie, quand tu nous tiens…

                  Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 21 avril 2023 à 18:06.

                  Les deux côtés ne sont pas obligatoires, on peut se limiter juste à ceux du début (en tout cas avec Creole et DokuWiki pour sûrs.) Maintenant, fun facts :

                  # This is a single line comment in Ruby
                  
                  =begin 
                  This is slightly long
                  multi line comment in Ruby
                  =end

                  Ruby, utilisé par LinuxFr (RoR) copie Perl

                  # This is a single line comment in Perl
                  
                  =begin 
                  This is slightly long
                  multi line comment in Perl
                  =end

                  Mais Perl est un chouia plus subtil avec POD :D

                  =head1 SECTION
                  
                  =for comment
                  
                  Comment!
                  
                  =cut
                  
                  =begin comment
                  
                  Comment! Number 2
                  
                  =end comment
                  
                  =cut

                  Ça c'est pour ce que j'ai déjà rencontré. Et il n'y a pas d'espace après le signe d'égalité (mais tous les moteurs wiki sont-ils aussi stricts ?)
                  Cependant, il y a certainement des exolang ou des langages plus mainstream mais de moindre diffusion qui peuvent avoir un traitement spécial pour les lignes commençant par le signe d'égalité…

                  “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                  • [^] # Re: Ô ironie, quand tu nous tiens…

                    Posté par  . Évalué à 2.

                    D'où l'intérêt de mettre un signe des deux côtés du titre pour limiter les effets de bords.

                    Ton code ruby ne pose pas de problème en txt2tags, par exemple en le pré visualisant dans

                    https://lionwiki-t2t.sourceforge.io/index.php?page=test

                    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

                    • [^] # Re: Ô ironie, quand tu nous tiens…

                      Posté par  (site web personnel, Mastodon) . Évalué à 2.

                      D'où ma remarque : « Et il n'y a pas d'espace après le signe d'égalité (mais tous les moteurs wiki sont-ils aussi stricts ?) » =begin et =end ne sont pas vus comme à cause de l'absence d'espace ; mais il me semble être déjà tombé sur un cas où c'était optionnel et où ==titre passe.
                      Mais bon, je voulais surtout souligner que = utilisé pour des commentaires ça existe. Tu subis le biais des gens qui sont confrontés à # pour les commentaires : j'en connais plein autour de moi qui n'ont jamais rencontré le cas, donc difficile d'en faire une « règle universelle » :)

                      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Ô ironie, quand tu nous tiens…

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

          Je pense quand même que la raison de rendre 'simple' l'implémentation de la syntaxe est un peu bidon, vu que parser des blocs de code type ``` n'est pas vraiment plus simple non plus…

          Je ne suis pas d'accord sur ce point. Pour les blocs préformatés, quand une ligne commence par ```, il suffit de continuer à lire ligne à ligne, sans rien chercher à interpréter, jusqu'à retomber sur une ligne commençant de nouveau par les mêmes trois backtick. Ça reste extrêmement basique :)

Suivre le flux des commentaires

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