A proposed scheme for parsing preformatted alt text

[Sean Conner]

It was thus said that the Great Nathan Galt once stated:
> 
> On Sep 11, 2020, at 11:36 AM, Luke Emmet <luke at marmaladefoo.com> wrote:
> > 
> > Or are we going to say these implementation terminal escape codes are
> > left as an ad-hoc convention? That seems to have its own risks as
> > discussed on this thread and elsewhere.
> 
> [shock and horror that people are using ANSI codes for color]

  I've come across ECMA-48 [1] code usage on both gopher and Gemini.  It is
being done.

> Prior reading:
> 
> => https://en.wikipedia.org/wiki/Escape_character#ASCII_escape_character
> => https://the.exa.website/ a modern ls(1) replacement
> 
> I think ANSI color codes are up to 24-bit color now. Not all terminals
> support them (Terminal.app doesn’t; iTerm2 does), but they’re out there. I
> was looking up color codes so I could make my EXA_COLORS variable nicer
> and the whole process wasn’t pleasant.
> 
> Sounds like a good reason to explicitly disallow U+001B in the text/gemini
> spec and:

  Ban ESC and I can *still* send the codes.  The sequence '<ESC>[' is the
CONTROL SEQUENCE INTRODUCER and is only one of two ways it is represented. 
The other way is with codepoint 155 [2].  To be truely safe, you need to
filter out all control codes (control set 0, from 0 to 31, 127 (which is
technically not in any control set, and control set 1, from 128 to 159) with
the exception of HT (horizonantal tab), CR (carriage return) and LF (line
feed).

  -spc (Did a deep dive into a few years ago ... )

[1]	ECMA-48 is the actual standard describing these codes.  ANSI got out
	of the game in the 80s (or maybe very early 90s) if I recall
	correctly.

[2]	In any of the ISO 8-bit character sets, this is character 155.
	Unicode also uses this value, but when encoded as UTF-8, it's
	represented as the bytes 194,155.