With inspiration from kensanata in the #gemini channel on tilde.chat, I
present the solution for emphasis in Gemini: Sperrsatz

=> gemini://gerikson.com/gemlog/gemini-sux/e-m-p-h-a-s-i-s.gmi

When you want to emphasize a word, simply add a NARROW NO-BREAK SPACE
(U+202F) between each letter.

/g.

--
In the beginning was the command line^Wpatch panel
=> gemini://gerikson.com/

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 every special syntax there shall be an escape syntax.
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.

* There shall be no arbitrary limits.
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:

* Compatibility with old clients
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".

Luca Saiu <luca@ageinghacker.net> writes:

> 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 :

[long interesting discussion snipped]

Thanks for taking the time to read my post and reply!

Please note however, that I am not proposing a *specification* change,
merely that enough clients recognize the "*"/"_" convention to enable a
writer to be relatively confident that they can use this "markup" as
intended.

> I think that Gemini as it stands is a worse fit for technical writing
> than for free-flow text.

I agree. To be fair, it's not meant to be all-encompassing.

Cheers,

/g.

--
..sig goes here

Gustaf Erikson posted:
>> 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.

to which Luca Saiu <luca@ageinghacker.net> replied:
> 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*”?

I would agree that single character '*' and '_' delimiters aren't going
to work well.

Better, but maybe not perfect, would be regular expressions matching
"\w\*[a-zA-Z0-9-]+\*[.,;!]?\w"and "\w_[a-zA-Z0-9-]+_[.,;!]?\w", where
"\w" means word separator / whitespace ([ \t\n\r] etc.).

So, then,
"*SURPRISE*!!" would match (assuming word separation),
"*a*b*c*d*" would (with word separation) unambiguously be <em>a*b*c*d</em>,
"*a*b*c*d" would not match (be rendered as written), and
"Please be _very_ careful." would contain <u>very</u>.

I would think that good regular expression matching would be able to
separate the common cases from the unusual or potentially ambiguous
ones.
-WBE

Winston <wbe@UBEBLOCK.psr.com.invalid> writes:
> "*SURPRISE*!!" would match (assuming word separation),
> "Please be _very_ careful." would contain <u>very</u>.

As I used Gnus to view the article I just posted, I see that Emacs shows
the "*SURPRISE*" in bold with the asterisks, and shows the _very_ as
underlined without its leading and trailing underscores. It did
not, however, show the *a*b*c*d* in bold, so that differs from what I
suggested.

So another alternative would be to adopt what Emacs does.
-WBE

Am 07.02.22 um 11:33 schrieb Gustaf Erikson:
> Please note however, that I am not proposing a *specification* change,
> merely that enough clients recognize the "*"/"_" convention to enable a
> writer to be relatively confident that they can use this "markup" as
> intended.

The German Newspaper "Tageszeitung" from Berlin gemini://taz.de uses
*text..*, just an example. They seem to feel a need.

My personal opinion would be, that having somewhat agreed markup would
lead to less use of abusing special unicode characters for fulfilling
this obvious need. So it would help people using a screenreader. Also it
would not end an a chaos of different own ideas.

Martin

On 2022-02-08, Martin <martin@datapulp.de> wrote:

> My personal opinion would be, that having somewhat agreed markup would
> lead to less use of abusing special unicode characters for fulfilling
> this obvious need. So it would help people using a screenreader. Also it
> would not end an a chaos of different own ideas.

Oh, very much this. Using unicode chars is the inverse of what I always
understood to be the purpose of gemini. The use of a "magic string" to denote
a link was specifically chosen to avoid the issue of non-standard characters
having impact on the protocol, your ability to write it, and your ability to
read it.

Having said that, and _pace_ the question of accessibility, I'm coming to the
conclusion that some form of acceptance of the two primary span elements,
<em> and <strong>, need to inform future development in the gemini protocol.
They are necessary for all sorts of reasons (inline quotes, titles of books,
plays, music, for poetry), there is a clear demand for them, they are being
*hacked* into people's capsules no matter what the spec says, and they offer
clear and unambiguous advantages for those using screenreaders.

I don't know what shape they should take, but I'd note that newsreaders have
been doing this for a not insignificant period, using essentially the same
characters as markdown.
--
dgold <news@dgold.eu>

I always asked myself, why we do markup not using ASCII characters? Did
we forget about our roots? ;-)

For emphasis e.g. there are ASCII characters 14 + 15. Once upon a time
it was implemented by exchanging a black color ribbon with a red one for
emphasis.

https://en.wikipedia.org/wiki/Shift_Out_and_Shift_In_characters

"Emphasis" would ~ be what in HTML may be called <strong>.

HTML could have be done with ASCII Control Codes 17 - 20 instead of
<xxx> and </xxx>. These control codes are especially thought out for
these kind of "flexible usage". And making use of them would have given
a better integration as inserting another level of meta-usage of normal
characters with all their problems, like escaping for displaying control
strings again in readable text and so on

.... just some rebel thoughts

Martin

On 2022-02-08, Martin <martin@datapulp.de> wrote:
> I always asked myself, why we do markup not using ASCII characters? Did
> we forget about our roots? ;-)
>
mainly because ascii control chars are

- obscure, as in people don't know them
- obscure, as in they're not present in an editor
- obscure, as in they're not easily identified

Don't underestimate the simplicity and accessibility created by the use of
simple direct formatting.

--
dgold <news@dgold.eu>

Martin <martin@datapulp.de> writes:

> I always asked myself, why we do markup not using ASCII characters?
> Did we forget about our roots? ;-)
>
> For emphasis e.g. there are ASCII characters 14 + 15. Once upon a time
> it was implemented by exchanging a black color ribbon with a red one
> for emphasis.
>
> https://en.wikipedia.org/wiki/Shift_Out_and_Shift_In_characters
>
> "Emphasis" would ~ be what in HTML may be called <strong>.
>
> HTML could have be done with ASCII Control Codes 17 - 20 instead of
> <xxx> and </xxx>. These control codes are especially thought out for
> these kind of "flexible usage". And making use of them would have
> given a better integration as inserting another level of meta-usage of
> normal characters with all their problems, like escaping for
> displaying control strings again in readable text and so on
>
> ... just some rebel thoughts
>
> Martin

We should bring back Wordstar formatting.

http://justsolve.archiveteam.org/wiki/WordStar

Or why not ROFF?

/g.

--
Just another old hacker

Daniel Goldsmith <dgold@dgold.invalid> wrote:
> Oh, very much this. Using unicode chars is the inverse of what I always
> understood to be the purpose of gemini. The use of a "magic string" to denote
> a link was specifically chosen to avoid the issue of non-standard characters
> having impact on the protocol, your ability to write it, and your ability to
> read it.

I really dislike Unicode, anyways.

> Having said that, and _pace_ the question of accessibility, I'm coming to the
> conclusion that some form of acceptance of the two primary span elements,
> <em> and <strong>, need to inform future development in the gemini protocol.
> They are necessary for all sorts of reasons (inline quotes, titles of books,
> plays, music, for poetry), there is a clear demand for them, they are being
> *hacked* into people's capsules no matter what the spec says, and they offer
> clear and unambiguous advantages for those using screenreaders.

Yes, there are some advantages, but it results in some extra complexity, and
possible confusion if they are used for something other than formatting. (I
mention below, a possible solution).

(However, I agree this is one deficiency of Gemini format; these are many of
the kind of things which should be wanted in text. Yes, <em> and <strong> are
probably the important ones, and possibly <code> as well, and also footnotes.)

> I don't know what shape they should take, but I'd note that newsreaders have
> been doing this for a not insignificant period, using essentially the same
> characters as markdown.

Whatever they should take, if extensions are made to the format, then I might
suggest to follow the principles (in order to avoid breaking compatibility,
and to ensure that files that have text that would otherwise be confused for
the extended formatting, will still be displayed correctly):

* A extra parameter of the MIME type indicates that this extended formatting
is being used.

* Clients MUST or SHOULD (I am not sure which should be appropriate here)
ignore unrecognized parameters in the MIME type and treat it like the same
MIME type without the extra parameter.

* Servers that serve files using this extended formatting MUST include that
parameter and files that don't use it MUST NOT have this parameter.

* Clients MAY implement the extended formatting specification. If they do,
then it SHOULD have an option for the end user to turn on/off this option
regardless of the MIME type of the response.

This is one possible solution; maybe you have other ideas. (Another idea
is a special command inside of the file itself.)

Regardless, the specification must be made clear about how it is working,
and make available reference implementations that you can compare with,
and to confirm that the file is interpreted in the intended way.

(I also have many other ideas, and will try to figure out more details
and then to see what it will be, too.)

--
Don't laugh at the moon when it is day time in France.

On 2022-02-07, Winston <wbe@UBEBLOCK.psr.com.invalid> wrote:
> Winston <wbe@UBEBLOCK.psr.com.invalid> writes:
>> "*SURPRISE*!!" would match (assuming word separation),
>> "Please be _very_ careful." would contain <u>very</u>.
>
> As I used Gnus to view the article I just posted, I see that Emacs shows
> the "*SURPRISE*" in bold with the asterisks, and shows the _very_ as
> underlined without its leading and trailing underscores. It did
> not, however, show the *a*b*c*d* in bold, so that differs from what I
> suggested.
>
> So another alternative would be to adopt what Emacs does.
> -WBE

I do not think any more rendering directives should be added to gemini.
If more advanced rendering is required then use a pdf document A gemini
URL can point to a pdf document. There is little value in recreating
HTML in gemini.

Vlad Markov <vlad@happy.dwarf7.net> writes:

> On 2022-02-07, Winston <wbe@UBEBLOCK.psr.com.invalid> wrote:
> I do not think any more rendering directives should be added to gemini.
> If more advanced rendering is required then use a pdf document A gemini
> URL can point to a pdf document. There is little value in recreating
> HTML in gemini.

I do think gemtext should be declared "done", and no extensions
added. But it's perfectly reasonable to serve other content-types over
Gemini. I'm strongly considering serving org-mode text.

--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow

Jason McBrayer <jmcbray@carcosa.net> posted:
> Vlad Markov <vlad@happy.dwarf7.net> writes:
>
===[No]=== >> On 2022-02-07, Winston <wbe@UBEBLOCK.psr.com.invalid> wrote:
>> I do not think any more rendering directives should be added to gemini.
>> If more advanced rendering is required then use a pdf document A gemini
>> URL can point to a pdf document. There is little value in recreating
>> HTML in gemini.

For the record, that was Vlad's comment, not mine.
-WBE

On 07/02/2022 14:53, Winston wrote:
> Gustaf Erikson posted:
> [...]
>
> So, then,
> "*SURPRISE*!!" would match (assuming word separation),
> "*a*b*c*d*" would (with word separation) unambiguously be <em>a*b*c*d</em>,
> "*a*b*c*d" would not match (be rendered as written), and
> "Please be _very_ careful." would contain <u>very</u>.

Thunderbird seems to render these correctly (as expected at least;
*a*b*c*d" is rendered as written.

Also TB doesn't remove characters, only adds string, underling or
italics as /required/.

Isn't this a subset of textile? https://textile-lang.com/

It was supported in a number of forums around 2000s. Or maybe it has a
different name, I don't know.

reidrac@minibox.invalid writes:

> On 07/02/2022 14:53, Winston wrote:
>
> Isn't this a subset of textile? https://textile-lang.com/
>
> It was supported in a number of forums around 2000s. Or maybe it has a
> different name, I don't know.

All the early 2000 simple text formatters inspired each other.

Markdown won out, big, so it's the game in town right now.

/g.

--
send lawyers, guns, and money
the shit has hit the fan

reidrac@minibox.invalid wrote:

>
> Also TB doesn't remove characters, only adds string, underling or italics as
> /required/.

With the Quote Colors add-on you can hide what it calls
the "font effect delimiters"