[Toybox] Editors and such.

[David Seikel]

3AM this side of the planet, one last email before bed.

On Tue, 22 Nov 2011 08:02:19 -0600 Rob Landley <rob at landley.net> wrote:

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

It was too far to swim.

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

Why is it when I say I hate vi, people assume I love emacs?  I won't
use either of them if I can help it.

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

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

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

Yes, I read your blog about that.

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

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

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

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

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

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


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20111123/aa9a9d47/attachment-0004.pgp>