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.
Posté par FLOZz (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.
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).
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é.
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) :
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.). :(
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…
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
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
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
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 longmulti line comment in Ruby=end
Ruby, utilisé par LinuxFr (RoR) copie Perl
# This is a single line comment in Perl=beginThisisslightlylongmultilinecommentinPerl=end
=head1 SECTION=for commentComment!=cut=begin commentComment! 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
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
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 :)
# Ô ironie, quand tu nous tiens…
Posté par SpaceFox (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
[^] # Re: Ô ironie, quand tu nous tiens…
Posté par FLOZz (site web personnel) . Évalué à 4. Dernière modification le 13 avril 2023 à 12:59.
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
rst2gemtextfait 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).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é. :)
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) :
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 SpaceFox (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
[^] # Re: Ô ironie, quand tu nous tiens…
Posté par Ysabeau 🧶 (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 FLOZz (site web personnel) . Évalué à 3.
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) :
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 zurvan . É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
Ç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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
…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 zurvan . É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 Gil Cot ✔ (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 zurvan . É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 Gil Cot ✔ (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 :
Ruby, utilisé par LinuxFr (RoR) copie Perl
Mais Perl est un chouia plus subtil avec POD :D
Ç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 zurvan . É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 Gil Cot ✔ (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 ?) »
=beginet=endne 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ù==titrepasse.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 FLOZz (site web personnel) . Évalué à 3.
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.