[Toybox] Editors and such.

[Rob Landley]

On 11/22/2011 03:09 AM, David Seikel wrote:
> Just read your triage blog, and noticed that the only editor in the
> group is vi.

That's because the only editors in POSIX-2008 are "vi" and "ed".  (I was
triaging the utilities list in the current POSIX standard.)

> Unless I missed something.

Yes: the Austin Group POSIX standard update committee meetings back in
2006 or so.

> Personally, I'd want to add
> any simple editor that is not vi.  Vi fails my editor test, a complete
> lack of discoverability.

The only editors Linux has that are worth anything are notepad clones
(which was itself a clone of the original 1980's macintosh text editor).

That said, there are two de-facto standard editors available when you
ssh into a box and get a text mode session: vi and emacs.  And the main
advantage of vi has always been "it's not emacs".

Emacs is an utterly horrible waste of time that needs to die.  I'm aware
it provides a lithp programming framework for manipulating text buffers
the same way web browsers provide a Javascript programming framework for
manipulating web page contents, and that people have implemented a Lots
of Irritating Superfluous Parentheses script to feed zippy the pinhead
quotes to the Eliza program, AND ARE PROUD OF THIS.  I do not consider
this an argument _against_ my position.

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.)

But I haven't written that yet, and it's not low-hanging-fruit.

>  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. :)

> 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.

More can totally half-ass what it does because the standard requires a
"-num" option to specify the number of vertical lines, and it can always
fall back to 80x25 if it gets confused.  Me getting hung up on
infrastructure issues says more about me than about more.

Less has to get it _right_, as does line editing for a command shell.
Even before you get to cursor up: unix tty handling is epically crappy.
 My commodore 64 could backspace past the left edge of the screen and
continue from the right edge one line up.  A TRS-80 could do this.  Unix
derivatives _can't_, you have to know when you're at the left edge of
the screen and do the ansi sequences for "cursor up one, jump right
999".  Which means you have to know when backspace puts you at the left
edge of the screen, which means you need to know when outputting normal
characters put you off the _right_ edge of the screen...

That's right: if you don't know what your current screen size is, your
command shell can't backspace past a line wrap.  Welcome to unix
terminal handling.

> I like your idea that you can pretty much deal with ANSI codes these
> days.

I inflicted said idea upon busybox in 2006, and Erik Andersen was
de-facto doing it before my time.

"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.

In 1987 Unix got xterms, which are software.  So your output is being
parsed by a program, and having 237 different output formats a piece of
software can use to talk to another piece of software, even for
historical reasons, is insane.  Just PICK ONE.  And the one DOS picked
was a subset of ANSI, and they shipped over 100 million units, and Linux
inherited their hardware.

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 have seen a really tiny editor, that used a profiles concept,
> you could invoke it to act like simple versions of a number of popular
> editors.  It was written in pure assembler though.

When I was around 17 I wrote my first DOS bulletin board system (after
writing 3 of them on the commodore 64, and extensively mangling two
different versions of WWIV).  It compiled a rather sad scripting
language into bytecode, and used it to emulate the user interface of
WWIV and deadlock and a couple others.

Not a new idea, really.

> If I have time, I'd like to tackle writing a common library of full
> screen terminal app code, and basic generic file editing.

Infrastructure in search of a user isn't my idea of fun.  And you can
output raw ansi escape sequences with "echo", that's not the hard part.

Back in 2006 I wrote a function for busybox that fell back to something
like three different methods to determine screen size (COLUMNS and LINES
environment variables, tty querying of both stdin and stdout, and
finally the escape sequence to query xterm across a serial connection).

I blogged about it last week (on the 15th).  The problem is receiving
asynchronous escape sequence input after an arbitrary delay, potentially
intermixed (queued up behind) other random user input: doable, but has
to be part of a line editing thing that can make use of the rest of the
data rather than just discarding it.

Here's a fun one:

  cat /proc/mounts | less

When less outputs the escape sequence to query terminal parameters, it
has to peek not stdin but /dev/tty.  Except the cursor keys scrolling up
and down also come from /dev/tty, as do "user hit forward slash and
wants to type in a search regex"...  Innit fun?

Plus you have to figure out the width of what you're outputting, which
means isprint() and probably UTF8 awareness...  (Flashbacks to
fontmetrics in java 1.1, but we can assume monospace text grid...)

> 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.

> 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.

> Substituting -KILL if I'm feeling particularly annoyed at it.

Apparently, you are not the target audience of this command.  It's still
in posix.  (And busybox.)

Rob

 1321970539.0