💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › stppj8$j6u$1@dont-email.me… captured on 2023-05-24 at 18:21:28. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
From: Luca Saiu <luca@ageinghacker.net>
Subject: Gemini markup extensions [Was: Re: a solution for emphasis]
Date: Mon, 07 Feb 2022 01:36:55 +0100
Message-ID: <stppj8$j6u$1@dont-email.me>
On 2022-02-05 at 00:13 +0100, Gustaf Erikson wrote, mostly in
gemini://gerikson.com/gemlog/gemini-sux/e-m-p-h-a-s-i-s.gmi :
This post is a bit of a joke, poking fun at the almost
utter lack of semantic signaling in gemtext. No-one would be happier
than me if the community could agree that words within asterisks would
be equivalent to the <em> tag in HTML, while words within underscores
would be <strong>, and we could rely on clients (and screenreaders!) to
interpret them as such.
The fact that the delimiters “*” and “_” are symmetrical makes it
difficult to parse them and introduces the possibility of mismatches.
How would we render “*a*b*c*d”? And “*a*b*c*d*”?
An example such as “a*b_c*d_” makes us feel uneasy because of the lack
of proper nesting; however it is possible to render all parts of it with
combinations of <em>, <strong>, both or neither. Do we want to allow
it? But then if we have added a special meaning for * and _ then I want
something to handle <tt> as well, ideally allowing unescaped “*” and “_”
inside.
If we are considering amending the Gemini specification, and I am not
necessarily saying we should, then I will take the liberty of proposing
a few guidelines.
These are part of, if you will, a meta-specification: desirable
properties that an acceptable specification is required to satisfy in my
opinion.
For example the current Gemini specification dictates a special
rendering for “```” at the beginning of a line, but provides no way to
specify a literal sequence of three backtick characters in the same
position in ordinary text or (which is more serious) a way of
embedding a literal sequence of three backtick characters inside
preformatted text.
However: Any escaping syntax, for example in “```”, would break
compatibility with existing documents: in particular
it would complicate copying and pasting between Gemini
and plain text.
Notice that Gustaf Erikson's “*” and “_” syntax makes it difficult to
insert literal “*” and “_” characters in ordinary text without an
escape syntax. This would be a common mistake in human-written text.
For example the current specification limits headings nesting to a
level of three: it is possible to have a titled section with a
sub-section and a sub-sub-section, but no section more deeply nested
that that. This limit is arbitrary and does not simplify
implementations. It should be removed.
However: even an apparently harmless generalisation such as removing
the nesting restriction on headings also breaks
compatibility. For example, “####” at the beginning of a
line would no longer be considered ordinary text.
The limit on list nesting does bother me aesthetically, but I understand
that this limit does make implementations simpler. (By contrast
allowing, for example, up to two levels of list nesting and no more
would be gratuitous and silly, and would count as an arbitrary limit to
reject.)
A problem of Gemini is that we dislike incompatibility and extensions,
but the specification is (as it normally happens in human affairs) not
perfect.
Would it be possible to introduce new features such as an emphasis
syntax and escaping that would still render acceptably with the current
clients? If so this is another meta-specification property:
Any usage of a new feature should still render in a way that is easily
understandable by a human using a client only implementing the
official specification as of 2022-02-07.
The Gemini markup system is “line oriented” and no elements really nest:
if an HTML DOM is a tree a Gemini DOM is a list.
All the special formatting is performed at the top level, and inside a
normal block of text no character is interpreted as special. This is a
simplification for the sake of minimalism, and does not feel wrong --
but then we have to reject <em> and <strong>.
The lack of escaping, on the other hand, to me really feels like a
design short-sight mistake.
I think that Gemini as it stands is a worse fit for technical writing
than for free-flow text.
--
Luca Saiu -- http://ageinghacker.net
I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".
Parent:
a solution for emphasis (by Gustaf Erikson <gerikson@gmial.com> on Sat, 05 Feb 2022 00:13:15 +0100)
Children: