Ivy Foster <escondida at iff.ink> writes:
> Also, I do recognize that this idea is going to get shot down as
> paving the way for more extensibility, though we already have things
> like verbatim blocks and what have you (which are more esoteric than
> italic, so I don't buy the "we shouldn't support every use case"
> argument. It's far more common to emphasize words, to write titles of
> works, and so forth, than it is to do ASCII art (not that there's
> anything wrong with ASCII art; it's great) or present code blocks (the
> current demographics of the medium notwithstanding)).
Early on, before gemtext existed in its current form, I was pushing to
include inline emphasis (like Markdown; in fact, I was pushing to use a
strict subset of Markdown for Gemini documents). The reason I lost that
argument was because it substantially complicates the implementation of
clients, and if you use "*" both for inline emphasis and links, then you
run into a lot of ambiguities that various Markdown implementations
face. But it's not that it's not wanted, or out of scope (in the way
that, for example, color specification would be).
Thought experiment: we agree to implement inline emphasis, using some
set of markers on either side of a range of text. To simplify
implementation, the emphasis must be within a single line of text (not a
problem since we use long lines and let clients wrap them). Emphasis
markers are not allowed in any line types except plain and list. The
markers should be ones that are commonly/historically used in plain-text
emails. Which markers should we use?
We can't use '*', because it would be ambiguous at the beginning of
lines. We can't use '/', because it is ambiguous with Unix paths. We can
use '_', but it's less used (to imply underlines). I'm open to
suggestions.
Clients would be free to represent this emphasis in any way suitable for
their display, including but not limited to italics. Not doing anything,
and leaving the emphasis markers in place, remains a valid
implementation. Implementations that _do_ use some kind of text
properties, like italics, are free to leave the emphasis markers in the
output, or remove them.
Any thoughts on this? It shouldn't be too much of a barrier to
implementation, because a) existing clients that do nothing are all
still in-spec, and b) the restriction on emphasis crossing lines means
that you can simply implement it with a regex, after you first determine
the line type.
A reminder: this is just a thought experiment, not yet an argument that
it should be implemented.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
---
Previous in thread (17 of 29): 🗣️ Ivy Foster (escondida (a) iff.ink)
Next in thread (19 of 29): 🗣️ Ecmel Berk Canlıer (me (a) ecmelberk.com)