πŸ’Ύ Archived View for gemini.bunburya.eu β€Ί newsgroups β€Ί gemini β€Ί messages β€Ί stppj8$j6u$1@dont-email.me… captured on 2023-09-08 at 16:30:49. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-04-28)

-=-=-=-=-=-=-

Gemini markup extensions [Was: Re: a solution for emphasis]

Message headers

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>

Message content

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".

Related

Parent:

a solution for emphasis (by Gustaf Erikson <gerikson@gmial.com> on Sat, 05 Feb 2022 00:13:15 +0100)

Children:

Re: Gemini markup extensions [Was: Re: a solution for emphasis] (by Gustaf Erikson <gerikson@gmial.com> on Mon, 07 Feb 2022 11:33:13 +0100)

Re: Gemini markup extensions [Was: Re: a solution for emphasis] (by Winston <wbe@UBEBLOCK.psr.com.invalid> on Mon, 07 Feb 2022 09:53:50 -0500)