A proposed scheme for parsing preformatted alt text

[Nathan Galt]

> On Sep 11, 2020, at 1:16 PM, Sean Conner <sean at conman.org> wrote:
> 
> 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).
> 

=> https://en.wikipedia.org/wiki/C0_and_C1_control_codes

Ooh, good catch. Yeah, ban ’em all except \t, \r, and \n.