Nathan Galt mailinglists at ngalt.com
Fri Sep 11 21:30:23 BST 2020
- - - - - - - - - - - - - - - - - - -
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.