[Toybox] Editors and such.

[David Seikel]

On Fri, 25 Nov 2011 13:17:05 -0600 Rob Landley <rob at landley.net> wrote:

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

I woke up this morning with the remnants of a dream about how to get
started on my MC clone.  Sometimes I program in my sleep.  Spent much
of the rest of today writing it down and blowing life into it as a
proper design for a useful toybox full screen handling library and
generic editor (with flexible keybindings as stated above), with
pretensions of supporting MC style stuff to.  I even started writing out
suitable data structures.

I'm guessing that we don't want a full vi clone, just a minimal one.
As mentioned in this thread long ago, I don't use vi.  So I would want
those that do use vi to agree on an absolute bare minimal subset that we
should implement.  And perhaps a second almost minimal "nice to have"
subset.  I can do the same for MC's editor, and nano is likely
minimalist enough.  Wordstar I used long ago, and can probably find the
relevant details.  Microemacs I think I used once, emacs fans can sort
that out for us.  Then see what that adds up to as a common set of bare
minimum editor features to write generically.

One of the more interesting ideas I came up with was to implement lots
of MC, and fancy editing features as some sort of special purpose
scripting language with shell abilities.  So there would be the full
screen handling library, with bindable functions for editing and other
basic generic functions, with callbacks.

Then there would be a toy I'm calling toyboxes.  You pass it a script,
the script binds keystrokes to functions, perhaps binds some functions
to a menu, then calls the generic editor.  

An MC script could bind keys and menus as before, create two boxes on
the screen, send the output of "ls" to each box, and bind some
callbacks to other keys.  The library handles moving the file selector
up and down one of the two boxes, as well as scrolling the box
contents, switching between the boxes, etc.  The library passes stuff
back to the script when the user hits return on one of the lines.  The
script notices it was a directory, changes to that directory, then
sends another "ls" commands output to the box again.  Or notices it's a
file and opens the proper viewer.  Similar for the other standard MC
keystrokes, they get bound to a callback in the script, the script
does the MC stuff, the library handles the generic box and content
stuff.

Add a shell alias for "mc" to be "toyboxes mc" and you get an MC
replacement.  Or "toyboxes vi", "toyboxes nano", etc.

I once wrote a program to run any program as a separate process, read
commands from it's stdin, execute those commands, then send the result
back through stdout.  The results where implemented as a callback
system, though it was all just plain text.  It was up to the
external program to figure out what to do with the results.  I think
something similar might work here.  Then people can use the language of
their choice to implement stuff using the toyboxes library.  This keeps
the toybox binary small and simple, while allowing people to create full
blown MC / editor / whatever replacements.  People can still write toys
for toybox that use it internally.  I can reuse some of that code.

Almost finished my virtual worlds web site redo, and just got paid to
get back to the embedded contract (I make him pay in advance, coz he
has a hard time coming up with money).  So I might not have much time
to bang on it.  See what I can get done.

-- 
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/20120615/a1bf9f25/attachment-0001.sig>