[Toybox] Editors and such.

[Rob Landley]

On 11/22/2011 11:31 AM, David Seikel wrote:
>> When I do an editor I want to make the keybindings flexible enough
>> that it can do vi, nano, microemacs, and ye olde wordstar keybindings
>> (ala joe, turbo C, and so on) from the same engine.  (I want a _C_
>> programming framework for manipulating a text buffer.)
> 
> That's exactly what I'm talking about.  B-)

Woot!

But I'm focusing on vi first because SUSv4 is the only publicly
available standard I've found (so far) that's worth following for this
sort of thing.

>>>  I'd also want to eventually add a very simple
>>> version of midnight commander (mc).
>>
>> I'm up for adding an mc clone if somebody wants to do that.  I don't
>> personally use it, but I do miss xtree gold from DOS and OS/2. :)
> 
> B-)
> 
>>> I'm thinking it would be useful to have some common support for full
>>> screen terminal driving.  The more command could probably use it to.
>>> So that would be four commands that could use it right off the bat,
>>> which is handy to help keep the design sane.  More, vi, something
>>> like nano, and something like a basic cut down mc.
>>
>> Priorities are wrong there.
> 
> Don't think I mentioned priorities, just that more COULD use it to, or
> just be as brain dead as simple can make it.  After all, toybox's main
> design goal is simple.

I like simple. :)

Alas, POSIX does not seem to like simple.  To start with, the spec
requires "more" to be terminal aware, which isn't entirely surprising
given what it does.  But it's not just _height_ aware, it's width aware too.

It's actually kinda fiddly: more needs to be able to wrap lines at the
screen size to figure out when to prompt, but the first 32 ascii
characters (all the stuff below space) don't consistently print one
character.  Some print nothing, some move the cursor around (tab,
newline, linefeed, backspace, form feed, whatever the heck "vertical
tab" does...)

In theory I can hijack catv and just escape most of the low-ascii
weirdness (so it's two characters, but it's _consistently_ two
characters whatever $TERM thinks).  In practice, when not hooked up to a
tty more is supposed to act like cat and pass data through unmodified...

I plan to do the simplest standards conformant implementation I can, and
every once in a while I go "you know, the standard's nuts, let's just
document the divergence"...

>> "These days" means DOS 3.x circa 1984.  All the unix terminal handling
>> magic was for different brands of printer in the 1970's (and then the
>> "glass tty" stuff where you essentially plugged in a printer that
>> didn't use up reams of paper), back before the computer had a video
>> card in it.
> 
> I'm old enough that "real time" for me used to mean you did not have to
> wait a week after submitting your OMR cards to peruse the printout and
> spot your "typo", but got the rare privilege of sitting on top of the
> noisy bastard printer and actually typing in your typo in "real time".

38911 basic bytes free is as far as I go back.  (poke 53280,0:poke
53281,1:poke 686,0... actually I'd have to look up that last one to be
sure I had it right, it's been a while.)

Most of my computer history before then is theoretical.  I've used my
Uncle Alan's HP minicomputer to play hangman on a line printer TTY, and
dialed into a couple creepy mainframes (assembly programming on some HP
thing with BCD, the zero and add packed instruction).  But they weren't
my normal programming environment.

> Now I'm happy working with embedded "real time", where half a
> microsecond too long to respond is a critical failure.

If you've got your own dedicated processor that can busy wait for input,
that's doable.  If you've got a multitasking OS on that processor,
latencies that tight are just not gonna happen.

>> The only reason this is NOT obvious to Unix greybeards is they haven't
>> questioned any of their established assumptions in over 30 years.
>> (You can spot these guys because they still think the word "hacker"
>> means something other than "variety of criminal that breaks into
>> computers through the internet".)
> 
> I resemble that remark.  Well, except I question assumptions all the
> time.  Gets me into lots of trouble, but usually means I write good
> code.  My beard IS starting to grey, but I look young for my age.

My father went grey at 19, so I'm less concerned about starting to do so
myself than I might otherwise be.

>>> The basic
>>> generic file editing stuff could also be used by the non screen
>>> editors.
>>
>> I'm told it's called "ncurses".  I once spent four hours beating a
>> "hello world" out of it, which is kind of sad if you think about it.
> 
> Yes, one of the first things I was glad to do, when I got the job of
> rewriting this embedded project from the ground up, was ditch ncurses.
> 
> Not the first time this company has hired me to rip their software a
> new one, but probably the last, I think they've run out of crappy
> software for me to rewrite.  B-)
> 
>>> BTW, I do have one command memorised for those times I accidentally
>>> find myself stuck in vi -
>>>
>>> killall -TERM vi
>>
>> escape-colon-q-exclamation point should get you out of anything.
> 
> killall gets you out of way more things than that.  :-P

You don't have to say -TERM, it's the default.

Rob

 1322248625.0