[Toybox] Generic editor. Was: fold implementation

[Rob Landley]

On 04/08/14 11:45, David Seikel wrote:
>> The first half of this table is matching 00 through 1F in order, I'm
>> not sure the first entry of each pair is necessary? The rest of the
>> table is matching escape sequences starting with either ESC (27) or
>> 0x9b (which it says is the 8-bit encoding of ESC? What?) A bit
>> redundant, but let's worry about cleaning it up later...
> 
> 0x9b is officially called CSI, it's the eight bit encoding of "Esc [",
> not "Esc".  You missed the "[".  7 bit terminals should use "Esc [",
> 8 bit terminals should use CSI.  Even though in our modern world of
> pretend terminals 7 bit ones should be rare, in practice I've seen both
> the 7 and 8 bit versions sent.  Not really redundant, as not all
> sequences can start with both, but lots do.

This is the second mention of an "8-bit encoding". ASCII was 7 bit. The
IBM PC devoted the top 8 bits to graphics, "latin 1" in windows (which
became an ISO standard) did something else, and then unicode came along
and the top bit means to combine multiple characters.

I have yet to encounter "8 bit ascii" in the wild. If you're saying
"this is what the DEC VT100 did", then say that. If there's a standard,
tell me what it is, but "ascii" isn't a sufficient description.

I tried googling for it myself, but got "rarely used directly" ala
http://en.wikipedia.org/wiki/C0_and_C1_control_codes and that in a
unicode system
(http://en.wikipedia.org/wiki/Control_Sequence_Introducer#Sequence_elements)
it would have to be encoded as two bytes so esc [ would actually be clearer.

What terminal type makes it do this? (We're not going to support _every_
terminal type...)

> Mapping input bytes to keys is a big mess, several standards, several
> non standards, some terminals do their own thing.  This entire table is
> the "simple" way to do things.  Sure the code could get more complex to
> cut the table up into smaller bits, but we are aiming for simple, so
> that's the way I did it.  Some of this table came from standards, some
> came from me starting up several terminal programs and hitting keys to
> see what they sent.

I'd be interested to know which terminal programs sent which keys.

But mostly what I was thinking is that either escape, followed by the
rest of the sequence, is unique except for the fact you have "R" and "S"
defined for 0x9b twice (but both times, for 0x9b).

I'm not trying for perfect, I'm trying for "mostly works". If some term
program is crazy, it's crazy. Wait for the bug reports from people
actually trying to use it.

Anyway, this is a thing I need a dedicated block of time to wrap my head
around, and right now that time is going to deflate compression-side,
cleaning up init, and finishing the grep -ABC thing I've had
half-finished in my tree forever. Plus I've got a large TODO comment
block in vconfig for some reason (what was I doing with that...), need
to cleanup human_readable() so du.c can use it, and I'm doing an update
to code.html because the "generated" directory description is completely
out of date and it needs more name= navigation anchor tags. Oh, and the
roadmap should mention the binaries included in glibc since musl doesn't
include 'em. And of course Ashwini Sharma just posted two more commands
I need to look at...

After that, "watch.c" needs the same general code as "less" to display
only the first screen of output (no scrolling) and to allow the command
to be interrupted so we can run it again if it hasn't finished producing
output before the timeout period expires. So the display side of all
this comes in handy for that.

I need to read the rest of this email in the morning. :)

Rob

 1397004071.0