Add the SledjChisl stuff.

8 files changed, 4640 insertions, 0 deletions

diff --git a/src/boxes/BOXES.txt b/src/boxes/BOXES.txt
new file mode 100644
index 0000000..745b7c9
--- /dev/null
+++ b/src/boxes/BOXES.txt
@@ -0,0 +1,1130 @@
+What's needed for MC like program.  Call the library toyboxes, and the MC clone toysoldier.  B-)
+
+Use ANSI for terminal control.
+UTF-8 support is welcome in toybox where it makes sense, here it makes sense.
+
+Command defining - key, name, script, context.
+    Internal commands for the scripts.
+        Which can depend on the context.
+    Context is important.  Gotta handle stuff like vi modes, MC browse / view / edit modes, less search popping into readline mode, etc.
+    Learnable keys ala GIMP.
+
+Split the screen up into boxes.
+    Each box is a context.
+    Current box should have it's box graphics drawn in a different colour to highlight it.
+    Tab/shift-Tab cycles through boxes.
+        Though the editor has it's own use for tab.  Ctrl-tab as an alias perhaps?
+    Horizontal / vertical splits, with some sort of size control.
+        Each box can be split h or v once, 
+        with a control of what proportion the current box has (initially half),
+        a minimum size set by the contents,
+        and initially a copy of the pointer to the function that supplies it's contents / deals with it's input / includes it's context.
+        Later it can have that pointer set to something else.
+        Any given box can be deleted, which deletes it's sub boxes, drops it's pointer, and merges it's area with the one it split from.
+    See if screen and tmux agree on keys to use for box control.
+        Though, as usual, it's definable, but screen/tmux can be the defaults.
+    Choose to make a box full screen.  With menu to select other boxes, or swap back to full set of boxes.
+        Can be without borders and such.
+
+    The borders can be the usual box graphics, +-| characters, or inverse spaces, in that order of priority.
+    Show bits of text on top and bottom borders (left and right sides of them).
+        MC includes a couple of tiny mouse controlled widgets.
+    Perhaps a scroll widget in left or right borders.  Emacs dired has that.
+
+    Single line 'boxes', across the entire terminal, or across each box.
+        Should be context sensitive.
+        Menu - a list of commands showing their names and keys, with sub menus.
+        Function keys - Any function keys with commands showing the command names and key.
+            Perhaps could just be a specialized menu.
+        Programmable status line.
+
+    Contents scrolling.
+        Virtual memory buffers.
+            If a file viewer, just mmap it.
+            Editor should be able to only load in bits of a large file, perhaps with a UNDO/REDO buffer.
+            If command output, can create a temp file and mmap it.
+
+    file viewer (less, man).
+    editor (vi, mcedit, nano).
+        Like e3, make generic editor, with pluggable command keys, that kick in depending on how it's called.
+            Uses a file list in a box to select files for opening.
+    Poor mans top and similar commands.
+        Top at least could make use of internal boxes, with the command list using a sortable list.
+    Put command output in boxes.  Each line can be selected and operated on.
+        Title bar across top, with click to sort style column names.
+        Each line is a single line 'box'.
+        ls.
+        ls with display options.
+        archive listing
+        find command result.
+            All these can show current directory with diving in and out, or tree and current directory in a sub box.
+            Also, allow an edit mode for editing the file attributes that are displayed, inline and full box if possible.
+    Shell console, with various text substitutions on input.
+        Can be a single line 'box' as well as an ordinary box.
+        Though the ordinary ones show their output in their box,
+        but the single line one should swap to a full screen, which can be a full screen box.
+
+A box has content.  Each content type is a context.  So we can have -
+    Plain scrollable text view.
+    Fancy text view (hex and so on).
+    Text edit.
+    Directory browse.
+    Script controlled.
+
+Popup widgets centered on box/boxes that they affect.
+    Labels, Text line (with optional history), check boxes, radio buttons, OK/Cancel/etc buttons, popup select list (useful for history to, can be just a menu specilization).
+    Widget sets, though try to keep things simple enough to not need them.
+    Notifications, with the addition of an abort button.
+    If a single widget in the popup, prompt in a single line "box" near the bottom (like nano).
+    Options.
+        Keep options down to a bare minimum.
+    Command params.
+        Fetch command params from internal toybox structures, map them to the appropriate widget.
+    F2 menu - list of commands to apply to file/s or current directory.
+        The list is selectable by file type.
+        Should use the same code as the menu box, and allow sub menus.
+    Context sensitive history lists for selecting stuff.
+        Could also be a widget inside the popup when needed.
+    Search / replace.
+    Delete / save confirmation.
+    Command progress meter.
+        Use xargs, and have it output something useful per 'argument' for the progress meter.
+            xargs has an option to print the command to stdout, and to ask for confirmation per command.
+            xargs can run multiple threads.
+
+Scripting, so we can make things fancy and tie it together.
+    Don't forget to make it 'scriptable' via internal C.
+    MC uses that for the F2 menu, user menu, and archive access.
+    We should use scripts to define most of the above.
+    I'd like to use Lua, but shell is likely a better choice.
+        Coz toybox will have a shell.
+        And MC scripts are mostly shell bits.
+    Should have an actual toyboxes command that you can feed toyboxes scripts into.
+        Might actually get away with using that to define most of MC, AND be the editor plugins.
+        See how far I get, but that's what I'll start with for testing.
+        I should reuse the old emu protocol for this.
+    Not gonna actually sort function names or key combos.
+        A linear search is good enough for keys, they only come in at human speeds.
+        People might want the scripts to run faster, but in toybox we strive for simplicity.
+        Well, maybe a binary search within each modules function block that is sorted by hand in the source code.
+        On the other hand, might be able to make use of the toybox command parsing infrastructure for script functions.
+            Leaving that as a problem for toybox itself.
+            But it's not reusable, it uses globals, and not sure if we can screw with those globals.
+
+NOTE - toybox is designed to only deal with one command per process.  So we can't call other toybox commands internally.
+        Or can we?  Toysh does it.
+
+Events
+    We need a time event.  Top has a resolution of hundredths of a second, though says that only tenths is officially supported.
+        Tenths makes sense for human speed UI.  Hundredths makes sense if you want video frame rates.  lol
+        Termios only allows tenths of seconds for read anyway.
+            Hmm, seems read() wants to wait for at least one byte, it's a between byte counter.  Doh!
+        Select() is likely less simple, poll() the same, and epoll() seems to be linux specific.  All allow more precise timeouts.
+        On the other hand, Rob is using poll() in netcat.
+
+Common bits / differences.
+    Initial toybox command arguments.
+        Ability to change those within the editor.
+    Files - passed as arguments, or can add / remove them from the running editor.
+        Process the file through some proggy, or just some function of the editor script.
+        Save / save as / backups.
+        Modelines are actualy discouraged as a security issue by the standard, but encouraged by toybox to use vi modelines.
+        Filename completion.
+        Filename prompts could have a couple of features.
+            Can pass things in and out of a shell command, append to the file, edit a specific fixed section of a file or special file (disk block editing!), or use stdin and stdout (joe in a pipe).
+    Directory / file browsing in a window.
+    Windows per current design.
+        Multiple files in the command line each have their own window.
+        Different / same file in each.
+        Each has it's own cursor / marks / block, etc.
+        Delete / scroll some other window.
+        Open a file in some other window, possibly creating one first.
+        Show one window full screen.
+        Method to show some hidden window, can be hidden if there's not enough space for them all.
+    Buffers - holds the contents of the files being edited / viewed.
+        Attached to windows, but can shift them around?
+        Edit / view / read only, named / unnamed buffers.
+        Special purpose buffers.
+            Emacs has - scratch, help, grep, compile, gdb, man, shell, probably others.
+                Though most of those are just running some other command in a window.
+            Kill ring buffer.
+                Kill goes to the buffer, delete just vanishes, on the other hand, this is really the difference between "cut" and "delete".
+                "Yank" just means "paste from kill buffer" then.
+        Emacs can have different working directory for each buffer, OR one global directory.
+        List them, perform some operation on the members of the list.  Go through them all, prompting to save modified buffers.
+    Display text - navigate within it, scroll it in various ways.
+        Many ways to display otherwise unprintable text.
+            Inverted video for high bit characters.
+            Just show high bit characters.
+            UTF8.
+            ^X
+        Could be a problem with "where's my cursor" for the code.
+        Hex mode, wrap mode, raw / parsed mode, as well as formatted / unformatted mode.
+            Parsed mode has the text being processed by some command specified in the config file.
+            Formatted mode converts common formatting stuff to bold / underline.
+            Line numbers.
+        Scrolling can be definable amounts.
+        Some editors count buffer lines, some display lines.
+        Move to top, bottom, middle of screen / line.
+        Marks.
+            One mark and cursor.
+                Hmmm, Emacs uses the idea of a "point" which is between characters, with the "cursor" on the right side.
+                    Not sure if this will be a problem.
+                Emacs has only one mark, and everything between point and mark is the "region", a block I think.
+            Multiple marks - numbered, named, just arbitrary, automated marks for various reasons.  Line / line and character marks.
+            Next / previous / goto / remove one / all marks.
+        Whitespace / word boundaries / line / paragraph / "sections", etc.  Should be definable.
+            Vi has multiples types of all of them.  Pffft
+        Smooth scrolling (line by line).
+        Slow serial line support - do we need it?
+            Maybe.  B-(
+    Status line.
+        Show cursor position, details of file / character under cursor / working directory.  Often used for line input of parameters to.
+        Top of screen, bottom, above the key display in nano.  Can have left, middle, right widgets.
+        Nano has essentially two status lines.
+        Expert mode to turn it off, disable it for more screen space.
+    Regexs - basic / extra / extended
+        Replacable stuff in search & replace.  Ex/vi has this as an option.
+    Commands - invoked immediately with no echo, or typed via readline.
+        Pre command numbers (usually not echoed) / post command arguments.  Also pre command regexs and other things to select the lines to work on.
+        Methods of repeating commands.  Repeat last / next command, possibly X times.
+        Direction / motion.
+        Execute line / buffer / file.
+        Select lines, apply command to them.
+        Parameter expansion.
+    Key handling.
+        Bind / learn keys.
+            Emacs has "keymaps" for major and minor modes, as well as a global one.
+            Unbind keys.  Mask keys from a lower level, but without actually binding them to anything, a NOP.
+        Command keys can be one or more keys.
+            Emacs and wordstar generally use a control key followed by some other key.
+        Show help page in a window with key bindings.  Show binding for specific key.
+        Shortcut keys display.  Nano has two lines of 6 each, showing only the most common.  MC has one line, showing 10 function keys.  No one else cares?
+        Esc key same as Alt / Meta key OR used for function keys OR used by itself.  sigh
+        Meta key used to insert high bit characters.
+        Abort current command key.
+        Emacs has a keymap per buffer, which is the keybindings.
+            A global keymap.
+            The buffers major mode keymap.
+            Minor modes can have keymaps that override the major mode keymap when the minor mode is turned on.
+        Del <-> BS swapping.
+    Readline type widget.  Called "minibuffer" in emacs.
+        For command parameters, also just go to one at the bottom to type commands into.
+        A fullscreen editor could be considered to just be a stack of these.
+        History, completion, editing, escape from.  Position and length.
+            Same editing keys, and treat it just like a one line window.
+            Restricted or different editing keys while in some random line editing mode.
+        Moving readline to some other line (the basis of full screen editing perhaps).
+        Perhaps allow it to autoexpand if the input covers multiple lines.
+            Though that might be better to do as just creating more lines, then moving the readline between them.
+            Still would need the prompt on the top one, and to know to send them all at once when done.
+            How exactly does one create multiple lines?
+                Only way that makes sense is if the ENTER key is different from the "now do this" key.
+                Or wrapping long lines instead of scrolling them.
+        The prompt could include the default in ().
+    Mouse support - left click, double click, scroll wheel.
+        Only used to click on a widget, move cursor, or scroll around.
+        Shift click is used for X cut and paste support, think that just works from the terminal.
+    Shell - In a window / full screen.
+        Make editor a background task with bg / fg standard shell stuff.
+        Pass a block or buffer as stdin.  Append / insert stdout to the buffer.
+        The shell output can just appended to the window contents as text that can be edited like every other window.  When the cursor is at the bottom of the shell windov, stuff typed in is the next shell command.
+    Simple editing.
+        Move cursor, insert, delete, overwrite.
+    Basic editing.
+        Modes.
+            Vi has a lot of them - command, insert, ex, and moooore.
+            Emacs has definable modes that are a different concept to vi.
+                There are "major" and "minor" modes per buffer.
+                Major modes is for file type specific editing like "editing C, latex, etc" or "Dired".
+                    Includes things like indenting, syntax highlighting, function boundaries (for ctags I guess), invoking the right compiler, keymaps, etc.
+                    Can include other specialisations, like a python shell, and dired.
+                Minor modes are extras you can add, they seem to be things like "autofill", "wrap", "overwrite", "line numbers", etc.
+            Insert / overwrite mode.
+            Automatic detection of file type (typically source files) to put editor into different modes.
+        Cut, copy, paste, delete - blocks, word / line /etc, to end / beginning line, others.
+            To / from other buffers, files, "clipfile", maybe even the clipboard/s (thought that's an X thing I think).
+        Blocks - cut, copy, move, write to file.
+            Unhighlight block.
+        Search / replace - regex / shell glob / straight text / whole words.  Case / charset sensitive.  Forward / backward.
+            Regexs - basic / extra / extended
+            File / all files / within selection.  Wrap around searching.
+            Incremental.  Interactive / all replace.  Inverted (find non matches).
+            Highlight / filter found.
+            Regex for the replace bit.   Replacable stuff in search & replace.  Ex/vi has this as an option.
+            Can search mixed hex and strings.
+            History, repeat, repeat in other direction.
+        Modified state.
+            Can be used by some commands to pester the user.
+            Ability to turn that state off.
+        Tabs / spaces / half tabs.  Setting tab size.
+    Advanced editing.
+        Insert a character that is otherwise hard to insert, like command keys.
+        Insert date/time.
+        Quick search for a character in current line / forward / back.
+        "Smart" home, home goes to actual beginning, or first non blank.
+        Replace lots of space horizontally / vertically with just one / zero spaces.
+        Insert empty line/s above / below.
+        End of line space removal.
+        Allow cursor beyond end of line.
+        Visible white space.
+        DOS / Mac line ending convert.  On the other hand, might just be good to do that transparently, remember on read, convert on save.
+        Change text encoding.
+        Add a newline at end of file if it's missing one.
+            Think we are doing that anyway, but an option to turn that off might be good.
+        Transpose, upper, lower, reverse case, capitalize words.
+        Adding a prefix / suffix string to selected lines.
+        Indent / outdent / line wrapping / centreing which can be auto / manual.  Left and right margins.
+        Column blocks.
+            Deleting might just replace the column block with spaces / tabs.
+        Macros.  Various ways of defining / invoking a macro.
+            Nested macros.
+        Auto expanding abbreviations.
+        Auto save after certain commands, or certain time.
+        Multi level undo / redo.  Also undo current line (revert it?).
+            Disable undo.
+            Ability to list the undo "records"?
+            Emacs undo boundaries?
+        Spell checker.
+        Pretty printer (likely via shell command like indent).
+        Email quote handling.
+        Count / highlight lines matching or not matching regexes.
+        Sort block.
+        Persistant cursor position and selection.
+        Complete the word being typed based on other words in the file.
+    Code editing.
+        Ctags - basically lookup a symbol (word cursor is on) in the ctags files, which gives you a position in some other file that defines this symbol.  Then display this other file somehow, probably allowing editing.
+            Ctags is in the standards, but do we want to write a toybox version?
+        Bracket / character matching.  Goto / highlight matching bracket.  Auto insert the closing one.
+            Include "insert one, blink the other".
+            Auto detect code block for indenting?
+        Syntax highlighting.
+        Next / previous error (compile errors usually).
+
+Readline.
+    toybox has get_line() and get_rawline(), but they are not interactive readlines.
+    In order to have our readline() be useful for generic use, the keystrokes that do stuff must be definable.
+    So, what do we need?
+    GNU readline has (leaving out a few things) -
+        Editing
+            How is a "word" defined?.
+            Hitting ENTER anywhere in the line submits it.  An editor would want to actually insert the ENTER into the text.
+            Move cursor / insert / delete / backspace / undo (all the way back) / revert.
+                Perhaps redo might be nice.
+            Move cursor to start / end of line, forward / back one word, redraw.
+            Cut / copy / paste.  Kill ring with ring rotation?
+                Entire line.
+                All spaces around cursor.
+                From cursor to mark.
+                Highlighted block.
+                From cursor to start / end of line.
+                    to end of word, or end of next word if between words.
+                    to beginning of word, or of the previous word if between words.
+                    to previous white space.  Different from above coz apparently white space is different from word boundaries.  shrugs
+            Numbers in front of commands.  Vi and emacs probably need this?  More and less "needs" this.  Otherwise... eww.
+                For repeats, or sometimes to reverse the direction if it's negative.
+            Insert / overwrite mode.
+            Upper and lower casing characters or words.
+            Transpose characters / words.
+            Marks - setting a mark and moving the cursor to it / swapping with it.
+            Character search within the string - forward / back.
+            Insert comment - bloat we don't need.
+        History.
+            Back / forward one line.  Goto start / end of history.
+            Incremental and non incremental searching, forwards or back.
+                During incremental search - ability to abort and restore original line.
+            Remember the last (incremental?) search.
+            Either return the found history (ENTER), or allow editing (editing keys).
+            Option to save edited history lines, and mark them as edited.
+        Show key bindings / macros / etc.
+        Tab completion.
+            List / select completions.
+            Cycle through the matches.
+        Macros!
+        Config files.
+            Not likely to emulate these, we have our own needs, and it's not a standard.
+        Expansions.
+            MC will want argument expansions at least.
+            Though perhaps this is best left to the code that calls this to expand the result.
+
+more
+    Can handle switch between multiple files.
+    Searches are regexs.  Can also search for non matches.
+    Multiple marks.
+    Forward and back half screenful, with "half" being the specified number, but defaulting to actual half.
+    Shell commands (not in the standard).
+    Invoke the editor mentioned in EDITOR, or default to vi.  Pass line number if it's vi.
+    Print info about file.
+    Ctags.
+    Some commands are single letters, some are ":" followed by a single letter, possible with more text, then ENTER.
+        Or other variations.
+
+less
+    Has bracket matching, but only from top-open / bottom-close.
+    Can search between multiple files, or add more.
+        Files on the command line, add / remove files, just open a new file now.
+    Highlight found text.
+    Filter found lines.
+    Option to NOT do regex search.
+    Change the command line arguments while running.
+    Shell commands with replacable params.
+    Input processor - some proggy that the input file is processed through, the output of that is shown.
+        Um, why not use pipes and input redirection?
+
+ed - obsolete for toybox, ancestor of ex.
+    A line editor.
+    In command mode, type the command, then ENTER.
+    In input mode, type text, with "." on a line by itself to go back to command mode.
+    Uses one or two optional line addresses (can be regex) followed by a single character command, then arguments.
+    The "address" can be various symbols with various meanings, see the manual.
+    Usual basic editing and navigation commands.
+    Join lines.
+    Mark lines.
+    Display lines (with line numbers).
+    Copy / move lines.
+    Apply a command to a bunch of lines matching / not matching the address.
+    Insert a file / write lines to a file.
+    Search and replace.
+    Undo.
+    Shell command, with filename replacement character.
+
+sed
+    Stream editor.
+    Fairly similar to ed, except it applies a script of commands to each line in turn.
+    Branch to a label within the script.  Can test if a substitution happened before deciding to branch.
+    Includes a "hold space" for cut and paste type operations, as well as swapping.
+    Can output line numbers.
+    Can read in a file, or write to one.
+    Can be commented.
+
+ex - obsolete for toybox, but part of vi.
+    A line editor, apparently the line oriented editing mode for vi.
+        So while the command itself is obsolete, it's internal stuff might be needed for vi.
+        In fact a lot of the standard for vi just refers to ex.
+        ":" means to perform an ex command from vi.  lol
+    Starts in command mode (":" prompt).
+    Basically a "type command then ENTER" command mode.
+    Text input mode (append, insert, change) ended by "." on it's own line.
+    Has line addresses before the commands, similar to ed.
+    Commands have complex parsing requirements.  Ewww.
+    Has some really basic command line editing.
+    Has a bunch of buffers, with modes.  Commands apply to a named buffer, or the unnamed one if no name is given.
+    Abbreviations and maps.  Same thing?  They interact.  lol
+        Think the difference is that maps don't have to have blank space after them.
+        They expand during typing.
+        Seems that maps are for binding to keys?
+    Set various options.
+    Shell command, with optional interaction.
+    Read commands from a file.
+    Can scan ctags files looking for regexs.
+    Can switch to "open" and "visual" modes, whatever they are.
+        "Visual" mode is just vi.
+        "Open" mode I think is a vi for dumb terminals?
+    Has a concept of "window", also not sure what that is.  Might just be the number of terminal lines.
+    Shell escape - pass selected lines to a shell command, replace them with whatever it returns.
+    Shift lines back and forth.  Indent and outdent in other words.
+    Execute a buffer as ex commands.
+    Regexs have extra thingies.
+    Replace commands can refer to other bits of text using parameters.  See the manual.
+    Autowrite - basicaly save the file after certain commands.
+    Mode that strips out non printables on file read.
+    Can be made ed compatible. lol
+    Can display line numbers.
+    Paragraph boundary pairs can be set.
+    Definable scroll distance.
+    Visual and open modes have "sections", with definable pairs of boundary characters.
+    Can show matching braces.
+    Can optionally warn on some commands if the buffers are modified.
+    Margin auto wrap and end of line blanks removal.
+    Can wrap searches.
+    "modelines" (as used at the top of toybox source files) are apparently is strongly discouraged by the standard.  shrugs
+    Overlaping copies are allowed.
+    Automatic marks created sometimes.
+
+vi
+    Notable for it's variety of modes, and it's standard command mode that uses non echoed ordinary keys for common commands.
+    "Visual" editor, a screen oriented superset of ex, that lets you use ex commands.
+    A lot of the standard simply refers to ex.
+    Seems to mostly be similar to ex commands, only done full screen, and with full screen navigation.
+    Has "open" and "visual" modes, but not sure what they are.  Also "ex" mode, with means using ex commands.
+        I think "open" mode is for dumb terminals, it's all done on the bottom line, perhaps with full screen redraws.
+        "Visual" mode then must be full screen editing.
+    Text input mode can return to command mode with Esc.
+    Has five kinds of "words" and four kinds of "bigwords", six types of "sections", four types of "paragraphs", and three types of "sentences".
+    There can be a multi digit count before commands, it's not echoed anywhere when not in a command line mode, the command key then does its command count times.
+        For instance typing "12h" does not echo anything, but just moves the cursor back 12 places when the "h" is hit.
+        Lots of those seem to be letters, or control keys, though there are others.
+    [count] ! motion shell-commands <newline> run a shell command, replacing count lines with the output.  Looks like you get to type and edit the command while you see it.
+    Move to matching brace.
+    Repeat last command, for specific commands.
+    Move to last context, where I think "context" means where we was before the last command, it gets a special mark.
+    Move to words, bigwords, sections, paragraphs, etc.
+    Reverse case.
+    Find character in current line.  Move cursor to before / after specific character.
+    Move to top / middle / bottom of screen.
+    Insert empty line above / below.
+    Paste above / below, depending on if the buffer is line or character mode as well.
+    Replace count characters with the entered character.
+    Undo current line.
+    Some editing command keys while in text input mode.
+
+nano
+    Has a file browser mode.
+    Has a title bar, with three areas for showing status type info.
+    And a status line, which shows messages and lets users type stuff like file names.
+    Optional shortcut lists show 12 of the most common keystrokes in the current mode, and can be mouse clickable.
+    Mouse moves the cursor, double click sets marks.
+    "Smart" home - the usual go to first non blank, or go to actual start of line.
+    Tabs to spaces.
+    Multiple file buffers.
+    Search and replace history.
+    Deal with DOS / Mac line endings sanely.
+    Restricted mode.
+    Smooth scrolling.
+    Setting tab size.
+    Syntax highlighting.
+    Display cursor position.
+    Backspace and delete fixes, coz that's always confusing.
+    Autoindent.
+    Optional line wrap.
+    "Soft wrapping", no idea what that is.
+    External spell checker.
+    Undo and redo.
+    Hard to use method to insert otherwise unusable characters.
+    Optional search case sensitivity.
+    Optional regex searches.
+    Email quote handling.
+    Source code bracket handling of some sort.
+    Turning command line options on and off within the editor.
+    Write selected text to a file.
+
+microemacs (microGNUemacs  lol)
+    Go to line number.
+    Scratch buffer, help buffer, grep buffer, compile buffer.
+    Named buffers - per file.  Can have their own working directory, or a global one for all.
+    Kill a named buffer, prompting if it's changed.
+    List buffers.
+    Has the concept of "modes", default ones are - fill (wrap), indent, overwrite, and notab.
+        Can set a list of (minor?) modes as default for buffer creation.
+    Run a script (commands from a file).
+    Split windows.  B-)
+    Window / buffer specific cursor and mark (depending on which emacs you have).
+        Can swap them.
+    Esc key same as Alt-key.
+    Get help, describe binding, describe key briefly (hit a key, it's binding is displayed).
+    Apropros - prompt the user for a string, open help buffer, list all commands with that string.
+    Auto execute - a shell glob pattern that is matched on files read into buffers, then executes a command.
+    Recenter - position cursor in center of screen / center of line / center of line counted from the bottom.
+    Open line - open up some space by inserting empty lines below cursor, leaving cursor at the top of them.
+    Quoted insert - insert the next key verbatim, ignoring what it's bound to.
+    Universal argument - repeat the next command 4 times, can apply to itself.
+    Toggle read only.
+    Find file read only.
+    Find alternate file - loading a different file into the current buffer, erasing the original buffer contents.
+    Find file in buffer, or load it into new buffer, then switch to it.
+    Find file other window - opens file in new buffer, splitting the window if needed.
+    Delete window.
+    Delete other windows.
+    Split window.
+    Enlarge / shrink window.
+    Next / previous window.
+    Scroll other window - scrolls the next window X pages.
+    Switch to buffer other window - "switch to buffer in another window"?
+    Switch to buffer - ask which buffer should be in this window.
+    Switch to a shell screen, and back again.
+    What cursor position - show a bunch of info about cursor position and what's there.
+    Next / previous error.
+    Dired - basically a multi window MC.  lol
+    Save some buffers - looks for buffers that need saving and prompts user.
+    Just one space - delete all white space around cursor, then insert one single space.
+    Query replace - an interactive search and replace.  Also a replace all with no interaction.
+        Oh nice - can do a search and replace with a regex for both the search string, AND for the replacable strings (selecting which ones get replaced with that regex).
+    Beginning / end of buffer.
+    Capitalize / upper / lower word.
+    Delete word.
+    Delete blank lines.
+    Delete horizontal / vertical space.
+    Delete leading / trailing space.
+    Delete lines non / matching regex after cursor.
+    Hmm, difference between "kill" and "delete"?
+        "Kill" goes into the kill buffer, "delete" just vanishes.
+        "Yank" inserts things from the kill buffer.
+        Kill buffer is a ring buffer in full emacs, but might not be a ring in microemacs.
+        So it's just an old fashioned concept for "cut and paste".
+    Fill paragraph - just means to wrap and justify it.  Command to ask the user what the wrap column is.
+    Copy region as kill.
+    Execute extended command - does the readline thing to ask user for a command and arguments to run.
+    Execute one buffer / line.
+    Not modified - turn off the modified flag in current buffer.
+    Blink and insert - insert a character, then search backwards for it's match (bracket, or the character itself) and blink that.
+    Mini buffer - it's just a readline for command arguments and such, but treated as a one line window, with an uneditable prompt.
+        It does have the trick of expanding to more lines if it's content goes over multiple lines.
+        The prompt can include a default argument in ().
+    Numbers can proceed commands, seems to be what the universal argument is for.
+        Looks like they have a key to introduce them, then get put into the mini buffer.
+        "Digit-argument" and "negative-argument" might be the functions for that.
+    Swap Del and BS.
+    C program "mode" - no idea what that involves.
+    Count regex non / matches.
+    Define key (includes a keymap, what ever they are).  Can also undefine a key, and there's a "global" keymap.  Can also bind keys in specific modes.
+    Meta key can insert 8 bit characters, or not.
+    Keyboard quit - abort current action.
+    Insert spaces instead of tabs.
+    Toggle overwrite / insert mode.
+    Add a prefix string to lines in a selected region.  Or set that string.
+    Show working directory in the status line.
+    Refresh screen, including recomputing window sizes if needed.
+    Scroll window without changing cursor position within window.
+    Toggle read only.
+    Undo boundaries?
+    Undo on/off.
+    List undo records for current buffer, in a new buffer.
+
+wordstar (joe, turbo C) - Using joe, which also comes in emacs and pico flavours.
+    Help window, with commands to page through that help text.
+    Something about "inverting" 8 bit characters, but we want to be 8 bit clean.  Not a WordStar thing I think.  shrugs
+        Ah, for displaying high bit characters in other languages, normally inverts the display, but "as is" mode just prints them normally.
+    Option to auto append a new line at end of files on save.
+    Option to disable the status line.
+    Windowed & buffered like emacs, but for when it's pretending to be emacs.
+        Can be windowed anyway.
+        Split window on same file.
+        Make one window full screen.
+        Can move to hidden windows (hidden when there's not enough space for them all).
+        Horizontal split only.
+        Height change.
+        Multiple files on the command line go to multiple windows.
+    Option to define how many lines are kept on screen between page up / down commands.
+    Option to not use X lines at the top, for embedding in a BBS.
+    Multi level undo and redo.
+    Scrolling.
+    Automatic detection of source code files, other types get word wraping and autoindent by default.
+        Can set left and right margins for word wrapping.
+        Can center between them to.
+        Can manually indent lines, highlighted blocks, or autodetected code blocks.
+    Command to insert a single space while in overwrite mode.
+        Overwrite mode makes backspace just move left, no deleting.
+    File name completion.
+    History.  History is described as a single line read only edit window, just like other windows, so the usual commands will work in them.
+    Status line can be edited in the setup string, to add or remove escape sequences that include various things.
+        Also a command to show the cursor position and character code in the status line.
+    Suspend the proggy and go to shell.  Actually, I think most editors have this in some form or another.
+        Most seem to use the shell foreground/background thingy for this.
+    Search prompts for the thing to search, then prompts for a bunch of character flags that are search options.
+        One of the options is if this is a replace command, then it prompts for the replacement text.
+        It's regexs are slash escaped.
+    Highlighted block can be sent through a shell filter command.
+    Highlighted block can be un highlighted.
+    Macros keyed by digit, and can be nested.
+    Repeat command, hit the repeat, type the numbers, hit the command you want repeated.
+        Also works with characters.
+    Column select mode.
+        Delete block command replaces the entire column with spaces and tabs instead of deleting.
+    Ctags support, prompt for symbol (default is word the cursor is on), search ctags files, replace the file in the current window with the file ctags points to, and the cursor position of the symbol definition.
+    Shell in a window.
+        Very intersening, the shell output is just appended to the window contents as text that can be edited like every other window.  When the cursor is at the bottom of the shell windov, stuff typed in is the next shell command.
+    Filename prompts have a couple of features.  Can pass things in and out of a shell command, append to the file, edit a specific fixed section of a file or special file (disk block editing!), or use stdin and stdout (joe in a pipe).
+    Keys can be bound in the settings file.
+
+mc viewer
+    Hex mode.
+    Can search mixed hex and strings.
+    Wrap mode.
+    Raw / parsed mode toggle, as well as formatted / unformatted mode toggle.
+        Parsed mode has the text being processed by some command specified in the config file.
+        Formatted mode converts common formatting stuff to bold / underline.
+
+mcedit / cool edit
+    User menu - run a script, insert result.
+    Mark columns.
+    Bookmarks, toggle, next, previous, "flush" (meaning to remove all bookmarks.)
+    Copy / cut insert clipfile as well as prompting for a file.
+    Highlight all lines with found text.
+    Search for hexidecimal, within selection, for whole words, and in "all charsets".
+    Goto matching bracket.
+    Show line numbers.
+    Find "declaration", back from and forward to declaration.
+        It's ctags support.
+    Change text encoding.
+    Create, invoke, and delete macros (hotkeys).
+    Spell check.
+    Email current file.
+    Sort selected lines.
+    Insert output of shell command.
+    Format (wrap) paragraph.
+    Run external format script on selection.
+    Insert date/time.
+    Half tabs.
+    Persistant cursor position and selection.
+    Visible white space.
+    Optional go beyond end of line.
+    Learn keys.
+    Syntax highlighting.
+    Edit syntax and menu files.
+
+Make the fancy features optional in the "wrap if(constant) around things so the compiler can optimise it out" way that Rob likes.
+    So the basic compile choices are -
+        File / stdout viewer.
+        Editor (the following options might depend on how the "pluggable" part is done).
+            Minimal vi?
+            Nice to have vi?
+            Minimal emacs?
+            Nice to have emacs?
+            Nano?
+            Minimal mcedit/cooledit?
+            Nice to have mcedit/cooledit?
+        Lists.
+        Simple top like.
+        Fancy top like.
+        Simple shell.
+        Fancy shell.
+        Basic MC.
+        Full on MC with all bells and whistles.
+    With the fancy compile options being (only if they are substantial amounts of code to support) -
+        Full popups or mere single line prompts?
+        One pane, or multiple panes?
+        Function key single line 'box'?
+        Menu?
+        Status line?
+        Border texts?
+        Border widgets?
+        Sortable lists?
+        History lists?
+        Progress bar?
+        Shell text substitutions?
+        Scriptable?
+        Learnable keys?
+
+Probably got most of what we need to do screen / tmux / multitail, and other full screen terminal stuffs.
+
+Are we ncurses yet?  Or twin?  lol
+
+------------------------------------------------------------------------------------------------------
+
+NOTES
+
+From Rob -
+----------
+
+On 06/21/2012 09:28 AM, David Seikel wrote:
+> What are the chances that get_optflags() could be made re usable by
+> toys?  
+
+Well, right now you can put a NULL as your optstring and then set
+which->options yourself and call get_optflags().
+
+> For toys that need to make their own little scripting system for
+> example.  Currently it seems to want to use the toys global, and I'm
+> not sure if it's safe to screw with that after pulling all of my toys
+> options out of it.
+> 
+> Would it get reused like that for shell internal commands?  
+
+Already does. In toys/toysh.c function run_pipeline() look for the
+TOYFLAG_NOFORK bit.
+
+This probably needs to be genericized somewhere in lib, but I never got
+around to it.
+
+From Rob -
+----------
+
+I need to write a getline() with cursor control, which means I need to
+query the tty size. The magic for that is:
+
+struct winsize tty = { 0, 0, 0, 0 };
+int ret = ioctl(1, TIOCGWINSZ, &tty);
+
+plus $COLUMNS and $LINES, plus echo -e "\e[s\e[999C\e[999B\e[6n\e[u"
+
+Add command history parsing to getline().
+
+From Rob -
+----------
+
+Digging up ancient issues from toybox development, one of which is an
+interesting design issue with querying the terminal size.
+
+When you're on a serial console (happens a lot in the embedded world),
+the local tty device doesn't know the width and height of the window at
+the far end, so ioctl(TIOCGWINSZ) can't report it to you.
+
+If the term program at the other end supports ansi escape sequences
+(everything does, including xterms), there's an escape sequence you can
+use to ask it, but there's multiple levels of non-obvious to the
+implementation.
+
+The escape sequence itself is "\e[6n", to which the terminal program
+responds with another escape sequence, "\e[YY;XXR" where the "XX" part
+is a decimal number with the current cursor's Y location, and XX is the
+cursor X location. (Both decimal, top left is 1;1.)
+
+Since what we want is the size of the screen, we wrap that in some more
+commands, saving the current position, moving to the cursor 999 down and
+999 to the right (which should stick it at the lower right corner),
+query that position, and the jump back to the saved location. The full
+escape sequence is therefore "\e[s\e[999C\e[999B\e[6n\e[u".
+
+The problem is, the response comes back from the terminal program on
+stdin: along with whatever else is coming in on stdin. There could be a
+delay of a significant fraction of a second (especially through a rial
+port, even when you aren't overcommitted and swapping), and there's no
+guarantee the terminal will actually respond. So blocking and waiting
+for a response isn't the greatest idea, and can eat other input the user
+has queued up.
+
+This means you need to do a nonblocking read, assemble an ansi sequence
+a piece at a time (luckily the term programs generate these atomically
+so you don't get part of an ansi sequence with user-typed keys in the
+middle of it), and keep any other data you get for use later. The
+logical place to do this is in the line editing code the shell has to
+have anyway, which responds to cursor keys, page up and down, and so on.
+
+From Rob -
+----------
+
+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.
+
+From Rob -
+----------
+
+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...)
+
+From Rob -
+----------
+
+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"...
+
+
+From Rob -
+----------
+
+Keep in mind that Unix doesn't implement backspace sanely (like the
+commodore 64 did), thus you have to figure out when you're at the left
+edge of the screen (keeping track of your cursor position)
+
+That's why if you do "echo -n this will screw bash up" and then cursor
+up a few times bash's command history gets all wonky because it _thinks_
+it knows where the cursor is but actually started farther to the right. 
+(I contributed ansi escape screen position querying code to busybox to 
+improve the situation for ash.)
+
+From Rob -
+----------
+
+The question here is how much of this we already need to do for shell
+history, which is what I was going to implement first. (Actually the one
+I've already sat down and wrestled with is "more", which turns out to
+have rather a lot of these issues as well. Knowing what printable
+characters actually _print_ so you know where your darn cursor is and
+where the screen wraps. You'd think less would have more issues here,
+but more actually hits just about all of 'em...)
+
+Moving the cursor isn't the issue. Querying the screen size is a
+reasonably contained issue. Knowing how the cursor will move when you
+print out an arbitrary string: that's the hard part. (utf8 awareness is
+kinda required here. And I'm assuming a monospaced font even in klingon.
+And replacing the !isprint() characters below space with escape
+sequences...)
+
+
+From Rob and others -
+---------------------
+
+http://lists.busybox.net/pipermail/busybox/2008-October/067348.html
+
+http://lists.busybox.net/pipermail/busybox/2009-May/069314.html
+
+From Rob -
+----------
+
+Implementing ascii programming in the library itself was what I was
+referring to.  (It's on my todo list...)  All sorts of stuff needs it:
+more, toysh, vi...  Even ls wants to know the width of the screen for -C
+mode.
+
+The problem is parsing the replies, since the user could type arbitrary
+stuff.  It's stdout that needs to be a tty (because "ls | blah" is not
+going to a tty even if stdin is a tty), but the input _could_ come back
+in on stdin if that's another filehandle to the same tty... as could any
+other random input.  If you're filtering all your input through a line
+reading function that needs to parse cursor keys to implement command
+history, doing this is easy. But if _all_ you care about is the probe
+response and you want to leave the rest of the input alone, it's kinda
+hard.
+
+What I might wind up doing is adding it to toysh and having that export
+COLUMNS and LINES environment variables. It wouldn't catch resizes in
+the middle of a command, but I think I'm ok with that...
+
+
+------------------------------------------------------------------------------------------------------
+
+/*
+key / mouse     -> command
+menu choice     -> command
+border click    -> command
+popup + args    -> command
+typed string    -> command
+script call     -> command
+script callback -> command
+C call          -> command
+
+Arguments - should use the same argument defining stuff as used by the toys.
+    Keys and menus have to have fixed arguments, and take the rest from their content.
+    Popup and typed get their arguments from what the user selected in the popup, or typed.
+    Popup is told what it's widgets are and how they map to arguments.
+    Popups eventually construct a command string.
+    Script call uses generic text to call the command and set it's arguments.
+    Script callback should be similar.
+    C calls can call the functions direct, or even just pass a string command.
+
+So every command call involves it's content, and can take default arguments from that content, to be overridden by arguments.
+Keys and menus just have arguments coded into their string on definition, though might mostly be argument less.
+Popups have a structure that defines their argument widgets, and how to turn them into command arguments.
+Popups need to be created from string commands to.
+Typed commands can just have their arguments as part of the typed string.
+Scripts and callbacks just send a string that is treated the same way as typed commands.
+C can do the same as scripts, but should be able to call things directly.
+
+Sending commands back to scripts, should use the same format as our commands.
+
+Would be nice to have parameter substitution to, but that would have to be per content.
+
+Use an event system.
+
+---------------------------------------------
+
+Events
+    keystroke / mouse click
+    menu item select
+    timer
+    draw all
+    scroll contents
+    box was redrawn?
+    box destroyed
+    leave box
+    enter box
+
+void doScript(struct content *content, char commandString, struct event *event, void *blob)
+
+Define a command
+    name, argsDefinitionString, pointer to C function - void myCommand(struct box *box, char *command, struct ToyboxArguments *args, struct event *event, void *blob)
+
+Define a key
+    keyName, commandString
+
+Define a menu item
+    menuTitle, commandString
+
+Define a border widget
+    borderPosition, borderType, textOrCommand
+
+Define a popup
+    popupName, commandStub, thingThatMapsWidgetsToArgs
+
+Define a script callback
+    name, command, someKey
+
+---------------------------------------------
+
+Script interface.
+
+We might have multiple scripts running, but only one per box.
+    But what if a script wants to split it's box?
+They can't access our data structures, and we can't access theirs.
+All needs to be done via stdin/stdout plain text, which should all look like the commands in the rest of the system.
+
+Scripts can register simple callbacks on these events - key, menu, timer, box destroyed.
+The first three might want to return a damage list.
+The last means that the box wants to be destroyed, but the script gets a chance to clean up.
+
+Scripts need to be able to hook into the damage system, so there needs to be a text representation of damage areas.
+
+boxes  <->  script
+
+Boxes knows which script is attached to which box.
+Registering a key for the box is optional, and it's only passed back if it exists.
+A split box gets no key, or can have the key optionally sent with the split command.
+    So how does the script deal with stuff coming from multiple boxes?
+
+<-      keyForBox someKey
+<-      registerKey keyName, commandString   arguments
+<-      registerKey keyName, callBackCommand arguments
+user hits a key
+    if the key has a command, execute it.
+        if the command is not one of ours, send it to the script instead
+->      callBackCommand arguments, someKey
+        otherwise do our command
+    else
+        send the key event to the script.
+->      handleEvent keyName, someKey
+
+    In any case, the script might want to change things in response.
+    Note that it could do these at any time.
+<-      damage x, y, h, w
+        line
+        line
+        line
+        line
+->      doneRedraw someKey
+<-      border borderPosition, borderType, textOrCommand
+<-      status line
+
+ *
+ */
+
+
+struct function
+{
+    name                        // Name for script purposes.
+    description                 // Human name for the menus.
+    type
+    union
+    {
+        *scriptCallback
+        *cFunction
+    }
+};
+
+struct command
+{
+    key                         // Note that any given context might have different keys for any given function.
+    *function
+};
+
+struct item
+{
+    type
+    union
+    {
+        *command
+        *menu
+    }
+}
+
+struct menu
+{
+    *items[]                    // Circular pointer definiton for sub menus.
+}
+
+struct context                  // Somehow I get the feeling I'm having a failure of imagination here with the menus and function keys.  Might be better to manage them seperately per box, but have common ones available?  Nano might have a problem with this.
+{
+    *commands[]                 // The master list, the ones pointed to by the menu structs should be in this list.
+    menu *menu                  // Can be NULL.
+    menu *functionKeys          // Can be NULL.
+    // This can be used as the sub struct for various context types.  Like viewer, editor, file browser, top, etc.
+    // Could even be an object hierarchy, like generic editor, which Basic vi inherits from.
+};
+
+char borderchars[][]
+{
+    // usual box graphic symbols
+    '-|+',
+    // ANSI code for inverse spaces.
+}
+
+struct borderWidget
+{
+    text
+    *clickFunction(int position)
+}
+
+struct border
+{
+    *topLeftWidget
+    *topRightWidget
+    *bottomLeftWidget
+    *bottomRightWidget
+    *leftWidget
+    *rightWidget
+}
+
+struct damage
+{
+    X, Y, W, H                  // The rectangle to be redrawn.
+    char **lines                // Pointer to an array of text lines, or NULL.
+    *damage                     // Perhaps a linked list might be in order, for fast redraws.
+}
+
+struct content                  // For various instances of context types, in other words, the editor might have several files open, so one of these per file.
+{
+    minW, minH, maxW, maxH
+    *context
+    *handleEvents()             // Should set the damage list if it needs a redraw, and flags if border or status line needs updating.
+                                // Keyboard / mouse events if the box did not handle them itself.
+                                // DrawAll event for when drawing the box for the first time, on reveals for coming out of full screen, or user hit the redraw key.
+                                // Scroll event if the content wants to handle that itself.
+                                // Timer event for things like top that might want to have this called regularly.
+    *doneRedraw()               // The box is done with it's redraw, so we can free the damage list or whatever now.
+    *delete()
+    // This can be used as the sub struct for various content types.
+};
+
+struct contentData
+{
+    *border                     // Can be NULL.
+    *statusLine                 // Text of the status line, or NULL if none.
+    offsetX, offsetY, W, H      // Offset and size within the content, coz box handles scrolling, usually.
+    bool redrawStatus, redrawBorder
+    *damage                     // Can be NULL.  If not NULL after content->doneRedraw(), box will free it and it's children.
+    void *data                  // The content controls this blob, it's specific to each box.
+}
+
+struct box
+{
+    box *sub, *parent
+    bool noBorderOnFullScreen
+    bool horizontalSplit        // Marks if it's horizontally or vertically split.
+    splitProportion             // proportion of this boxes part of the split, the sub box gets the rest.
+    *content
+    contentData                 // Data blob specific to this box, passed to each content function.  For sharing contents, like a split pane editor for instance.  Not a pointer, but the struct.
+    X, Y, W, H                  // Position and size of the box itself, not the content.  Calculated, but cached coz that might be needed for speed.
+    cX, cY                      // Position of the content within the box.  Calculated, but cached coz that might be needed for speed.
+};
+
+box root;                       // Always a full screen, parent of the rest of the boxes, or the only box.
+box current;
+bool currentIsFullScreen;
diff --git a/src/boxes/BUGS.txt b/src/boxes/BUGS.txt
new file mode 100644
index 0000000..87c3d4b
--- /dev/null
+++ b/src/boxes/BUGS.txt
@@ -0,0 +1,6 @@
+xterm current box characters are wrong
+joe - ^K^D not working, but ^Kd is
+  Even odder, ^D works, all other ^K^? combinations work.
+F1 seems to not work, at least under xterm.
+
+should clear the command line prompt when not in use
diff --git a/src/boxes/README b/src/boxes/README
new file mode 100644
index 0000000..e01bb6b
--- /dev/null
+++ b/src/boxes/README
@@ -0,0 +1,34 @@
+boxes
+=====
+
+A test bed for a generic editor / pager thingy for the toybox project.
+
+The toybox project is at http://www.landley.net/code/toybox/ and boxes
+is covered by the same license that toybox is.  Basically that's a two
+clause BSD license, but see the LICENSE file from toybox for details.
+
+This is a work in progress, proof of concept, playground, packaged up as
+one big toy, to be self contained until the mess is cleaned up.  This
+"boxes" toy itself will go away, to be replaced by individual editor /
+pager toys and library bits.  Nothing is set in stone, lots of mess
+inside, there's bugs, but at least it shows the general direction my
+mind is wandering in.  As a bonus, it actually works, you can edit
+stuff.
+
+Please don't actually include this in toybox.  Just look at it and sneer
+/ giggle, depending on your nature.  Drop it into the toys directory to
+try it out, it's just one big toy.
+
+If you want to see how it can be used to build specific editors, start
+at the end and work backwards.  Reading the lengthy comments at the
+beginning would also be useful.
+
+Toybox uses mecurial instead of git, but I keep all my stuff on github. 
+Boxes will hopefully be incorporated into toybox in a highly altered
+form some day in the future.  So this is just a temporary git repo for
+my convenience.  If and when boxes migrates to toybox, this repo will be
+retired.
+
+
+BTW, toybox REQUIRES a README file here, a README.md file isn't good
+enough.
diff --git a/src/boxes/boxes.c b/src/boxes/boxes.c
new file mode 100644
index 0000000..4f542e1
--- /dev/null
+++ b/src/boxes/boxes.c
@@ -0,0 +1,2517 @@
+/* boxes.c - Generic editor development sandbox.
+ *
+ * Copyright 2012 David Seikel <won_fang@yahoo.com.au>
+ *
+ * Not in SUSv4.  An entirely new invention, thus no web site either.
+ * See -
+ * http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html
+ * http://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html
+ * http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
+ * http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
+ * http://linux.die.net/man/1/less
+
+USE_BOXES(NEWTOY(boxes, "w#h#m(mode):a(stickchars)1", TOYFLAG_USR|TOYFLAG_BIN))
+
+config BOXES
+  bool "boxes"
+  default y
+  help
+    usage: boxes [-m|--mode mode] [-a|--stickchars] [-w width] [-h height]
+
+    Generic text editor and pager.
+
+    Mode selects which editor or text viewr it emulates, the choices are -
+      emacs is a microemacs type editor.
+      joe is a joe / wordstar type editor.
+      less is a less type pager.
+      mcedit (the default) is cooledit / mcedit type editor.
+      more is a more type pager.
+      nano is a nano / pico type editor.
+      vi is a vi type editor.
+
+    Stick chars means to use ASCII for the boxes instead of "graphics" characters.
+*/
+
+#include "toys.h"
+#include "lib/handlekeys.h"
+
+GLOBALS(
+  char *mode;
+  long h, w;
+)
+
+#define TT this.boxes
+
+#define FLAG_a  2
+#define FLAG_m  4
+#define FLAG_h  8
+#define FLAG_w  16
+
+
+/* This is trying to be a generic text editing, text viewing, and terminal
+ * handling system.  The current code is a work in progress, and the design
+ * may change.  Certainly at this moment it's only partly written.  It is
+ * "usable" though, for a very small value of "usable".  In the following
+ * I'll use "editors" to refer to the toys using this, though not all will
+ * be editors.
+ *
+ * The things it is targeting are - vi and more (part of the standards, so
+ * part of the toybox TODO), less (also on the toybox TODO), joe and
+ * wordstar (coz Rob said they would be good to include), nano (again Rob
+ * thinks it would be good and I agree), microemacs (to avoid religous
+ * wars), and mcedit (coz that's what I actually use).  The ex editor comes
+ * along for the ride coz vi is basically a screen editor wrapper around
+ * the ex line editor.  Sed might be supported coz I'll need to do basic
+ * editing functions that are common to the editors, and sed needs the same
+ * editing functions.
+ *
+ * I will also use this for a midnight commander clone as discussed on the
+ * mailing list.  This would have things in common with emacs dired, so we
+ * might get that as well.  Parts of this code could also be used for a
+ * file chooser, as used by some of the editors we are targeting.  Finally,
+ * the terminal handling stuff might be useful for other toys, so should be
+ * generic in it's own right.  Oh, screen is listed in the toybox TODO as
+ * "maybe", so I'll poke at that to.
+ *
+ * The basic building blocks are box, content, context, edit line, and
+ * view.  A box is an on screen rectanglur area.  Content is a file, and
+ * the text that is in that file.  A context represents a particular editor
+ * type, it has key mappings and other similar stuff.  The edit line is a
+ * single line where editing happens, it's similar to readline.  A view is
+ * a view into a content, there can be many, it represents that portion of
+ * the content that is on screen right now.
+ *
+ * I plan on splitting these things up a bit so they can be used
+ * separately.  Then I can make actually toybox libraries out of them.  For
+ * now it's all one big file for ease of development.
+ *
+ * The screen is split into boxes, by default there are only two, the main
+ * text area and the command line at the bottom.  Each box contains a view,
+ * and each view points to a content (file) for it's text.  A content can
+ * have many views.  Each content has a context (editor).  There is only
+ * ever one edit line, it's the line that is being edited at the moment. 
+ * The edit line moves within and between boxes (including the command
+ * line) as needed.
+ *
+ * The justification for boxes is that most of the editors we are trying to
+ * emulate include some splitting up of the screen area for various
+ * reasons, and some of them include a split window system as well.  So
+ * this boxes concept covers command line, main editing area, split windows,
+ * menus, on screen display of command keys, file selection, and anything
+ * else that might be needed.
+ *
+ * To keep things simple boxes are organised as a binary tree of boxes. 
+ * There is a root box, it's a global.  Each box can have two sub boxes. 
+ * Only the leaf nodes of the box tree are visible on the screen.  Each box
+ * with sub boxes is split either horizontally or vertically.  Navigating
+ * through the boxes goes depth first.
+ *
+ * A content keeps track of a file and it's text.  Each content also has a
+ * context, which is a collection of the things that define a particular
+ * editor.  (I might move the context pointer from content to view, makes
+ * more sense I think.)
+ *
+ * A context is the heart of the generic part of the system.  Any given
+ * toybox command that uses this system would basically define a context
+ * and pass that to the rest of the system.  See the end of this file for a
+ * few examples.  A context holds a list of command to C function mappings,
+ * key to command mappings, and a list of modes.
+ *
+ * Most of the editors targetted include a command line where the user
+ * types in editor commands, and each of those editors has different
+ * commands.  They would mostly use the same editing C functions though, or
+ * short wrappers around them.  The vi context at the end of this file is a
+ * good example, it has a bunch of short C wrappers around some editing
+ * functions, or uses standard C editing functions directly.  So a context
+ * has an editor command to C function mapping.
+ *
+ * The editors respond to keystrokes, and those keystrokes invoke editor
+ * commands, often in a modal way.  So there are keystroke to editor
+ * command mappings.  To cater for editing modes, each context has a list
+ * of modes, and each mode can have key to command mappings, as well as
+ * menu to command mappings, and a list of displayed key/command pairs. 
+ * Menu and key/command pair display is not written yet.  Most editors have
+ * a system for remapping key to command mappings, that's not supported
+ * yet.  Emacs has a heirarchy of key to command mappings, that's not
+ * supported yet.  Some twiddling of the current design would be needed for
+ * those.
+ *
+ * The key mappings used can be multiple keystrokes in a sequence, the
+ * system caters for that.  Some can be multi byte like function keys, and
+ * even different strings of bytes depending on the terminal type.  To
+ * simplify this, there is a table that maps various terminals ideas of
+ * special keys to key names, and the mapping of keys to commands uses
+ * those key names.
+ *
+ * A view represents the on screen visible portion of a content within a
+ * box.  To cater for split window style editors, a content can have many
+ * views.  It deals with keeping track of what's shown on screen, mapping
+ * the on screen representation of the text to the stored text during input
+ * and output.  Each box holds one view.
+ *
+ * The edit line is basically a movable readline.  There are editing C
+ * functions for moving it up and down lines within a view, and for
+ * shifting the edit line to some other box.  So an editor would map the
+ * cursor keys for "up a line" and "down a line" to these C functions for
+ * example.  Actual readline style functionality is just the bottom command
+ * box being a single line view, with the history file loaded into it's
+ * content, and the Enter key mapped to the editor contexts "do this
+ * command" function.  Using most of the system with not much special casing.
+ *
+ *
+ * I assume that there wont be a terribly large number of boxes.
+ * Things like minimum box sizes, current maximum screen sizes, and the fact
+ * that they all have to be on the screen mean that this assumption should
+ * be safe.  It's likely that most of the time there will be only a few at
+ * most.  The point is there is a built in limit, there's only so many non
+ * overlapping boxes with textual contents that you can squeeze onto one
+ * terminal screen at once.
+ *
+ * I assume that there will only be one command line, no matter how many boxes,
+ * and that the command line is for the current box.
+ *
+ * I use a wide screen monitor and small font.
+ * My usual terminal is 104 x 380 characters.
+ * There will be people with bigger monitors and smaller fonts.
+ * So use sixteen bits for storing screen positions and the like.
+ * Eight bits wont cut it.
+ *
+ *
+ * These are the escape sequences we send -
+ *    \x1B[m            reset attributes and colours
+ *    \x1B[1m           turn on bold
+ *    \x1B[%d;%dH       move cursor
+ * Plus some experimentation with turning on mouse reporting that's not
+ * currently used.
+ *
+ *
+ * TODO - disentangle boxes from views.
+ *
+ * TODO - should split this up into editing, UI, and boxes parts,
+ * so the developer can leave out bits they are not using.
+ *
+ * TODO - Show status line instead of command line when it's not being edited.
+ *
+ * TODO - should review it all for UTF8 readiness.  Think I can pull that off
+ * by keeping everything on the output side as "screen position", and using
+ * the formatter to sort out the input to output mapping.
+ *
+ * TODO - see if there are any simple shortcuts to avoid recalculating
+ * everything all the time.  And to avoid screen redraws.
+ */
+
+/* Robs "It's too big" lament.
+
+> So when you give me code, assume I'm dumber than you. Because in this 
+> context, I am. I need bite sized pieces, each of which I can
+> understand in its entirety before moving on to the next.  
+
+As I mentioned in my last email to the Aboriginal linux list, I wrote
+the large blob so I could see how the ideas all work to do the generic
+editor stuff and other things.  It kinda needs to be that big to do
+anything that is actually useful.  So, onto musings about cutting it up
+into bite sized bits...
+
+You mentioned on the Aboriginal Linux list that you wanted a
+"readline", and you listed some features.  My reply was that you had
+basically listed the features of my "basic editor".  The main
+difference between "readline" and a full screen editor, is that the
+editor is fullscreen, while the "readline" is one line.  They both have
+to deal with a list of lines, going up and down through those lines,
+editing the contents of those lines, one line at a time.  For persistent
+line history, they both have to save and load those lines to a file.
+Other than that "readline" adds other behaviour, like moving the
+current line to the end when you hit return and presenting that line to
+the caller (here's the command).  So just making "readline" wont cut
+out much of the code.  In fact, my "readline" is really just a thin
+wrapper around the rest of the code.
+
+Starting from the other end of the size spectrum, I guess "find out
+terminal size" is a small enough bite sized chunk.  To actually do
+anything useful with that you would probably start to write stuff I've
+already written though.  Would be better off just using the stuff I've
+already written.  On the other hand, maybe that would be useful for
+"ls" listings and the like, then we can start with just that bit?
+
+I guess the smallest useful command I have in my huge blob of code
+would be "more".  I could even cut it down more.  Show a page of text,
+show the next page of text when you hit the space bar, quit when you
+hit "q".  Even then, I would estimate it would only cut out a third of
+the code.
+
+On the other hand, there's a bunch of crap in that blob that is for
+future plans, and is not doing anything now.
+
+In the end though, breaking it up into suitable bite sized bits might
+be almost as hard as writing it in the first place.  I'll see what I
+can do, when I find some time.  I did want to break it up into three
+bits anyway, and there's a TODO to untangle a couple of bits that are
+currently too tightly coupled.
+
+*/
+
+/* Robs contradiction
+
+On Thu, 27 Dec 2012 06:06:53 -0600 Rob Landley <rob@landley.net> wrote:
+
+> On 12/27/2012 12:56:07 AM, David Seikel wrote:  
+> > On Thu, 27 Dec 2012 00:37:46 -0600 Rob Landley <rob@landley.net>  
+> > wrote:  
+> > > Since ls isn't doiing any of that, probing would just be awkward
+> > > so toysh should set COLUMNS to a sane value. The problem is,
+> > > we're not using toysh yet because it's still just a stub...  
+> > 
+> > I got some or all of that terminal sizing stuff in my editor thingy
+> > already if I remember correctly.  I remember you wanted me to cut it
+> > down into tiny bits to start with, so you don't have to digest the  
+> > huge lump I sent.  
+> 
+> Basically what I'd like is a self-contained line reader. More or less
+> a getline variant that can handle cursoring left and right to insert  
+> stuff, handle backspace past a wordwrap (which on unix requires
+> knowing the screen width and your current cursor position), and one
+> that lets up/down escape sequences be hooked for less/more screen
+> scrolling, vi line movement, shell command history, and so on.  
+
+Which is most of an editor already, so how to break it up into bite
+sized morsels?
+
+> There's sort of three levels here, the first is "parse raw input,  
+> assembling escape sequences into cursor-left and similar as
+> necessary". (That's the one I had to redo in busybox vi because they
+> didn't do it right.)
+> 
+> The second is "edit a line of text, handling cursoring _within_ the  
+> line". That's the better/interactive getline().
+> 
+> The third is handling escapes from that line triggering behavior in
+> the larger command (cursor up and cursor down do different things in
+> less, in vi, and in shell command history).
+> 
+> The fiddly bit is that terminal_size() sort of has to integrate with  
+> all of these. Possibly I need to have width and height be members of  
+> struct toy_context. Or have the better_getline() take a pointer to a  
+> state structure it can update, containing that info...
+
+*/
+
+
+static char *borderChars[][6] =
+{
+  {"-",    "|",    "+",    "+",    "+",    "+"},     // "stick" characters.
+  {"\xE2\x94\x80", "\xE2\x94\x82", "\xE2\x94\x8C", "\xE2\x94\x90", "\xE2\x94\x94", "\xE2\x94\x98"},  // UTF-8
+  {"\x71", "\x78", "\x6C", "\x6B", "\x6D", "\x6A"},  // VT100 alternate character set.
+  {"\xC4", "\xB3", "\xDA", "\xBF", "\xC0", "\xD9"}   // DOS
+};
+
+static char *borderCharsCurrent[][6] =
+{
+  {"=",    "#",    "+",    "+",    "+",    "+"},     // "stick" characters.
+  {"\xE2\x95\x90", "\xE2\x95\x91", "\xE2\x95\x94", "\xE2\x95\x97", "\xE2\x95\x9A", "\xE2\x95\x9D"},  // UTF-8
+  {"\x71", "\x78", "\x6C", "\x6B", "\x6D", "\x6A"},  // VT100 alternate character set has none of these.  B-(
+  {"\xCD", "\xBA", "\xC9", "\xBB", "\xC8", "\xBC"}   // DOS
+};
+
+
+typedef struct _box box;
+typedef struct _view view;
+
+typedef void (*boxFunction) (box *box);
+typedef void (*eventHandler) (view *view);
+
+struct function
+{
+  char *name;           // Name for script purposes.
+  char *description;    // Human name for the menus.
+  char type;
+  union
+  {
+    eventHandler handler;
+    char *scriptCallback;
+  };
+};
+
+struct keyCommand
+{
+  char *key, *command;
+};
+
+struct item
+{
+  char *text;           // What's shown to humans.
+  struct key *key;      // Shortcut key while the menu is displayed.
+    // If there happens to be a key bound to the same command, the menu system should find that and show it to.
+  char type;
+  union
+  {
+    char *command;
+    struct item *items; // An array of next level menu items.
+  };
+};
+
+struct borderWidget
+{
+  char *text, *command;
+};
+
+// TODO - a generic "part of text", and what is used to define them.
+// For instance - word, line, paragraph, section.
+// Each context can have a collection of these.
+
+struct mode
+{
+  struct keyCommand *keys;      // An array of key to command mappings.
+  struct item *items;           // An array of top level menu items.
+  struct item *functionKeys;    // An array of single level "menus".  Used to show key commands.
+  uint8_t flags;                // commandMode.
+};
+
+/*
+Have a common menu up the top.
+  MC has a menu that changes per mode.
+  Nano has no menu.
+Have a common display of certain keys down the bottom.
+  MC is one row of F1 to F10, but changes for edit / view / file browse.  But those are contexts here.
+  Nano is 12 random Ctrl keys, possibly in two lines, that changes depending on the editor mode, like editing the prompt line for various reasons, help.
+*/
+struct context                  // Defines a context for content.  Text viewer, editor, file browser for instance.
+{
+  struct function *commands;    // The master list, the ones pointed to by the menus etc should be in this list.
+  struct mode *modes;           // A possible empty array of modes, indexed by the view.
+    // OR might be better to have these as a linked list, so that things like Emacs can have it's mode keymap hierarcy.
+  eventHandler handler;         // TODO - Might be better to put this in the modes.  I think vi will need that.
+    // Should set the damage list if it needs a redraw, and flags if border or status line needs updating.
+    // Keyboard / mouse events if the box did not handle them itself.
+    // DrawAll event for when drawing the box for the first time, on reveals for coming out of full screen, or user hit the redraw key.
+    // Scroll event if the content wants to handle that itself.
+    // Timer event for things like top that might want to have this called regularly.
+  boxFunction doneRedraw;       // The box is done with it's redraw, so we can free the damage list or whatever now.
+  boxFunction delete;
+    // This can be used as the sub struct for various context types.  Like viewer, editor, file browser, top, etc.
+    // Could even be an object hierarchy, like generic editor, which Basic vi inherits from.
+    //   Or not, since the commands might be different / more of them.
+};
+
+// TODO - might be better off just having a general purpose "widget" which includes details of where it gets attached.
+// Status lines can have them to.
+struct border
+{
+  struct borderWidget *topLeft, *topMiddle, *topRight;
+  struct borderWidget *bottomLeft, *bottomMiddle, *bottomRight;
+  struct borderWidget *left, *right;
+};
+
+struct line
+{
+  struct line *next, *prev;
+  uint32_t length;      // Careful, this is the length of the allocated memory for real lines, but the number of lines in the header node.
+  char *line;           // Should be blank for the header.
+};
+
+struct damage
+{
+  struct damage *next;  // A list for faster draws?
+  uint16_t X, Y, W, H;  // The rectangle to be redrawn.
+  uint16_t offset;      // Offest from the left for showing lines.
+  struct line *lines;   // Pointer to a list of text lines, or NULL.
+    // Note - likely a pointer into the middle of the line list in a content.
+};
+
+struct content          // For various instances of context types.  
+    // Editor / text viewer might have several files open, so one of these per file.
+    // MC might have several directories open, one of these per directory.  No idea why you might want to do this.  lol
+{
+  struct context *context;
+  char *name, *file, *path;
+  struct line lines;
+//  file type
+//  double linked list of bookmarks, pointer to line, character position, length (or ending position?), type, blob for types to keep context.
+  uint16_t minW, minH, maxW, maxH;
+  uint8_t flags;        // readOnly, modified.
+    // This can be used as the sub struct for various content types.
+};
+
+struct _view
+{
+  struct content *content;
+  box *box;
+  struct border *border;        // Can be NULL.
+  char *statusLine;             // Text of the status line, or NULL if none.
+  int mode;                     // For those contexts that can be modal.  Normally used to index the keys, menus, and key displays.
+  struct damage *damage;        // Can be NULL.  If not NULL after context->doneRedraw(), box will free it and it's children.
+    // TODO - Gotta be careful of overlapping views.
+  void *data;                   // The context controls this blob, it's specific to each box.
+  uint32_t offsetX, offsetY;    // Offset within the content, coz box handles scrolling, usually.
+  uint16_t X, Y, W, H;          // Position and size of the content area within the box.  Calculated, but cached coz that might be needed for speed.
+  uint16_t cX, cY;              // Cursor position within the content.
+  uint16_t iX, oW;              // Cursor position inside the lines input text, in case the formatter makes it different, and output length.
+  char *output;                 // The current line formatted for output.
+  uint8_t flags;                // redrawStatus, redrawBorder;
+
+  // Assumption is that each box has it's own editLine (likely the line being edited), or that there's a box that is just the editLine (emacs minibuffer, and command lines for other proggies).
+  struct line *line;            // Pointer to the current line, might be the only line.
+  char *prompt;                 // Optional prompt for the editLine.
+
+// Display mode / format hook.
+// view specific bookmarks, including highlighted block and it's type.
+// Linked list of selected lines for a filtered view, or processing only those lines.
+// Linked list of pointers to struct keyCommand, for emacs keymaps hierarchy, and anything similar in other editors.  Plus some way of dealing with emacs minor mode keymaps.
+};
+
+struct _box
+{
+  box *sub1, *sub2, *parent;
+  view *view;                   // This boxes view into it's content.  For sharing contents, like a split pane editor for instance, there might be more than one box with this content, but a different view.
+    // If it's just a parent box, it wont have this, so just make it a damn pointer, that's the simplest thing.  lol
+    // TODO - Are parent boxes getting a view anyway?
+  uint16_t X, Y, W, H;          // Position and size of the box itself, not the content.  Calculated, but cached coz that might be needed for speed.
+  float split;                  // Ratio of sub1's part of the split, the sub2 box gets the rest.
+  uint8_t flags;                // Various flags.
+};
+
+
+// Sometimes you just can't avoid circular definitions.
+void drawBox(box *box);
+
+
+#define BOX_HSPLIT  1   // Marks if it's a horizontally or vertically split.
+#define BOX_BORDER  2   // Mark if it has a border, often full screen boxes wont.
+
+static int overWriteMode;
+static box *rootBox;    // Parent of the rest of the boxes, or the only box.  Always a full screen.
+static box *currentBox;
+static view *commandLine;
+static int commandMode;
+
+#define MEM_SIZE  128   // Chunk size for line memory allocation.
+
+// Inserts the line after the given line, or at the end of content if no line.
+struct line *addLine(struct content *content, struct line *line, char *text, uint32_t length)
+{
+  struct line *result = NULL;
+  uint32_t len;
+
+  if (!length)
+    length = strlen(text);
+  // Round length up.
+  len = (((length + 1) / MEM_SIZE) + 1) * MEM_SIZE;
+  result = xzalloc(sizeof(struct line));
+  result->line = xzalloc(len);
+  result->length = len;
+  strncpy(result->line, text, length);
+
+  if (content)
+  {
+    if (!line)
+      line = content->lines.prev;
+
+    result->next = line->next;
+    result->prev = line;
+
+    line->next->prev = result;
+    line->next = result;
+
+    content->lines.length++;
+  }
+  else
+  {
+    result->next = result;
+    result->prev = result;
+  }
+
+  return result;
+}
+
+void freeLine(struct content *content, struct line *line)
+{
+  line->next->prev = line->prev;
+  line->prev->next = line->next;
+  if (content)
+    content->lines.length--;
+  free(line->line);
+  free(line);
+}
+
+void loadFile(struct content *content)
+{
+  int fd = open(content->path, O_RDONLY);
+
+  if (-1 != fd)
+  {
+    char *temp = NULL;
+    long len = 0;
+
+    do
+    {
+      // TODO - get_line() is slow, and wont help much with DOS and Mac line endings.
+      temp = get_line(fd);
+      if (temp)
+        addLine(content, NULL, temp, len);
+    } while (temp);
+    close(fd);
+  }
+}
+
+// TODO - load and save should be able to deal with pipes, and with loading only parts of files, to load more parts later.
+
+void saveFile(struct content *content)
+{
+// TODO - Should do "Save as" as well.  Which is just a matter of changing content->path before calling this.
+  int fd;
+
+  fd = open(content->path, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH);
+
+  if (-1 != fd)
+  {
+    struct line *line = content->lines.next;
+
+    while (&(content->lines) != line)  // We are at the end if we have wrapped to the beginning.
+    {
+      write(fd, line->line, strlen(line->line));
+      write(fd, "\n", 1);
+      line = line->next;
+    }
+    close(fd);
+  }
+  else
+  {
+    fprintf(stderr, "Can't open file %s\n", content->path);
+    exit(1);
+  }
+}
+
+struct content *addContent(char *name, struct context *context, char *filePath)
+{
+  struct content *result  = xzalloc(sizeof(struct content));
+
+  result->lines.next  = &(result->lines);
+  result->lines.prev  = &(result->lines);
+  result->name    = strdup(name);
+  result->context    = context;
+
+  if (filePath)
+  {
+    result->path = strdup(filePath);
+    loadFile(result);
+  }
+
+  return result;
+}
+
+// General purpose line moosher.  Used for appends, inserts, overwrites, and deletes.
+// TODO - should have the same semantics as mooshStrings, only it deals with whole lines in double linked lists.
+// We need content so we can adjust it's number of lines if needed.
+void mooshLines(struct content *content, struct line *result, struct line *moosh, uint16_t index, uint16_t length, int insert)
+{
+}
+
+// General purpose string moosher.  Used for appends, inserts, overwrites, and deletes.
+void mooshStrings(struct line *result, char *moosh, uint16_t index, uint16_t length, int insert)
+{
+  char *c, *pos;
+  int limit = strlen(result->line);
+  int mooshLen = 0, resultLen;
+
+  if (moosh)
+    mooshLen = strlen(moosh);
+
+  /*
+   * moosh  == NULL  a deletion
+   * length == 0    simple insertion
+   * length <  mooshlen  delete some, insert moosh
+   * length == mooshlen  exact overwrite.
+   * length >  mooshlen  delete a lot, insert moosh
+   */
+
+  mooshLen -= length;
+  resultLen = limit + mooshLen;
+
+  // If we need more space, allocate more.
+  if (resultLen > result->length)
+  {
+    result->length = resultLen + MEM_SIZE;
+    result->line = xrealloc(result->line, result->length);
+  }
+
+  if (limit <= index)  // At end, just add to end.
+  {
+    // TODO - Possibly add spaces to pad out to where index is?
+    //          Would be needed for "go beyond end of line" and "column blocks".
+    //          Both of those are advanced editing.
+    index = limit;
+    insert = 1;
+  }
+
+  pos = &(result->line[index]);
+
+  if (insert)  // Insert / delete before current character, so move it and the rest up / down mooshLen bytes.
+  {
+    if (0 < mooshLen)  // Gotta move things up.
+    {
+      c = &(result->line[limit]);
+      while (c >= pos)
+      {
+        *(c + mooshLen) = *c;
+        c--;
+      }
+    }
+    else if (0 > mooshLen)  // Gotta move things down.
+    {
+      c = pos;
+      while (*c)
+      {
+        *c = *(c - mooshLen);  // A double negative.
+        c++;
+      }
+    }
+  }
+
+  if (moosh)
+  {
+    c = moosh;
+    do
+    {
+      *pos++ = *c++;
+    }
+    while (*c);
+  }
+}
+
+// TODO - Should draw the current border in green, the text as default (or highlight / bright).
+//          Then allow one other box to be red bordered (MC / dired destination box).
+//          All other boxes with dark gray border, and dim text.
+void drawLine(int y, int start, int end, char *left, char *internal, char *contents, char *right, int current)
+{
+  int size = strlen(internal);
+  int len = (end - start) * size, x = 0;
+  char line[len + 1];
+
+  if ('\0' != left[0])  // Assumes that if one side has a border, then so does the other.
+    len -= 2 * size;
+
+  if (contents)
+  {
+    // strncpy wont add a null at the end if the source is longer, but will pad with nulls if source is shorter.
+    // So it's best to put a safety null in first.
+    line[len] = '\0';
+    strncpy(line, contents, len);
+    // Make sure the following while loop pads out line with the internal character.
+    x = strlen(line);
+  }
+  while (x < len)
+  {
+    strcpy(&line[x], internal);
+    x += size;
+  }
+  line[x++] = '\0';
+  if ('\0' == left[0])  // Assumes that if one side has a border, then so does the other.
+  {
+    if (current)
+      printf("\x1B[1m\x1B[%d;%dH%s\x1B[m", y + 1, start + 1, line);
+    else
+      printf("\x1B[m\x1B[%d;%dH%s", y + 1, start + 1, line);
+  }
+  else
+  {
+    if (current)
+      printf("\x1B[1m\x1B[%d;%dH%s%s%s\x1B[m", y + 1, start + 1, left, line, right);
+    else
+      printf("\x1B[m\x1B[%d;%dH%s%s%s", y + 1, start + 1, left, line, right);
+  }
+}
+
+void formatCheckCursor(view *view, long *cX, long *cY, char *input)
+{
+  int i = 0, o = 0, direction = (*cX) - view->cX;
+
+  // Adjust the cursor if needed, depending on the contents of the line, and the direction of travel.
+  while (input[i])
+  {
+    // When o is equal to the cX position, update the iX position to be where i is.
+    if ('\t' == input[i])
+    {
+      int j = 8 - (i % 8);
+
+      // Check if the cursor is in the middle of the tab.
+      if (((*cX) > o) && ((*cX) < (o + j)))
+      {
+        if (0 <= direction)
+        {
+          *cX = (o + j);
+          view->iX = i + 1;
+        }
+        else
+        {
+          *cX = o;
+          view->iX = i;
+        }
+      }
+      o += j;
+    }
+    else
+    {
+      if ((*cX) == o)
+        view->iX = i;
+      o++;
+    }
+    i++;
+  }
+  // One more check in case the cursor is at the end of the line.
+  if ((*cX) == o)
+    view->iX = i;
+}
+
+// TODO - Should convert control characters to reverse video, and deal with UTF8.
+
+/* FIXME - We get passed a NULL input, apparently when the file length is close to the screen length. -
+> On Thu, 6 Sep 2012 11:56:17 +0800 Roy Tam <roytam@gmail.com> wrote:
+>   
+> > 2012/9/6 David Seikel <onefang@gmail.com>:  
+> > >> Program received signal SIGSEGV, Segmentation fault.
+> > >> formatLine (view=0x8069168, input=0x0, output=0x806919c)
+> > >>     at toys/other/boxes.c:843
+> > >> 843        int len = strlen(input), i = 0, o = 0;
+> > >> (gdb) bt
+> > >> #0  formatLine (view=0x8069168, input=0x0, output=0x806919c)
+> > >>     at toys/other/boxes.c:843
+> > >> #1  0x0804f1dd in moveCursorAbsolute (view=0x8069168, cX=0,
+> > >> cY=10, sX=0, sY=0) at toys/other/boxes.c:951
+> > >> #2  0x0804f367 in moveCursorRelative (view=0x8069168, cX=0,
+> > >> cY=10, sX=0, sY=0) at toys/other/boxes.c:1011
+> > >> #3  0x0804f479 in upLine (view=0x8069168, event=0x0) at
+> > >> toys/other/boxes.c:1442 #4  0x0804fb63 in handleKey
+> > >> (view=0x8069168, i=2, keyName=<optimized out>, buffer=0xbffffad8
+> > >> "\033[A") at toys/other/boxes.c:1593 #5  0x0805008d in editLine
+> > >> (view=0x8069168, X=-1, Y=-1, W=-1, H=-1) at
+> > >> toys/other/boxes.c:1785 #6  0x08050288 in boxes_main () at
+> > >> toys/other/boxes.c:2482 #7  0x0804b262 in toy_exec
+> > >> (argv=0xbffffd58) at main.c:104 #8  0x0804b29d in toybox_main ()
+> > >> at main.c:118 #9  0x0804b262 in toy_exec (argv=0xbffffd54) at
+> > >> main.c:104 #10 0x0804b29d in toybox_main () at main.c:118
+> > >> #11 0x0804affa in main (argc=5, argv=0xbffffd54) at main.c:159  
+> > >
+> > > No segfault here when I try that, nor with different files.  As I
+> > > said, it has bugs.  I have seen other cases before when NULL lines
+> > > are passed around near that code.  Guess I've not got them all.
+> > > Might help to mention what terminal proggy you are using, it's
+> > > size in characters, toybox version, OS, etc.  Something is
+> > > different between you and me.  
+> > 
+> > Terminal Program: PuTTY
+> > Windows size: 80 * 25 chars
+> > Toybox version: hg head
+> > OS: Linux 3.2 (Debian wheezy)
+> > File: Toybox LICENSE file  
+> 
+> I'll install PuTTY, try toybox hg head, and play with them later, see
+> if I can reproduce that segfault.  I use the last released tarball of
+> toybox, an old Ubuntu, and a bunch of other terminal proggies.  I did
+> not know that PuTTY had been ported to Unix.
+> 
+> But as I mentioned, not interested in a bug hunt right now.  That will
+> be more appropriate when it's less of a "sandbox for testing the
+> ideas" and more of a "good enough to bother using".  Always good to
+> have other terminals for testing though.  
+
+Seems to be sensitive to the number of lines.  On my usual huge
+roxterm, using either toybox 0.4 or hg head, doing this -
+
+./toybox boxes -m less LICENSE -h 25
+
+and just hitting down arrow until you get to the bottom of the page
+segfaults as well.  -h means "pretend the terminal is that many lines
+high", there's a similar -w as well.  80x25 in any other terminal did
+the same.  For that particular file (17 lines long), any value of -h
+between 19 and 34 will segfault after some moving around.  -h 35 makes
+it segfault straight away.  Less than 19 or over 35 is fine.  Longer
+files don't have that problem, though I suspect it will happen on
+shortish files where the number of lines is about the length of the
+screen.
+
+I guess that somewhere I'm doing maths wrong and getting an out of
+bounds line number when the file length is close to the screen length.
+I'll make note of that, and fix it when I next get time to beat on
+boxes.
+
+Thanks for reporting it Roy.
+*/
+
+int formatLine(view *view, char *input, char **output)
+{
+  int len = strlen(input), i = 0, o = 0;
+
+  *output = xrealloc(*output, len + 1);
+
+  while (input[i])
+  {
+    if ('\t' == input[i])
+    {
+      int j = 8 - (i % 8);
+
+      *output = xrealloc(*output, len + j + 1);
+      for (; j; j--)
+      {
+        (*output)[o++] = ' ';
+        len++;
+      }
+      len--;  // Not counting the actual tab character itself.
+    }
+    else
+      (*output)[o++] = input[i];
+    i++;
+  }
+  (*output)[o++] = '\0';
+
+  return len;
+}
+
+void drawContentLine(view *view, int y, int start, int end, char *left, char *internal, char *contents, char *right, int current)
+{
+  char *temp = NULL;
+  int offset = view->offsetX, len;
+
+  if (contents == view->line->line)
+  {
+    view->oW = formatLine(view, contents, &(view->output));
+    temp = view->output;
+    len = view->oW;
+  }
+  else  // Only time we are not drawing the current line, and only used for drawing the entire page.
+    len = formatLine(NULL, contents, &(temp));
+
+  if (offset > len)
+    offset = len;
+  drawLine(y, start, end, left, internal, &(temp[offset]), right, current);
+}
+
+void updateLine(view *view)
+{
+  int y, len;
+
+  // Coz things might change out from under us, find the current view.  Again.
+  if (commandMode)      view = commandLine;
+  else          view = currentBox->view;
+
+  // TODO - When doing scripts and such, might want to turn off the line update until finished.
+  // Draw the prompt and the current line.
+  y = view->Y + (view->cY - view->offsetY);
+  len = strlen(view->prompt);
+  drawLine(y, view->X, view->X + view->W, "", " ", view->prompt, "", 0);
+  drawContentLine(view, y, view->X + len, view->X + view->W, "", " ", view->line->line, "", 1);
+  // Move the cursor.
+  printf("\x1B[%d;%dH", y + 1, view->X + len + (view->cX - view->offsetX) + 1);
+  fflush(stdout);
+}
+
+void doCommand(view *view, char *command)
+{
+  if (command)
+  {
+    struct function *functions = view->content->context->commands;
+    int i;
+
+// TODO - Some editors have a shortcut command concept.  The smallest unique first part of each command will match, as well as anything longer.
+//          A further complication is if we are not implementing some commands that might change what is "shortest unique prefix".
+
+    for (i = 0; functions[i].name; i++)
+    {
+      if (strcmp(functions[i].name, command) == 0)
+      {
+        if (functions[i].handler)
+        {
+          functions[i].handler(view);
+          updateLine(view);
+        }
+        break;
+      }
+    }
+  }
+}
+
+int moveCursorAbsolute(view *view, long cX, long cY, long sX, long sY)
+{
+  struct line *newLine = view->line;
+  long oX = view->offsetX, oY = view->offsetY;
+  long lX = view->oW, lY = view->content->lines.length - 1;
+  long nY = view->cY;
+  uint16_t w = view->W - 1, h = view->H - 1;
+  int moved = 0, updatedY = 0, endOfLine = 0;
+
+  // Check if it's still within the contents.
+  if (0 > cY)    // Trying to move before the beginning of the content.
+    cY = 0;
+  else if (lY < cY)  // Trying to move beyond end of the content.
+    cY = lY;
+  if (0 > cX)    // Trying to move before the beginning of the line.
+  {
+    // See if we can move to the end of the previous line.
+    if (view->line->prev != &(view->content->lines))
+    {
+      cY--;
+      endOfLine = 1;
+    }
+    else
+      cX = 0;
+  }
+  else if (lX < cX)  // Trying to move beyond end of line.
+  {
+    // See if we can move to the begining of the next line.
+    if (view->line->next != &(view->content->lines))
+    {
+      cY++;
+      cX = 0;
+    }
+    else
+      cX = lX;
+  }
+
+  // Find the new line.
+  while (nY != cY)
+  {
+    updatedY = 1;
+    if (nY < cY)
+    {
+      newLine = newLine->next;
+      nY++;
+      if (view->content->lines.prev == newLine)  // We are at the end if we have wrapped to the beginning.
+        break;
+    }
+    else
+    {
+      newLine = newLine->prev;
+      nY--;
+      if (view->content->lines.next == newLine)  // We are at the end if we have wrapped to the beginning.
+        break;
+    }
+  }
+  cY = nY;
+
+  // Check if we have moved past the end of the new line.
+  if (updatedY)
+  {
+    // Format it.
+    view->oW = formatLine(view, newLine->line, &(view->output));
+    if (view->oW < cX)
+      endOfLine = 1;
+    if (endOfLine)
+      cX = view->oW;
+  }
+
+  // Let the formatter decide if it wants to adjust things.
+  // It's up to the formatter to deal with things if it changes cY.
+  // On the other hand, changing cX is it's job.
+  formatCheckCursor(view, &cX, &cY, newLine->line);
+
+  // Check the scrolling.
+  lY -= view->H - 1;
+  oX += sX;
+  oY += sY;
+
+  if (oY > cY)      // Trying to move above the box.
+    oY += cY - oY;
+  else if ((oY + h) < cY)    // Trying to move below the box
+    oY += cY - (oY + h);
+  if (oX > cX)      // Trying to move to the left of the box.
+    oX += cX - oX;
+  else if ((oX + w) <= cX)  // Trying to move to the right of the box.
+    oX += cX - (oX + w);
+
+  if (oY < 0)
+    oY = 0;
+  if (oY >= lY)
+    oY = lY;
+  if (oX < 0)
+    oX = 0;
+  // TODO - Should limit oX to less than the longest line, minus box width.
+  //          Gonna be a pain figuring out what the longest line is.
+  //          On the other hand, don't think that will be an actual issue unless "move past end of line" is enabled, and that's an advanced editor thing.
+  //          Though still might want to do that for the longest line on the new page to be.
+
+  if ((view->cX != cX) || (view->cY != cY))
+    moved = 1;
+
+  // Actually update stuff, though some have been done already.
+  view->cX = cX;
+  view->cY = cY;
+  view->line = newLine;
+
+  // Handle scrolling.
+  if ((view->offsetX != oX) || (view->offsetY != oY))
+  {
+    view->offsetX = oX;
+    view->offsetY = oY;
+
+    if (view->box)
+      drawBox(view->box);
+  }
+
+  return moved;
+}
+
+int moveCursorRelative(view *view, long cX, long cY, long sX, long sY)
+{
+  return moveCursorAbsolute(view, view->cX + cX, view->cY + cY, sX, sY);
+}
+
+void sizeViewToBox(box *box, int X, int Y, int W, int H)
+{
+  uint16_t one = 1, two = 2;
+
+  if (!(box->flags & BOX_BORDER))
+  {
+      one = 0;
+      two = 0;
+  }
+  box->view->X = X;
+  box->view->Y = Y;
+  box->view->W = W;
+  box->view->H = H;
+  if (0 > X)  box->view->X = box->X + one;
+  if (0 > Y)  box->view->Y = box->Y + one;
+  if (0 > W)  box->view->W = box->W - two;
+  if (0 > H)  box->view->H = box->H - two;
+}
+
+view *addView(char *name, struct context *context, char *filePath, uint16_t X, uint16_t Y, uint16_t W, uint16_t H)
+{
+  view *result = xzalloc(sizeof(struct _view));
+
+  result->X = X;
+  result->Y = Y;
+  result->W = W;
+  result->H = H;
+
+  result->content = addContent(name, context, filePath);
+  result->prompt = xzalloc(1);
+  // If there was content, format it's first line as usual, otherwise create an empty first line.
+  if (result->content->lines.next != &(result->content->lines))
+  {
+    result->line = result->content->lines.next;
+    result->oW = formatLine(result, result->line->line, &(result->output));
+  }
+  else
+  {
+    result->line = addLine(result->content, NULL, "\0", 0);
+    result->output = xzalloc(1);
+  }
+
+  return result;
+}
+
+box *addBox(char *name, struct context *context, char *filePath, uint16_t X, uint16_t Y, uint16_t W, uint16_t H)
+{
+  box *result = xzalloc(sizeof(struct _box));
+
+  result->X = X;
+  result->Y = Y;
+  result->W = W;
+  result->H = H;
+  result->view = addView(name, context, filePath, X, Y, W, H);
+  result->view->box = result;
+  sizeViewToBox(result, X, Y, W, H);
+
+  return result;
+}
+
+void freeBox(box *box)
+{
+  if (box)
+  {
+    freeBox(box->sub1);
+    freeBox(box->sub2);
+    if (box->view)
+    {
+      // In theory the line should not be part of the content if there is no content, so we should free it.
+      if (!box->view->content)
+        freeLine(NULL, box->view->line);
+      free(box->view->prompt);
+      free(box->view->output);
+      free(box->view);
+    }
+    free(box);
+  }
+}
+
+void drawBox(box *box)
+{
+  // This could be heavily optimized, but let's keep things simple for now.
+  // Optimized for sending less characters I mean, on slow serial links for instance.
+
+  char **bchars = (toys.optflags & FLAG_a) ? borderChars[0] : borderChars[1];
+  char *left = "\0", *right = "\0";
+  struct line *lines = NULL;
+  int y = box->Y, current = (box == currentBox);
+  uint16_t h = box->Y + box->H;
+
+  if (current)
+    bchars = (toys.optflags & FLAG_a) ? borderCharsCurrent[0] : borderCharsCurrent[1];
+
+  // Slow and laborious way to figure out where in the linked list of lines we start from.
+  // Wont scale well, but is simple.
+  if (box->view && box->view->content)
+  {
+    int i = box->view->offsetY;
+
+    lines = &(box->view->content->lines);
+    while (i--)
+    {
+      lines = lines->next;
+      if (&(box->view->content->lines) == lines)  // We are at the end if we have wrapped to the beginning.
+        break;
+    }
+  }
+
+  if (box->flags & BOX_BORDER)
+  {
+    h--;
+    left = right = bchars[1];
+    drawLine(y++, box->X, box->X + box->W, bchars[2], bchars[0], NULL, bchars[3], current);
+  }
+
+  while (y < h)
+  {
+    char *line = "";
+
+    if (lines)
+    {
+      lines = lines->next;
+      if (&(box->view->content->lines) == lines)  // We are at the end if we have wrapped to the beginning.
+        lines = NULL;
+      else
+        line = lines->line;
+      // Figure out which line is our current line while we are here.
+      if (box->view->Y + (box->view->cY - box->view->offsetY) == y)
+        box->view->line = lines;
+    }
+    drawContentLine(box->view, y++, box->X, box->X + box->W, left, " ", line, right, current);
+  }
+  if (box->flags & BOX_BORDER)
+    drawLine(y++, box->X, box->X + box->W, bchars[4], bchars[0], NULL, bchars[5], current);
+  fflush(stdout);
+}
+
+void drawBoxes(box *box)
+{
+  if (box->sub1)  // If there's one sub box, there's always two.
+  {
+    drawBoxes(box->sub1);
+    drawBoxes(box->sub2);
+  }
+  else
+    drawBox(box);
+}
+
+void calcBoxes(box *box)
+{
+  if (box->sub1)  // If there's one sub box, there's always two.
+  {
+    box->sub1->X = box->X;
+    box->sub1->Y = box->Y;
+    box->sub1->W = box->W;
+    box->sub1->H = box->H;
+    box->sub2->X = box->X;
+    box->sub2->Y = box->Y;
+    box->sub2->W = box->W;
+    box->sub2->H = box->H;
+    if (box->flags & BOX_HSPLIT)
+    {
+      box->sub1->H *= box->split;
+      box->sub2->H -= box->sub1->H;
+      box->sub2->Y += box->sub1->H;
+    }
+    else
+    {
+      box->sub1->W *= box->split;
+      box->sub2->W -= box->sub1->W;
+      box->sub2->X += box->sub1->W;
+    }
+    sizeViewToBox(box->sub1, -1, -1, -1, -1);
+    calcBoxes(box->sub1);
+    sizeViewToBox(box->sub2, -1, -1, -1, -1);
+    calcBoxes(box->sub2);
+  }
+  // Move the cursor to where it is, to check it's not now outside the box.
+  moveCursorAbsolute(box->view, box->view->cX, box->view->cY, 0, 0);
+
+  // We could call drawBoxes() here, but this is recursive, and so is drawBoxes().
+  // The combination might be deadly.  Drawing the content of a box might be an expensive operation.
+  // Later we might use a dirty box flag to deal with this, if it's not too much of a complication.
+}
+
+void deleteBox(view *view)
+{
+  box *box = view->box;
+
+  if (box->parent)
+  {
+    struct _box *oldBox = box, *otherBox = box->parent->sub1;
+
+    if (otherBox == oldBox)
+      otherBox = box->parent->sub2;
+    if (currentBox->parent == box->parent)
+      currentBox = box->parent;
+    box = box->parent;
+    box->X = box->sub1->X;
+    box->Y = box->sub1->Y;
+    if (box->flags & BOX_HSPLIT)
+      box->H = box->sub1->H + box->sub2->H;
+    else
+      box->W = box->sub1->W + box->sub2->W;
+    box->flags &= ~BOX_HSPLIT;
+    // Move the other sub boxes contents up to this box.
+    box->sub1 = otherBox->sub1;
+    box->sub2 = otherBox->sub2;
+    if (box->sub1)
+    {
+        box->sub1->parent = box;
+        box->sub2->parent = box;
+        box->flags = otherBox->flags;
+        if (currentBox == box)
+          currentBox = box->sub1;
+    }
+    else
+    {
+      if (!box->parent)
+        box->flags &= ~BOX_BORDER;
+      box->split = 1.0;
+    }
+    otherBox->sub1 = NULL;
+    otherBox->sub2 = NULL;
+    // Safe to free the boxes now that we have all their contents.
+    freeBox(otherBox);
+    freeBox(oldBox);
+  }
+  // Otherwise it must be a single full screen box.  Never delete that one, unless we are quitting.
+
+  // Start the recursive recalculation of all the sub boxes.
+  calcBoxes(box);
+  drawBoxes(box);
+}
+
+void cloneBox(struct _box *box, struct _box *sub)
+{
+  sub->parent = box;
+  // Only a full screen box has no border.
+  sub->flags |= BOX_BORDER;
+  sub->view = xmalloc(sizeof(struct _view));
+  // TODO - After this is more stable, should check if the memcpy() is simpler than - xzalloc() then copy a few things manually.
+  //          Might even be able to arrange the structure so we can memcpy just part of it, leaving the rest blank.
+  memcpy(sub->view, box->view, sizeof(struct _view));
+  sub->view->damage = NULL;
+  sub->view->data = NULL;
+  sub->view->output = NULL;
+  sub->view->box = sub;
+  if (box->view->prompt)
+    sub->view->prompt = strdup(box->view->prompt);
+}
+
+void splitBox(box *box, float split)
+{
+  uint16_t size;
+  int otherBox = 0;
+
+  // First some sanity checks.
+  if (0.0 > split)
+  {
+    // TODO - put this in the status line, or just silently fail.  Also, better message.  lol
+    fprintf(stderr, "User is crazy.\n");
+    return;
+  }
+  else if (1.0 <= split)  // User meant to unsplit, and it may already be split.
+  {
+    // Actually, this means that the OTHER sub box gets deleted.
+    if (box->parent)
+    {
+      if (box == box->parent->sub1)
+        deleteBox(box->parent->sub2->view);
+      else
+        deleteBox(box->parent->sub1->view);
+    }
+    return;
+  }
+  else if (0.0 < split)  // This is the normal case, so do nothing.
+  {
+  }
+  else      // User meant to delete this, zero split.
+  {
+      deleteBox(box->view);
+      return;
+  }
+  if (box->flags & BOX_HSPLIT)
+    size = box->H;
+  else
+    size = box->W;
+  if (6 > size)    // Is there room for 2 borders for each sub box and one character of content each?
+        // TODO - also should check the contents minimum size.
+        // No need to check the no border case, that's only for full screen.
+        // People using terminals smaller than 6 characters get what they deserve.
+  {
+    // TODO - put this in the status line, or just silently fail.
+    fprintf(stderr, "Box is too small to split.\n");
+    return;
+  }
+
+  // Note that a split box is actually three boxes.  The parent, which is not drawn, and the two subs, which are.
+  // Based on the assumption that there wont be lots of boxes, this keeps things simple.
+  // It's possible that the box has already been split, and this is called just to update the split.
+  box->split = split;
+  if (NULL == box->sub1)  // If not split already, do so.
+  {
+    box->sub1 = xzalloc(sizeof(struct _box));
+    box->sub2 = xzalloc(sizeof(struct _box));
+    cloneBox(box, box->sub1);
+    cloneBox(box, box->sub2);
+    if (box->flags & BOX_HSPLIT)
+    {
+      // Split the boxes in the middle of the content.
+      box->sub2->view->offsetY += (box->H * box->split) - 2;
+      // Figure out which sub box the cursor will be in, then update the cursor in the other box.
+      if (box->sub1->view->cY < box->sub2->view->offsetY)
+        box->sub2->view->cY = box->sub2->view->offsetY;
+      else
+      {
+        box->sub1->view->cY = box->sub2->view->offsetY - 1;
+        otherBox = 1;
+      }
+    }
+    else
+    {
+      // Split the boxes in the middle of the content.
+      box->sub2->view->offsetX += (box->W * box->split) - 2;
+      // Figure out which sub box the cursor will be in, then update the cursor in the other box.
+      if (box->sub1->view->cX < box->sub2->view->offsetX)
+        box->sub2->view->cX = box->sub2->view->offsetX;
+      else
+      {
+        box->sub1->view->cX = box->sub2->view->offsetX - 1;
+        otherBox = 1;
+      }
+    }
+  }
+
+  if ((currentBox == box) && (box->sub1))
+  {
+    if (otherBox)
+      currentBox = box->sub2;
+    else
+      currentBox = box->sub1;
+  }
+
+  // Start the recursive recalculation of all the sub boxes.
+  calcBoxes(box);
+  drawBoxes(box);
+}
+
+// TODO - Might be better to just have a double linked list of boxes, and traverse that instead.
+//          Except that leaves a problem when deleting boxes, could end up with a blank space.
+void switchBoxes(view *view)
+{
+  box *box = view->box;
+
+  // The assumption here is that box == currentBox.
+  struct _box *oldBox = currentBox;
+  struct _box *thisBox = box;
+  int backingUp = 0;
+
+  // Depth first traversal.
+  while ((oldBox == currentBox) && (thisBox->parent))
+  {
+    if (thisBox == thisBox->parent->sub1)
+    {
+      if (backingUp && (thisBox->parent))
+        currentBox = thisBox->parent->sub2;
+      else if (thisBox->sub1)
+        currentBox = thisBox->sub1;
+      else
+        currentBox = thisBox->parent->sub2;
+    }
+    else if (thisBox == thisBox->parent->sub2)
+    {
+      thisBox = thisBox->parent;
+      backingUp = 1;
+    }
+  }
+
+  // If we have not found the next box to move to, move back to the beginning.
+  if (oldBox == currentBox)
+    currentBox = rootBox;
+
+  // If we ended up on a parent box, go to it's first sub.
+  while (currentBox->sub1)
+    currentBox = currentBox->sub1;
+
+  // Just redraw them all.
+  drawBoxes(rootBox);
+}
+
+// TODO - It might be better to do away with this bunch of single line functions
+//        and map script commands directly to lower functions.
+//        How to deal with the various argument needs?
+//        Might be where we can re use the toybox argument stuff.
+
+void halveBoxHorizontally(view *view)
+{
+  view->box->flags |= BOX_HSPLIT;
+  splitBox(view->box, 0.5);
+}
+
+void halveBoxVertically(view *view)
+{
+  view->box->flags &= ~BOX_HSPLIT;
+  splitBox(view->box, 0.5);
+}
+
+void switchMode(view *view)
+{
+  currentBox->view->mode++;
+  // Assumes that modes will always have a key mapping, which I think is a safe bet.
+  if (NULL == currentBox->view->content->context->modes[currentBox->view->mode].keys)
+    currentBox->view->mode = 0;
+  commandMode = currentBox->view->content->context->modes[currentBox->view->mode].flags & 1;
+}
+
+void leftChar(view *view)
+{
+  moveCursorRelative(view, -1, 0, 0, 0);
+}
+
+void rightChar(view *view)
+{
+  moveCursorRelative(view, 1, 0, 0, 0);
+}
+
+void upLine(view *view)
+{
+  moveCursorRelative(view, 0, -1, 0, 0);
+}
+
+void downLine(view *view)
+{
+  moveCursorRelative(view, 0, 1, 0, 0);
+}
+
+void upPage(view *view)
+{
+  moveCursorRelative(view, 0, 0 - (view->H - 1), 0, 0 - (view->H - 1));
+}
+
+void downPage(view *view)
+{
+  moveCursorRelative(view, 0, view->H - 1, 0, view->H - 1);
+}
+
+void endOfLine(view *view)
+{
+  moveCursorAbsolute(view, strlen(view->prompt) + view->oW, view->cY, 0, 0);
+}
+
+void startOfLine(view *view)
+{
+  // TODO - add the advanced editing "smart home".
+  moveCursorAbsolute(view, strlen(view->prompt), view->cY, 0, 0);
+}
+
+void splitLine(view *view)
+{
+  // TODO - should move this into mooshLines().
+  addLine(view->content, view->line, &(view->line->line[view->iX]), 0);
+  view->line->line[view->iX] = '\0';
+  moveCursorAbsolute(view, 0, view->cY + 1, 0, 0);
+  if (view->box)
+    drawBox(view->box);
+}
+
+void deleteChar(view *view)
+{
+  // TODO - should move this into mooshLines().
+  // If we are at the end of the line, then join this and the next line.
+  if (view->oW == view->cX)
+  {
+    // Only if there IS a next line.
+    if (&(view->content->lines) != view->line->next)
+    {
+      mooshStrings(view->line, view->line->next->line, view->iX, 1, !overWriteMode);
+      view->line->next->line = NULL;
+      freeLine(view->content, view->line->next);
+      // TODO - should check if we are on the last page, then deal with scrolling.
+      if (view->box)
+        drawBox(view->box);
+    }
+  }
+  else
+    mooshStrings(view->line, NULL, view->iX, 1, !overWriteMode);
+}
+
+void backSpaceChar(view *view)
+{
+  if (moveCursorRelative(view, -1, 0, 0, 0))
+    deleteChar(view);
+}
+
+void saveContent(view *view)
+{
+  saveFile(view->content);
+}
+
+void executeLine(view *view)
+{
+  struct line *result = view->line;
+
+  // Don't bother doing much if there's nothing on this line.
+  if (result->line[0])
+  {
+    doCommand(currentBox->view, result->line);
+    // If we are not at the end of the history contents.
+    if (&(view->content->lines) != result->next)
+    {
+      struct line *line = view->content->lines.prev;
+
+      // Remove the line first.
+      result->next->prev = result->prev;
+      result->prev->next = result->next;
+      // Check if the last line is already blank, then remove it.
+      if ('\0' == line->line[0])
+      {
+        freeLine(view->content, line);
+        line = view->content->lines.prev;
+      }
+      // Then add it to the end.
+      result->next = line->next;
+      result->prev = line;
+      line->next->prev = result;
+      line->next = result;
+      view->cY = view->content->lines.length - 1;
+    }
+    moveCursorAbsolute(view, 0, view->content->lines.length, 0, 0);
+    // Make sure there is one blank line at the end.
+    if ('\0' != view->line->line[0])
+    {
+      endOfLine(view);
+      splitLine(view);
+    }
+  }
+
+  saveFile(view->content);
+}
+
+void quit(view *view)
+{
+  handle_keys_quit();
+}
+
+void nop(view *view)
+{
+  // 'tis a nop, don't actually do anything.
+}
+
+
+typedef void (*CSIhandler) (long extra, int *code, int count);
+
+struct CSI
+{
+  char *code;
+  CSIhandler func;
+};
+
+static void termSize(long extra, int *params, int count)
+{
+  struct _view *view = (struct _view *) extra;          // Though we pretty much stomp on this straight away.
+  int r = params[0], c = params[1];
+
+  // The defaults are 1, which get ignored by the heuristic below.
+  // Check it's not an F3 key variation, coz some of them use the same CSI function code.
+  // This is a heuristic, we are checking against an unusable terminal size.
+  // TODO - Double check what the maximum F3 variations can be.
+  if ((2 == count) && (8 < r) && (8 < c))
+  {
+    commandLine->Y = r;
+    commandLine->W = c;
+    rootBox->W = c;
+    rootBox->H = r - 1;
+    sizeViewToBox(rootBox, -1, -1, -1, -1);
+    calcBoxes(rootBox);
+    drawBoxes(rootBox);
+
+    // Move the cursor to where it is, to check it's not now outside the terminal window.
+    moveCursorAbsolute(rootBox->view, rootBox->view->cX, rootBox->view->cY, 0, 0);
+
+    // We have no idea which is the current view now.
+    if (commandMode)    view = commandLine;
+    else                view = currentBox->view;
+    updateLine(view);
+  }
+}
+
+struct CSI CSIcommands[] =
+{
+  {"R", termSize}       // Parameters are cursor line and column.  Note this may be sent at other times, not just during terminal resize.
+};
+
+
+// Callback for incoming sequences from the terminal.
+static int handleEvent(long extra, struct keyevent *event)
+{
+  switch (event->type)
+  {
+    case HK_CSI :
+    {
+      int j;
+
+      for (j = 0; j < ARRAY_LEN(CSIcommands); j++)
+      {
+        if (strcmp(CSIcommands[j].code, event->sequence) == 0)
+        {
+          CSIcommands[j].func(extra, event->params, event->count);
+          break;
+        }
+      }
+      break;
+    }
+
+    case HK_KEYS :
+    {
+      struct _view *view = (struct _view *) extra;              // Though we pretty much stomp on this straight away.
+      struct keyCommand *commands = currentBox->view->content->context->modes[currentBox->view->mode].keys;
+      int j, l = strlen(event->sequence);
+
+      // Coz things might change out from under us, find the current view.
+      if (commandMode)  view = commandLine;
+      else              view = currentBox->view;
+
+      // Search for a key sequence bound to a command.
+      for (j = 0; commands[j].key; j++)
+      {
+        if (strncmp(commands[j].key, event->sequence, l) == 0)
+        {
+          // If it's a partial match, keep accumulating them.
+          if (strlen(commands[j].key) != l)
+            return 0;
+          else
+          {
+            doCommand(view, commands[j].command);
+            return 1;
+          }
+        }
+      }
+
+      // See if it's ordinary keys.
+      // NOTE - with vi style ordinary keys can be commands,
+      // but they would be found by the command check above first.
+      if (!event->isTranslated)
+      {
+        // TODO - Should check for tabs to, and insert them.
+        //        Though better off having a function for that?
+        mooshStrings(view->line, event->sequence, view->iX, 0, !overWriteMode);
+        view->oW = formatLine(view, view->line->line, &(view->output));
+        moveCursorRelative(view, strlen(event->sequence), 0, 0, 0);
+        updateLine(view);
+      }
+      break;
+    }
+
+    default :  break;
+  }
+
+  // Tell handle_keys to drop it, coz we dealt with it, or it's not one of ours.
+  return 1;
+}
+
+
+// The default command to function mappings, with help text.  Any editor that does not have it's own commands can use these for keystroke binding and such.
+// Though most of the editors have their own variation.
+// TODO - Maybe just use the joe one as default, it uses short names at least.
+//        Though vi is the only one in POSIX, so might be better to treat that one as the "standard" default.
+//        With some commands from others for stuff vi doesn't support.
+struct function simpleEditCommands[] =
+{
+  {"backSpaceChar",     "Back space last character.",           0, {backSpaceChar}},
+  {"deleteBox",         "Delete a box.",                        0, {deleteBox}},
+  {"deleteChar",        "Delete current character.",            0, {deleteChar}},
+  {"downLine",          "Move cursor down one line.",           0, {downLine}},
+  {"downPage",          "Move cursor down one page.",           0, {downPage}},
+  {"endOfLine",         "Go to end of line.",                   0, {endOfLine}},
+  {"executeLine",       "Execute a line as a script.",          0, {executeLine}},
+  {"leftChar",          "Move cursor left one character.",      0, {leftChar}},
+  {"quit",              "Quit the application.",                0, {quit}},
+  {"rightChar",         "Move cursor right one character.",     0, {rightChar}},
+  {"save",              "Save.",                                0, {saveContent}},
+  {"splitH",            "Split box in half horizontally.",      0, {halveBoxHorizontally}},
+  {"splitLine",         "Split line at cursor.",                0, {splitLine}},
+  {"splitV",            "Split box in half vertically.",        0, {halveBoxVertically}},
+  {"startOfLine",       "Go to start of line.",                 0, {startOfLine}},
+  {"switchBoxes",       "Switch to another box.",               0, {switchBoxes}},
+  {"switchMode",        "Switch between command and box.",      0, {switchMode}},
+  {"upLine",            "Move cursor up one line.",             0, {upLine}},
+  {"upPage",            "Move cursor up one page.",             0, {upPage}},
+  {NULL, NULL, 0, {NULL}}
+};
+
+// Construct a simple command line.
+
+// The key to command mappings.
+// TODO - Should not move off the ends of the line to the next / previous line.
+struct keyCommand simpleCommandKeys[] =
+{
+  {"BS",        "backSpaceChar"},
+  {"Del",       "deleteChar"},
+  {"Down",      "downLine"},
+  {"End",       "endOfLine"},
+  {"F10",       "quit"},
+  {"Home",      "startOfLine"},
+  {"Left",      "leftChar"},
+  {"Enter",     "executeLine"},
+  {"Return",    "executeLine"},
+  {"Right",     "rightChar"},
+  {"Esc",       "switchMode"},
+  {"Up",        "upLine"},
+  {NULL, NULL}
+};
+
+
+// Construct a simple emacs editor.
+
+// Mostly control keys, some meta keys.
+// Ctrl-h and Ctrl-x have more keys in the commands.  Some of those extra keys are commands by themselves.  Up to "Ctrl-x 4 Ctrl-g" which apparently is identical to just Ctrl-g.  shrugs
+//   Ctrl-h is backspace / del.  Pffft.
+// Meta key is either Alt-keystroke, Esc keystroke, or an actual Meta-keystroke (do they still exist?).
+//   TODO - Alt and Meta not supported yet, so using Esc.
+// Windows commands.
+
+// readline uses these same commands, and defaults to emacs keystrokes.
+struct function simpleEmacsCommands[] =
+{
+  {"delete-backward-char",      "Back space last character.",           0, {backSpaceChar}},
+  {"delete-window",             "Delete a box.",                        0, {deleteBox}},
+  {"delete-char",               "Delete current character.",            0, {deleteChar}},
+  {"next-line",                 "Move cursor down one line.",           0, {downLine}},
+  {"scroll-up",                 "Move cursor down one page.",           0, {downPage}},
+  {"end-of-line",               "Go to end of line.",                   0, {endOfLine}},
+  {"accept-line",               "Execute a line as a script.",          0, {executeLine}},              // From readline, which uses emacs commands, coz mg at least does not seem to have this.
+  {"backward-char",             "Move cursor left one character.",      0, {leftChar}},
+  {"save-buffers-kill-emacs",   "Quit the application.",                0, {quit}},                     // TODO - Does more than just quit.
+  {"forward-char",              "Move cursor right one character.",     0, {rightChar}},
+  {"save-buffer",               "Save.",                                0, {saveContent}},
+  {"split-window-horizontally", "Split box in half horizontally.",      0, {halveBoxHorizontally}},     // TODO - Making this one up for now, mg does not have it.
+  {"newline",                   "Split line at cursor.",                0, {splitLine}},
+  {"split-window-vertically",   "Split box in half vertically.",        0, {halveBoxVertically}},
+  {"beginning-of-line",         "Go to start of line.",                 0, {startOfLine}},
+  {"other-window",              "Switch to another box.",               0, {switchBoxes}},              // There is also "previous-window" for going in the other direction, which we don't support yet.
+  {"execute-extended-command",  "Switch between command and box.",      0, {switchMode}},               // Actually a one time invocation of the command line.
+  {"previous-line",             "Move cursor up one line.",             0, {upLine}},
+  {"scroll-down",               "Move cursor up one page.",             0, {upPage}},
+  {NULL, NULL, 0, {NULL}}
+};
+
+// The key to command mappings.
+struct keyCommand simpleEmacsKeys[] =
+{
+  {"BS",        "delete-backward-char"},
+  {"Del",       "delete-backward-char"},
+  {"^D",        "delete-char"},
+  {"Down",      "next-line"},
+  {"^N",        "next-line"},
+  {"End",       "end-of-line"},
+  {"^E",        "end-of-line"},
+  {"^X^C",      "save-buffers-kill-emacs"},
+  {"^X^S",      "save-buffer"},
+  {"Home",      "beginning-of-line"},
+  {"^A",        "beginning-of-line"},
+  {"Left",      "backward-char"},
+  {"^B",        "backward-char"},
+  {"PgDn",      "scroll-up"},
+  {"^V",        "scroll-up"},
+  {"PgUp",      "scroll-down"},
+  {"Escv",      "scroll-down"},                 // M-v
+  {"Enter",     "newline"},
+  {"Return",    "newline"},
+  {"Right",     "forward-char"},
+  {"^F",        "forward-char"},
+  {"Escx",      "execute-extended-command"},    // M-x
+  {"^X2",       "split-window-vertically"},
+  {"^XP",       "other-window"},
+  {"^X0",       "delete-window"},
+  {"Up",        "previous-line"},
+  {"^P",        "previous-line"},
+  {NULL, NULL}
+};
+
+struct keyCommand simpleEmacsCommandKeys[] =
+{
+  {"Del",       "delete-backwards-char"},
+  {"^D",        "delete-char"},
+  {"Down",      "next-line"},
+  {"^N",        "next-line"},
+  {"End",       "end-of-line"},
+  {"^E",        "end-of-line"},
+  {"Home",      "beginning-of-line"},
+  {"^A",        "beginning-of-line"},
+  {"Left",      "backward-char"},
+  {"^B",        "backward-char"},
+  {"Right",     "forward-char"},
+  {"^F",        "forward-char"},
+  {"Up",        "previous-line"},
+  {"^P",        "previous-line"},
+  {"Enter",     "accept-line"},
+  {"Return",    "accept-line"},
+  {"Escx",      "execute-extended-command"},
+  {NULL, NULL}
+};
+
+// An array of various modes.
+struct mode simpleEmacsMode[] =
+{
+  {simpleEmacsKeys, NULL, NULL, 0},
+  {simpleEmacsCommandKeys, NULL, NULL, 1},
+  {NULL, NULL, NULL}
+};
+
+// Put it all together into a simple editor context.
+struct context simpleEmacs =
+{
+  simpleEmacsCommands,
+  simpleEmacsMode,
+  NULL,
+  NULL,
+  NULL
+};
+
+
+// Construct a simple joe / wordstar editor, using joe is the reference, seems to be the popular Unix variant.
+// Esc x starts up the command line.
+// Has multi control key combos.  Mostly Ctrl-K, Ctrl-[ (Esc), (Ctrl-B, Ctrl-Q in wordstar and delphi), but might be others.
+//   Can't find a single list of command mappings for joe, gotta search all over.  sigh
+//   Even the command line keystroke I stumbled on (Esc x) is not documented.
+//   Note that you don't have to let go of the Ctrl key for the second keystroke, but you can.
+
+// From http://joe-editor.sourceforge.net/list.html
+// TODO - Some of these might be wrong.  Just going by the inadequate joe docs for now.
+struct function simpleJoeCommands[] =
+{
+  {"backs",     "Back space last character.",           0, {backSpaceChar}},
+  {"abort",     "Delete a box.",                        0, {deleteBox}},        // TODO - Should do quit if it's the last window.
+  {"delch",     "Delete current character.",            0, {deleteChar}},
+  {"dnarw",     "Move cursor down one line.",           0, {downLine}},
+  {"pgdn",      "Move cursor down one page.",           0, {downPage}},
+  {"eol",       "Go to end of line.",                   0, {endOfLine}},
+  {"ltarw",     "Move cursor left one character.",      0, {leftChar}},
+  {"killjoe",   "Quit the application.",                0, {quit}},
+  {"rtarw",     "Move cursor right one character.",     0, {rightChar}},
+  {"save",      "Save.",                                0, {saveContent}},
+  {"splitw",    "Split box in half horizontally.",      0, {halveBoxHorizontally}},
+  {"open",      "Split line at cursor.",                0, {splitLine}},
+  {"bol",       "Go to start of line.",                 0, {startOfLine}},
+  {"home",      "Go to start of line.",                 0, {startOfLine}},
+  {"nextw",     "Switch to another box.",               0, {switchBoxes}},      // This is "next window", there's also "previous window" which we don't support yet.
+  {"execmd",    "Switch between command and box.",      0, {switchMode}},       // Actually I think this just switches to the command mode, not back and forth.  Or it might execute the actual command.
+  {"uparw",     "Move cursor up one line.",             0, {upLine}},
+  {"pgup",      "Move cursor up one page.",             0, {upPage}},
+
+  // Not an actual joe command.
+  {"executeLine",       "Execute a line as a script.",  0, {executeLine}},      // Perhaps this should be execmd?
+  {NULL, NULL, 0, {NULL}}
+};
+
+struct keyCommand simpleJoeKeys[] =
+{
+  {"BS",        "backs"},
+  {"^D",        "delch"},
+  {"Down",      "dnarw"},
+  {"^N",        "dnarw"},
+  {"^E",        "eol"},
+  {"^C",        "killjoe"},
+  {"^Kd",       "save"},
+  {"^K^D"       "save"},
+  {"^A",        "bol"},
+  {"Left",      "ltarw"},
+  {"^B",        "ltarw"},
+  {"^V",        "pgdn"},        // Actually half a page.
+  {"^U",        "pgup"},        // Actually half a page.
+  {"Enter",     "open"},
+  {"Return",    "open"},
+  {"Right",     "rtarw"},
+  {"^F",        "rtarw"},
+  {"Escx",      "execmd"},
+  {"Esc^X",     "execmd"},
+  {"^Ko",       "splitw"},
+  {"^K^O",      "splitw"},
+  {"^Kn",       "nextw"},
+  {"^K^N",      "nextw"},
+  {"^Kx",       "killjoe"},     // TODO - Should ask if it should save if it's been modified.  A good generic thing to do anyway.
+  {"^K^X",      "abort"},       // TODO - These two both close a window, and quit if that was the last window.
+  {"Up",        "uparw"},
+  {"^P",        "uparw"},
+  {NULL, NULL}
+};
+
+struct keyCommand simpleJoeCommandKeys[] =
+{
+  {"BS",        "backs"},
+  {"^D",        "delch"},
+  {"Down",      "dnarw"},
+  {"^N",        "dnarw"},
+  {"^E",        "eol"},
+  {"^A",        "bol"},
+  {"Left",      "ltarw"},
+  {"^B",        "ltarw"},
+  {"Right",     "rtarw"},
+  {"^F",        "rtarw"},
+  {"Escx",      "execmd"},
+  {"Esc^X",     "execmd"},
+  {"Up",        "uparw"},
+  {"^P",        "uparw"},
+  {"Enter",     "executeLine"},
+  {"Return",    "executeLine"},
+  {NULL, NULL}
+};
+
+struct mode simpleJoeMode[] =
+{
+  {simpleJoeKeys, NULL, NULL, 0},
+  {simpleJoeCommandKeys, NULL, NULL, 1},
+  {NULL, NULL, NULL, 0}
+};
+
+struct context simpleJoe =
+{
+  simpleJoeCommands,
+  simpleJoeMode,
+  NULL,
+  NULL,
+  NULL
+};
+
+
+// Simple more and / or less.
+// '/' and '?' for search command mode.  I think they both have some ex commands with the usual : command mode starter.
+// No cursor movement, just scrolling.
+// TODO - Put content into read only mode.
+// TODO - actually implement read only mode where up and down one line do actual scrolling instead of cursor movement.
+
+struct keyCommand simpleLessKeys[] =
+{
+  {"Down",      "downLine"},
+  {"j",         "downLine"},
+  {"Enter",     "downLine"},
+  {"Return",    "downLine"},
+  {"End",       "endOfLine"},
+  {"q",         "quit"},
+  {":q",        "quit"},        // TODO - A vi ism, should do ex command stuff instead.
+  {"ZZ",        "quit"},
+  {"PgDn",      "downPage"},
+  {"f",         "downPage"},
+  {" ",         "downPage"},
+  {"^F",        "downPage"},
+  {"Left",      "leftChar"},
+  {"Right",     "rightChar"},
+  {"PgUp",      "upPage"},
+  {"b",         "upPage"},
+  {"^B",        "upPage"},
+  {"Up",        "upLine"},
+  {"k",         "upLine"},
+  {NULL, NULL}
+};
+
+struct mode simpleLessMode[] =
+{
+  {simpleLessKeys, NULL, NULL, 0},
+  {simpleCommandKeys, NULL, NULL, 1},
+  {NULL, NULL, NULL}
+};
+
+struct context simpleLess =
+{
+  simpleEditCommands,
+  simpleLessMode,
+  NULL,
+  NULL,
+  NULL
+};
+
+struct keyCommand simpleMoreKeys[] =
+{
+  {"j",         "downLine"},
+  {"Enter",     "downLine"},
+  {"Return",    "downLine"},
+  {"q",         "quit"},
+  {":q",        "quit"},        // See comments for "less".
+  {"ZZ",        "quit"},
+  {"f",         "downPage"},
+  {" ",         "downPage"},
+  {"^F",        "downPage"},
+  {"b",         "upPage"},
+  {"^B",        "upPage"},
+  {"k",         "upLine"},
+  {NULL, NULL}
+};
+
+struct mode simpleMoreMode[] =
+{
+  {simpleMoreKeys, NULL, NULL, 0},
+  {simpleCommandKeys, NULL, NULL, 1},
+  {NULL, NULL, NULL}
+};
+
+struct context simpleMore =
+{
+  simpleEditCommands,
+  simpleMoreMode,
+  NULL,
+  NULL,
+  NULL
+};
+
+
+// Construct a simple mcedit / cool edit editor.
+
+struct keyCommand simpleMceditKeys[] =
+{
+  {"BS",        "backSpaceChar"},
+  {"Del",       "deleteChar"},
+  {"Down",      "downLine"},
+  {"End",       "endOfLine"},
+  {"F10",       "quit"},
+  {"Esc0",      "quit"},
+  {"F2",        "save"},
+  {"Esc2",      "save"},
+  {"Home",      "startOfLine"},
+  {"Left",      "leftChar"},
+  {"PgDn",      "downPage"},
+  {"PgUp",      "upPage"},
+  {"Enter",     "splitLine"},
+  {"Return",    "splitLine"},
+  {"Right",     "rightChar"},
+  {"Shift F2",  "switchMode"},  // MC doesn't have a command mode.
+  {"Esc:",      "switchMode"},  // Sorta vi like, and coz tmux is screwing with the shift function keys somehow.
+  {"Esc|",      "splitV"},      // MC doesn't have a split window concept, so make these up to match tmux more or less.
+  {"Esc-",      "splitH"},
+  {"Esco",      "switchBoxes"},
+  {"Escx",      "deleteBox"},
+  {"Up",        "upLine"},
+{"^C",  "switchMode"},  // To test the signal stopper.
+{"^D",  "switchMode"},  // To test the signal stopper.
+{"^Q",  "switchMode"},  // To test the signal stopper.
+{"^S",  "switchMode"},  // To test the signal stopper.
+{"^T",  "switchMode"},  // To test the signal stopper.
+{"^Z",  "switchMode"},  // To test the signal stopper.
+{"^\\", "switchMode"},  // To test the signal stopper.
+{"F1",  "switchMode"},  // To test various function keys.
+{"F3",  "switchMode"},  // To test various function keys.
+{"F4",  "switchMode"},  // To test various function keys.
+{"F5",  "switchMode"},  // To test various function keys.
+{"F6",  "switchMode"},  // To test various function keys.
+{"F7",  "switchMode"},  // To test various function keys.
+{"F8",  "switchMode"},  // To test various function keys.
+{"F9",  "switchMode"},  // To test various function keys.
+  {NULL, NULL}
+};
+
+struct mode simpleMceditMode[] =
+{
+  {simpleMceditKeys, NULL, NULL, 0},
+  {simpleCommandKeys, NULL, NULL, 1},
+  {NULL, NULL, NULL}
+};
+
+struct context simpleMcedit =
+{
+  simpleEditCommands,
+  simpleMceditMode,
+  NULL,
+  NULL,
+  NULL
+};
+
+
+// Simple nano editor.
+// Has key to function bindings, but no command line mode.  Has "enter parameter on this line" mode for some commands.
+// Control and meta keys, only singles, unlike emacs and joe.
+// Can have multiple buffers, but no windows.  Think I can skip that for simple editor.
+
+struct function simpleNanoCommands[] =
+{
+  {"backSpaceChar",     "Back space last character.",           0, {backSpaceChar}},
+  {"delete",            "Delete current character.",            0, {deleteChar}},
+  {"down",              "Move cursor down one line.",           0, {downLine}},
+  {"downPage",          "Move cursor down one page.",           0, {downPage}},
+  {"end",               "Go to end of line.",                   0, {endOfLine}},
+  {"left",              "Move cursor left one character.",      0, {leftChar}},
+  {"exit",              "Quit the application.",                0, {quit}},
+  {"right",             "Move cursor right one character.",     0, {rightChar}},
+  {"writeout",          "Save.",                                0, {saveContent}},
+  {"enter",             "Split line at cursor.",                0, {splitLine}},
+  {"home",              "Go to start of line.",                 0, {startOfLine}},
+  {"up",                "Move cursor up one line.",             0, {upLine}},
+  {"upPage",            "Move cursor up one page.",             0, {upPage}},
+  {NULL, NULL, 0, {NULL}}
+};
+
+
+// Hmm, back space, page up, and page down don't seem to have bindable commands according to the web page, but they are bound to keys anyway.
+struct keyCommand simpleNanoKeys[] =
+{
+// TODO - Delete key is ^H dammit.  Find the alternate Esc sequence for Del.
+//  {"^H",      "backSpaceChar"},       // ?
+  {"BS",        "backSpaceChar"},
+  {"^D",        "delete"},
+  {"Del",       "delete"},
+  {"^N",        "down"},
+  {"Down",      "down"},
+  {"^E",        "end"},
+  {"End",       "end"},
+  {"^X",        "exit"},
+  {"F2",        "exit"},
+  {"^O",        "writeout"},
+  {"F3",        "writeout"},
+  {"^A",        "home"},
+  {"Home",      "home"},
+  {"^B",        "left"},
+  {"Left",      "left"},
+  {"^V",        "downPage"},    // ?
+  {"PgDn",      "downPage"},
+  {"^Y",        "upPage"},      // ?
+  {"PgUp",      "upPage"},
+  {"Enter",     "enter"},       // TODO - Not sure if this is correct.
+  {"Return",    "enter"},       // TODO - Not sure if this is correct.
+  {"^F",        "right"},
+  {"Right",     "right"},
+  {"^P",        "up"},
+  {"Up",        "up"},
+  {NULL, NULL}
+};
+
+struct mode simpleNanoMode[] =
+{
+  {simpleNanoKeys, NULL, NULL, 0},
+  {NULL, NULL, NULL}
+};
+
+struct context simpleNano =
+{
+  simpleNanoCommands,
+  simpleNanoMode,
+  NULL,
+  NULL,
+  NULL
+};
+
+
+// Construct a simple vi editor.
+// Only vi is not so simple.  lol
+// The "command line" modes are /, ?, :, and !,
+//   / is regex search.
+//   ? is regex search backwards.
+//   : is ex command mode.
+//   ! is replace text with output from shell command mode.
+// Arrow keys do the right thing in "normal" mode, but not in insert mode.
+// "i" goes into insert mode, "Esc" (or Ctrl-[ or Ctrl-C) gets you out.  So much for "you can do it all touch typing on the home row".  Pffft
+//   Ah, the Esc key WAS a lot closer to the home row (where Tab usually is now) on the original keyboard vi was designed for, ADM3A.
+//   Which is also the keyboard with the arrow keys marked on h, j, k, and l keys.
+//   Did I mention that vi is just a horrid historic relic that should have died long ago?
+//   Emacs looks to have the same problem, originally designed for an ancient keyboard that is nothing like what people actually use these days.
+// "h", "j", "k", "l" move cursor, which is just random keys for dvorak users.
+// ":" goes into ex command mode.
+// ":q" deletes current window in vim.
+// ":qa!" goes into ex mode and does some sort of quit command.
+//   The 'q' is short for quit, the ! is an optional argument to quit.  No idea yet what the a is for, all windows?
+// Del or "x" to delete a character.  Del in insert mode.
+// "X" to backspace.  BS or Ctrl-H to backspace in insert mode.
+//   NOTE - Backspace in normal mode just moves left.
+// Tab or Ctrl-I to insert a tab in insert mode.
+// Return in normal mode goes to the start of the next line, or splits the line in insert mode.
+// ":help" opens a window with help text.
+// Vim window commands.
+
+// Vi needs extra variables and functions.
+static int viTempExMode;
+
+void viMode(view *view)
+{
+  currentBox->view->mode = 0;
+  commandMode = 0;
+  viTempExMode = 0;
+}
+
+void viInsertMode(view *view)
+{
+  currentBox->view->mode = 1;
+  commandMode = 0;
+}
+
+void viExMode(view *view)
+{
+  currentBox->view->mode = 2;
+  commandMode = 1;
+  // TODO - Should change this based on the event, : or Q.
+  viTempExMode = 1;
+  commandLine->prompt = xrealloc(commandLine->prompt, 2);
+  strcpy(commandLine->prompt, ":");
+}
+
+void viBackSpaceChar(view *view)
+{
+  if ((2 == currentBox->view->mode) && (0 == view->cX) && viTempExMode)
+    viMode(view);
+  else
+    backSpaceChar(view);
+}
+
+void viStartOfNextLine(view *view)
+{
+  startOfLine(view);
+  downLine(view);
+}
+
+struct function simpleViCommands[] =
+{
+  // These are actual ex commands.
+  {"insert",            "Switch to insert mode.",               0, {viInsertMode}},
+  {"quit",              "Quit the application.",                0, {quit}},
+  {"visual",            "Switch to visual mode.",               0, {viMode}},
+  {"write",             "Save.",                                0, {saveContent}},
+
+  // These are not ex commands.
+  {"backSpaceChar",     "Back space last character.",           0, {viBackSpaceChar}},
+  {"deleteBox",         "Delete a box.",                        0, {deleteBox}},
+  {"deleteChar",        "Delete current character.",            0, {deleteChar}},
+  {"downLine",          "Move cursor down one line.",           0, {downLine}},
+  {"downPage",          "Move cursor down one page.",           0, {downPage}},
+  {"endOfLine",         "Go to end of line.",                   0, {endOfLine}},
+  {"executeLine",       "Execute a line as a script.",          0, {executeLine}},
+  {"exMode",            "Switch to ex mode.",                   0, {viExMode}},
+  {"leftChar",          "Move cursor left one character.",      0, {leftChar}},
+  {"rightChar",         "Move cursor right one character.",     0, {rightChar}},
+  {"splitH",            "Split box in half horizontally.",      0, {halveBoxHorizontally}},
+  {"splitLine",         "Split line at cursor.",                0, {splitLine}},
+  {"splitV",            "Split box in half vertically.",        0, {halveBoxVertically}},
+  {"startOfLine",       "Go to start of line.",                 0, {startOfLine}},
+  {"startOfNLine",      "Go to start of next line.",            0, {viStartOfNextLine}},
+  {"switchBoxes",       "Switch to another box.",               0, {switchBoxes}},
+  {"upLine",            "Move cursor up one line.",             0, {upLine}},
+  {"upPage",            "Move cursor up one page.",             0, {upPage}},
+  {NULL, NULL, 0, {NULL}}
+};
+
+struct keyCommand simpleViNormalKeys[] =
+{
+  {"BS",        "leftChar"},
+  {"X",         "backSpaceChar"},
+  {"Del",       "deleteChar"},
+  {"x",         "deleteChar"},
+  {"Down",      "downLine"},
+  {"j",         "downLine"},
+  {"End",       "endOfLine"},
+  {"Home",      "startOfLine"},
+  {"Left",      "leftChar"},
+  {"h",         "leftChar"},
+  {"PgDn",      "downPage"},
+  {"^F",        "downPage"},
+  {"PgUp",      "upPage"},
+  {"^B",        "upPage"},
+  {"Enter",     "startOfNextLine"},
+  {"Return",    "startOfNextLine"},
+  {"Right",     "rightChar"},
+  {"l",         "rightChar"},
+  {"i",         "insert"},
+  {":",         "exMode"},      // This is the temporary ex mode that you can backspace out of.  Or any command backs you out.
+  {"Q",         "exMode"},      // This is the ex mode you need to do the "visual" command to get out of.
+  {"^Wv",       "splitV"},
+  {"^W^V",      "splitV"},
+  {"^Ws",       "splitH"},
+  {"^WS",       "splitH"},
+  {"^W^S",      "splitH"},
+  {"^Ww",       "switchBoxes"},
+  {"^W^W",      "switchBoxes"},
+  {"^Wq",       "deleteBox"},
+  {"^W^Q",      "deleteBox"},
+  {"Up",        "upLine"},
+  {"k",         "upLine"},
+  {NULL, NULL}
+};
+
+struct keyCommand simpleViInsertKeys[] =
+{
+  {"BS",        "backSpaceChar"},
+  {"Del",       "deleteChar"},
+  {"Return",    "splitLine"},
+  {"Esc",       "visual"},
+  {"^C",        "visual"},
+  {NULL, NULL}
+};
+
+struct keyCommand simpleExKeys[] =
+{
+  {"BS",        "backSpaceChar"},
+  {"Del",       "deleteChar"},
+  {"Down",      "downLine"},
+  {"End",       "endOfLine"},
+  {"Home",      "startOfLine"},
+  {"Left",      "leftChar"},
+  {"Enter",     "executeLine"},
+  {"Return",    "executeLine"},
+  {"Right",     "rightChar"},
+  {"Esc",       "visual"},
+  {"Up",        "upLine"},
+  {NULL, NULL}
+};
+
+struct mode simpleViMode[] =
+{
+  {simpleViNormalKeys, NULL, NULL, 0},
+  {simpleViInsertKeys, NULL, NULL, 0},
+  {simpleExKeys, NULL, NULL, 1},
+  {NULL, NULL, NULL}
+};
+
+struct context simpleVi =
+{
+  simpleViCommands,
+  simpleViMode,
+  NULL,
+  NULL,
+  NULL
+};
+
+
+// TODO - simple sed editor?  May be out of scope for "simple", so leave it until later?
+// Probably entirely useless for "simple".
+
+
+// TODO - have any unrecognised escape key sequence start up a new box (split one) to show the "show keys" content.
+// That just adds each "Key is X" to the end of the content, and allows scrolling, as well as switching between other boxes.
+
+void boxes_main(void)
+{
+  struct context *context = &simpleMcedit;  // The default is mcedit, coz that's what I use.
+  struct termios termio, oldtermio;
+  char *prompt = "Enter a command : ";
+  unsigned W = 80, H = 24;
+
+  // For testing purposes, figure out which context we use.  When this gets real, the toybox multiplexer will sort this out for us instead.
+  if (toys.optflags & FLAG_m)
+  {
+    if (strcmp(TT.mode, "emacs") == 0)
+      context = &simpleEmacs;
+    else if (strcmp(TT.mode, "joe") == 0)
+      context = &simpleJoe;
+    else if (strcmp(TT.mode, "less") == 0)
+      context = &simpleLess;
+    else if (strcmp(TT.mode, "mcedit") == 0)
+      context = &simpleMcedit;
+    else if (strcmp(TT.mode, "more") == 0)
+      context = &simpleMore;
+    else if (strcmp(TT.mode, "nano") == 0)
+      context = &simpleNano;
+    else if (strcmp(TT.mode, "vi") == 0)
+      context = &simpleVi;
+  }
+
+  // TODO - Should do an isatty() here, though not sure about the usefullness of driving this from a script or redirected input, since it's supposed to be a UI for terminals.
+  //          It would STILL need the terminal size for output though.  Perhaps just bitch and abort if it's not a tty?
+  //          On the other hand, sed don't need no stinkin' UI.  And things like more or less should be usable on the end of a pipe.
+
+  // Grab the old terminal settings and save it.
+  tcgetattr(0, &oldtermio);
+  tcflush(0, TCIFLUSH);
+  termio = oldtermio;
+
+  // Mould the terminal to our will.
+  /*
+    IUCLC       (not in POSIX) Map uppercase characters to lowercase on input.
+    IXON        Enable XON/XOFF flow control on output.
+    IXOFF       Enable XON/XOFF flow control on input.
+    IXANY       (not in POSIX.1; XSI) Enable any character to restart output.
+
+    ECHO        Echo input characters.
+    ECHOE       If ICANON is also set, the ERASE character erases the preceding input character, and WERASE erases the preceding word.
+    ECHOK       If ICANON is also set, the KILL character erases the current line. 
+    ECHONL      If ICANON is also set, echo the NL character even if ECHO is not set. 
+    TOSTOP      Send the SIGTTOU signal to the process group of a background process which tries to write to its controlling terminal.
+    ICANON      Enable canonical mode. This enables the special characters EOF, EOL, EOL2, ERASE, KILL, LNEXT, REPRINT, STATUS, and WERASE, and buffers by lines.
+
+    VTIME       Timeout in deciseconds for non-canonical read.
+    VMIN        Minimum number of characters for non-canonical read.
+
+    raw mode  turning off ICANON, IEXTEN, and ISIG kills most special key processing.
+       termio.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON);
+       termio.c_oflag &= ~OPOST;
+       termio.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
+       termio.c_cflag &= ~(CSIZE | PARENB);
+       termio.c_cflag |= CS8;
+
+    IGNBRK      ignore BREAK
+    BRKINT      complicated, bet in this context, sends BREAK as '\x00'
+    PARMRK      characters with parity or frame erors are sent as '\x00'
+    ISTRIP      strip 8th byte
+    INLCR       translate LF to CR in input
+    IGLCR       ignore CR
+    OPOST       enable implementation defined output processing
+    ISIG        generate signals on INTR (SIGINT on ^C), QUIT (SIGQUIT on ^\\), SUSP (SIGTSTP on ^Z), DSUSP (SIGTSTP on ^Y)
+    IEXTEN      enable implementation defined input processing, turns on some key -> signal -tuff
+    CSIZE       mask for character sizes, so in this case, we mask them all out
+    PARENB      enable parity
+    CS8         8 bit characters
+
+    VEOF        "sends" EOF on ^D, ICANON turns that on.
+    VSTART      restart output on ^Q, IXON turns that on.
+    VSTATUS     display status info and sends SIGINFO (STATUS) on ^T.  Not in POSIX, not supported in Linux.  ICANON turns that on.
+    VSTOP       stop output on ^S, IXON turns that on.
+  */
+  termio.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IUCLC | IXON | IXOFF | IXANY);
+  termio.c_oflag &= ~OPOST;
+  termio.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL | TOSTOP | ICANON | ISIG | IEXTEN);
+  termio.c_cflag &= ~(CSIZE | PARENB);
+  termio.c_cflag |= CS8;
+  termio.c_cc[VTIME]=0;  // deciseconds.
+  termio.c_cc[VMIN]=1;
+  tcsetattr(0, TCSANOW, &termio);
+
+  terminal_size(&W, &H);
+  if (toys.optflags & FLAG_w)
+    W = TT.w;
+  if (toys.optflags & FLAG_h)
+    H = TT.h;
+
+  // Create the main box.  Right now the system needs one for wrapping around while switching.  The H - 1 bit is to leave room for our example command line.
+  rootBox = addBox("root", context, toys.optargs[0], 0, 0, W, H - 1);
+  currentBox = rootBox;
+
+  // Create the command line view, sharing the same context as the root.  It will differentiate based on the view mode of the current box.
+  // Also load the command line history as it's file.
+  // TODO - different contexts will have different history files, though what to do about ones with no history, and ones with different histories for different modes?
+  commandLine = addView("command", rootBox->view->content->context, ".boxes.history", 0, H, W, 1);
+  // Add a prompt to it.
+  commandLine->prompt = xrealloc(commandLine->prompt, strlen(prompt) + 1);
+  strcpy(commandLine->prompt, prompt);
+  // Move to the end of the history.
+  moveCursorAbsolute(commandLine, 0, commandLine->content->lines.length, 0, 0);
+
+  // All the mouse tracking methods suck one way or another.  sigh
+  // http://rtfm.etla.org/xterm/ctlseq.html documents xterm stuff, near the bottom is the mouse stuff.
+  // http://leonerds-code.blogspot.co.uk/2012/04/wide-mouse-support-in-libvterm.html is helpful.
+  // Enable mouse (VT200 normal tracking mode, UTF8 encoding).  The limit is 2015.  Seems to only be in later xterms.
+//  fputs("\x1B[?1005h", stdout);
+  // Enable mouse (VT340 locator reporting mode).  In theory has no limit.  Wont actually work though.
+  // On the other hand, only allows for four buttons, so only half a mouse wheel.
+  // Responds with "\1B[e;p;r;c;p&w" where e is event type, p is a bitmap of buttons pressed, r and c are the mouse coords in decimal, and p is the "page number".
+//  fputs("\x1B[1;2'z\x1B[1;3'{", stdout);
+  // Enable mouse (VT200 normal tracking mode).  Has a limit of 256 - 32 rows and columns.  An xterm exclusive I think, but works in roxterm at least.  No wheel reports.
+  // Responds with "\x1B[Mbxy" where x and y are the mouse coords, and b is bit encoded buttons and modifiers - 0=MB1 pressed, 1=MB2 pressed, 2=MB3 pressed, 3=release, 4=Shift, 8=Meta, 16=Control
+//  fputs("\x1B[?1000h", stdout);
+//  fflush(stdout);
+
+  calcBoxes(currentBox);
+  drawBoxes(currentBox);
+  // Do the first cursor update.
+  updateLine(currentBox->view);
+
+  // Run the main loop.
+  handle_keys((long) currentBox->view, handleEvent);
+
+  // TODO - Should remember to turn off mouse reporting when we leave.
+
+  // Restore the old terminal settings.
+  tcsetattr(0, TCSANOW, &oldtermio);
+
+  puts("");
+  fflush(stdout);
+}
diff --git a/src/boxes/dumbsh.c b/src/boxes/dumbsh.c
new file mode 100644
index 0000000..9ad0204
--- /dev/null
+++ b/src/boxes/dumbsh.c
@@ -0,0 +1,283 @@
+/* dumbsh.c - A really dumb shell, to demonstrate handle_keys usage.
+ *
+ * Copyright 2014 David Seikel <won_fang@yahoo.com.au>
+ *
+ * Not a real shell, so doesn't follow any standards,
+ * coz it wont implement them anyway.
+
+USE_DUMBSH(NEWTOY(dumbsh, "", TOYFLAG_USR|TOYFLAG_BIN))
+
+config DUMBSH
+  bool "dumbsh"
+  default n
+  help
+    usage: dumbsh
+
+    A really dumb shell.
+*/
+
+#include "toys.h"
+#include "lib/handlekeys.h"
+
+typedef void (*eventHandler) (void);
+
+struct keyCommand
+{
+  char *key;
+  eventHandler handler;
+};
+
+GLOBALS(
+  unsigned h, w;
+  int x, y;
+  struct double_list *history;
+)
+
+#define TT this.dumbsh
+
+// Sanity check cursor location and update the current line.
+static void updateLine()
+{
+  if (0 > TT.x)  TT.x = 0;
+  if (0 > TT.y)  TT.y = 0;
+  if (TT.w < TT.x)  TT.x = TT.w;
+  if (TT.h < TT.y)  TT.y = TT.h;
+  if (strlen(toybuf) < TT.x)  TT.x = strlen(toybuf);
+  printf("\x1B[%d;0H%-*s\x1B[%d;%dH",
+    TT.y + 1, TT.w, toybuf, TT.y + 1, TT.x + 1);
+  fflush(stdout);
+}
+
+// The various commands.
+static void deleteChar()
+{
+  int j;
+
+  for (j = TT.x; toybuf[j]; j++)
+    toybuf[j] = toybuf[j + 1];
+  updateLine();
+}
+
+static void backSpaceChar()
+{
+  if (TT.x)
+  {
+    TT.x--;
+    deleteChar();
+  }
+}
+
+// This is where we would actually deal with 
+// what ever command the user had typed in.
+// For now we just move on to the next line.
+// TODO - We would want to redirect I/O, capture some keys (^C),
+//        but pass the rest on.
+//        Dunno yet how to deal with that.
+//        We still want handle_keys to be doing it's thing,
+//        so maybe handing it another fd, and a callback.
+//        A function to add and remove fd and callback pairs for
+//        handle_keys to check?
+static void doCommand()
+{
+  toybuf[0] = 0;
+  TT.x = 0;
+  TT.y++;
+  printf("\n");
+  fflush(stdout);
+  updateLine();
+}
+
+static void endOfLine()
+{
+  TT.x = strlen(toybuf);
+  updateLine();
+}
+
+static void leftChar()
+{
+  TT.x--;
+  updateLine();
+}
+
+static void nextHistory()
+{
+  TT.history = TT.history->next;
+  strcpy(toybuf, TT.history->data);
+  TT.x = strlen(toybuf);
+  updateLine();
+}
+
+static void prevHistory()
+{
+  TT.history = TT.history->prev;
+  strcpy(toybuf, TT.history->data);
+  TT.x = strlen(toybuf);
+  updateLine();
+}
+
+static void quit()
+{
+  handle_keys_quit();
+}
+
+static void rightChar()
+{
+  TT.x++;
+  updateLine();
+}
+
+static void startOfLine()
+{
+  TT.x = 0;
+  updateLine();
+}
+
+// The key to command mappings, Emacs style.
+static const struct keyCommand simpleEmacsKeys[] =
+{
+  {"BS",        backSpaceChar},
+  {"Del",       deleteChar},
+  {"^D",        deleteChar},
+  {"Return",    doCommand},
+  {"Enter",     doCommand},
+  {"Down",      nextHistory},
+  {"^N",        nextHistory},
+  {"End",       endOfLine},
+  {"^E",        endOfLine},
+  {"Left",      leftChar},
+  {"^B",        leftChar},
+  {"^X^C",      quit},
+  {"^C",        quit},
+  {"Right",     rightChar},
+  {"^F",        rightChar},
+  {"Home",      startOfLine},
+  {"^A",        startOfLine},
+  {"Up",        prevHistory},
+  {"^P",        prevHistory}
+};
+
+// Callback for incoming sequences from the terminal.
+static int handleEvent(long extra, struct keyevent *event)
+{
+  switch (event->type)
+  {
+    case HK_KEYS :
+    {
+      int j, l = strlen(event->sequence);
+
+      // Search for a key sequence bound to a command.
+      for (j = 0; j < ARRAY_LEN(simpleEmacsKeys); j++)
+      {
+        if (strncmp(simpleEmacsKeys[j].key, event->sequence, l) == 0)
+        {
+          // If it's a partial match, keep accumulating them.
+          if (strlen(simpleEmacsKeys[j].key) != l)
+            return 0;
+          else
+          {
+            if (simpleEmacsKeys[j].handler)  simpleEmacsKeys[j].handler();
+            return 1;
+          }
+        }
+      }
+
+      // See if it's ordinary keys.
+      // NOTE - with vi style ordinary keys can be commands,
+      // but they would be found by the command check above first.
+      if (!event->isTranslated)
+      {
+        if (TT.x < sizeof(toybuf))
+        {
+          int j, l = strlen(event->sequence);
+
+          for (j = strlen(toybuf); j >= TT.x; j--)
+            toybuf[j + l] = toybuf[j];
+          for (j = 0; j < l; j++)
+            toybuf[TT.x + j] = event->sequence[j];
+          TT.x += l;
+          updateLine();
+        }
+      }
+      break;
+    }
+
+    case HK_CSI :
+    {
+      // Is it a cursor location report?
+      if (strcmp("R", event->sequence) == 0)
+      {
+        // Parameters are cursor line and column.
+        // NOTE - This may be sent at other times, not just during terminal resize.
+        //        We are assuming here that it's a resize.
+        // The defaults are 1, which get ignored by the heuristic below.
+        int r = event->params[0], c = event->params[1];
+
+        // Check it's not an F3 key variation, coz some of them use 
+        // the same CSI function command.
+        // This is a heuristic, we are checking against an unusable terminal size.
+        if ((2 == event->count) && (8 < r) && (8 < c))
+        {
+          TT.h = r;
+          TT.w = c;
+          updateLine();
+        }
+        break;
+      }
+    }
+
+    default :  break;
+  }
+
+  // Tell handle_keys to drop it, coz we dealt with it, or it's not one of ours.
+  return 1;
+}
+
+void dumbsh_main(void)
+{
+  struct termios termIo, oldTermIo;
+  char *t = getenv("HOME");
+  int fd;
+
+  // Load bash history.
+  t = xmprintf("%s/%s", t ? t : "", ".bash_history");
+  if (-1 != (fd = open(t, O_RDONLY)))
+  {
+    while ((t = get_line(fd)))  TT.history = dlist_add(&TT.history, t);
+    close(fd);
+  }
+  if (!TT.history)
+    TT.history = dlist_add(&TT.history, "");
+
+  // Grab the old terminal settings and save it.
+  tcgetattr(0, &oldTermIo);
+  tcflush(0, TCIFLUSH);
+  termIo = oldTermIo;
+
+  // Mould the terminal to our will.
+  // In this example we are turning off all the terminal smarts, but real code
+  // might not want that.
+  termIo.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL
+                     | IUCLC | IXON | IXOFF | IXANY);
+  termIo.c_oflag &= ~OPOST;
+  termIo.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL | TOSTOP | ICANON | ISIG
+                     | IEXTEN);
+  termIo.c_cflag &= ~(CSIZE | PARENB);
+  termIo.c_cflag |= CS8;
+  termIo.c_cc[VTIME]=0;  // deciseconds.
+  termIo.c_cc[VMIN]=1;
+  tcsetattr(0, TCSANOW, &termIo);
+
+  // Let the mouldy old terminal mold us.
+  TT.w = 80;
+  TT.h = 24;
+  terminal_size(&TT.w, &TT.h);
+
+  // Let's rock!
+  updateLine();
+  handle_keys(0, handleEvent);
+
+  // Clean up.
+  tcsetattr(0, TCSANOW, &oldTermIo);
+  puts("");
+  fflush(stdout);
+}
diff --git a/src/boxes/handlekeys.c b/src/boxes/handlekeys.c
new file mode 100644
index 0000000..8bae529
--- /dev/null
+++ b/src/boxes/handlekeys.c
@@ -0,0 +1,445 @@
+/* handlekeys.c - Generic terminal input handler.
+ *
+ * Copyright 2012 David Seikel <won_fang@yahoo.com.au>
+ */
+
+// I use camelCaseNames internally, instead of underscore_names as is preferred
+// in the rest of toybox.  A small limit of 80 characters per source line infers
+// shorter names should be used.  CamelCaseNames are shorter.  Externally visible
+// stuff is underscore_names as usual.  Plus, I'm used to camelCaseNames, my
+// fingers twitch that way.
+
+#include "toys.h"
+#include "handlekeys.h"
+
+struct key
+{
+  char *code;
+  char *name;
+};
+
+// This table includes some variations I have found on some terminals.
+// http://rtfm.etla.org/xterm/ctlseq.html has a useful guide.
+// TODO - Don't think I got all the linux console or xterm variations.
+// TODO - Add more shift variations, plus Ctrl & Alt variations when needed.
+// TODO - tmux messes with the shift function keys somehow.
+// TODO - Add other miscelany that does not use an escape sequence.
+
+// This is sorted by type, though there is some overlap.
+// Human typing speeds wont need fast searching speeds on this small table.
+// So simple wins out over speed, and sorting by terminal type wins
+// the simple test.
+static struct key keys[] =
+{
+  // Control characters.
+  //  Commented out coz it's the C string terminator, and may confuse things.
+  //{"\x00",            "^@"},          // NUL
+  {"\x01",              "^A"},          // SOH Apparently sometimes sent as Home.
+  {"\x02",              "^B"},          // STX
+  {"\x03",              "^C"},          // ETX SIGINT  Emacs and vi.
+  {"\x04",              "^D"},          // EOT EOF     Emacs, joe, and nano.
+  {"\x05",              "^E"},          // ENQ Apparently sometimes sent as End
+  {"\x06",              "^F"},          // ACK
+  {"\x07",              "^G"},          // BEL
+  {"\x08",              "Del"},         // BS  Delete key, usually.
+  {"\x09",              "Tab"},         // HT
+  {"\x0A",              "Enter"},       // LF  Roxterm translates Ctrl-M to this.
+  {"\x0B",              "^K"},          // VT
+  {"\x0C",              "^L"},          // FF
+  {"\x0D",              "Return"},      // CR  Other Enter/Return key, usually.
+  {"\x0E",              "^N"},          // SO
+  {"\x0F",              "^O"},          // SI  DISCARD
+  {"\x10",              "^P"},          // DLE
+  {"\x11",              "^Q"},          // DC1 SIGCONT  Vi.
+  {"\x12",              "^R"},          // DC2
+  {"\x13",              "^S"},          // DC3 SIGSTOP can't be caught.  Emacs and vi.
+  {"\x14",              "^T"},          // DC4 SIGINFO STATUS
+  {"\x15",              "^U"},          // NAK KILL character
+  {"\x16",              "^V"},          // SYN LNEXT
+  {"\x17",              "^W"},          // ETB WERASE
+  {"\x18",              "^X"},          // CAN KILL character
+  {"\x19",              "^Y"},          // EM  DSUSP SIGTSTP
+  {"\x1A",              "^Z"},          // SUB SIGTSTP
+  // Commented out coz it's the ANSI start byte in the below multibyte keys.
+  // Handled in the code with a timeout.
+  //{"\x1B",            "Esc"},         // ESC Esc key.
+  {"\x1C",              "^\\"},         // FS SIGQUIT
+  {"\x1D",              "^]"},          // GS
+  {"\x1E",              "^^"},          // RS
+  {"\x1F",              "^_"},          // US
+  {"\x7F",              "BS"},          // Backspace key, usually.  Ctrl-? perhaps?
+  // Commented out for the same reason Esc is.
+  //{"\x9B",            "CSI"},         // CSI The eight bit encoding of "Esc [".
+
+  // "Usual" xterm CSI sequences, with ";1" omitted for no modifiers.
+  // Even though we have a proper CSI parser,
+  // these should still be in this table.  Coz we would need a table anyway
+  // in the CSI parser, so might as well keep them with the others.
+  // Also, less code, no need to have a separate scanner for that other table.
+  {"\x9B\x31~",         "Home"},        // Duplicate, think I've seen this somewhere.
+  {"\x9B\x32~",         "Ins"},
+  {"\x9B\x33~",         "Del"},
+  {"\x9B\x34~",         "End"},         // Duplicate, think I've seen this somewhere.
+  {"\x9B\x35~",         "PgUp"},
+  {"\x9B\x36~",         "PgDn"},
+  {"\x9B\x37~",         "Home"},
+  {"\x9B\x38~",         "End"},
+  {"\x9B\x31\x31~",             "F1"},
+  {"\x9B\x31\x32~",             "F2"},
+  {"\x9B\x31\x33~",             "F3"},
+  {"\x9B\x31\x34~",             "F4"},
+  {"\x9B\x31\x35~",             "F5"},
+  {"\x9B\x31\x37~",             "F6"},
+  {"\x9B\x31\x38~",             "F7"},
+  {"\x9B\x31\x39~",             "F8"},
+  {"\x9B\x32\x30~",             "F9"},
+  {"\x9B\x32\x31~",             "F10"},
+  {"\x9B\x32\x33~",             "F11"},
+  {"\x9B\x32\x34~",             "F12"},
+
+  // As above, ";2" means shift modifier.
+  {"\x9B\x31;2~",               "Shift Home"},
+  {"\x9B\x32;2~",               "Shift Ins"},
+  {"\x9B\x33;2~",               "Shift Del"},
+  {"\x9B\x34;2~",               "Shift End"},
+  {"\x9B\x35;2~",               "Shift PgUp"},
+  {"\x9B\x36;2~",               "Shift PgDn"},
+  {"\x9B\x37;2~",               "Shift Home"},
+  {"\x9B\x38;2~",               "Shift End"},
+  {"\x9B\x31\x31;2~",   "Shift F1"},
+  {"\x9B\x31\x32;2~",   "Shift F2"},
+  {"\x9B\x31\x33;2~",   "Shift F3"},
+  {"\x9B\x31\x34;2~",   "Shift F4"},
+  {"\x9B\x31\x35;2~",   "Shift F5"},
+  {"\x9B\x31\x37;2~",   "Shift F6"},
+  {"\x9B\x31\x38;2~",   "Shift F7"},
+  {"\x9B\x31\x39;2~",   "Shift F8"},
+  {"\x9B\x32\x30;2~",   "Shift F9"},
+  {"\x9B\x32\x31;2~",   "Shift F10"},
+  {"\x9B\x32\x33;2~",   "Shift F11"},
+  {"\x9B\x32\x34;2~",   "Shift F12"},
+
+  // "Normal" Some terminals are special, and it seems they only have
+  //  four function keys.
+  {"\x9B\x41",          "Up"},
+  {"\x9B\x42",          "Down"},
+  {"\x9B\x43",          "Right"},
+  {"\x9B\x44",          "Left"},
+  {"\x9B\x46",          "End"},
+  {"\x9BH",             "Home"},
+  {"\x9BP",             "F1"},
+  {"\x9BQ",             "F2"},
+  {"\x9BR",             "F3"},
+  {"\x9BS",             "F4"},
+  {"\x9B\x31;2P",               "Shift F1"},
+  {"\x9B\x31;2Q",               "Shift F2"},
+  {"\x9B\x31;2R",               "Shift F3"},
+  {"\x9B\x31;2S",               "Shift F4"},
+
+  // "Application"  Esc O is known as SS3
+  {"\x1BOA",            "Up"},
+  {"\x1BOB",            "Down"},
+  {"\x1BOC",            "Right"},
+  {"\x1BOD",            "Left"},
+  {"\x1BOF",            "End"},
+  {"\x1BOH",            "Home"},
+  {"\x1BOn",            "Del"},
+  {"\x1BOp",            "Ins"},
+  {"\x1BOq",            "End"},
+  {"\x1BOw",            "Home"},
+  {"\x1BOP",            "F1"},
+  {"\x1BOQ",            "F2"},
+  {"\x1BOR",            "F3"},
+  {"\x1BOS",            "F4"},
+  {"\x1BOT",            "F5"},
+  // These two conflict with the above four function key variations.
+  {"\x9BR",             "F6"},
+  {"\x9BS",             "F7"},
+  {"\x9BT",             "F8"},
+  {"\x9BU",             "F9"},
+  {"\x9BV",             "F10"},
+  {"\x9BW",             "F11"},
+  {"\x9BX",             "F12"},
+
+  // Can't remember, but saw them somewhere.
+  {"\x1BO1;2P",         "Shift F1"},
+  {"\x1BO1;2Q",         "Shift F2"},
+  {"\x1BO1;2R",         "Shift F3"},
+  {"\x1BO1;2S",         "Shift F4"},
+};
+
+static volatile sig_atomic_t sigWinch;
+static int stillRunning;
+
+static void handleSIGWINCH(int signalNumber)
+{
+    sigWinch = 1;
+}
+
+void handle_keys(long extra, int (*handle_event)(long extra, struct keyevent *event))
+{
+  struct keyevent event;
+  fd_set selectFds;
+  struct timespec timeOut;
+  struct sigaction sigAction, oldSigAction;
+  sigset_t signalMask;
+  char buffer[20], sequence[20];
+  int buffIndex = 0, pendingEsc = 0;
+
+  buffer[0] = 0;
+  sequence[0] = 0;
+
+  // Terminals send the SIGWINCH signal when they resize.
+  memset(&sigAction, 0, sizeof(sigAction));
+  sigAction.sa_handler = handleSIGWINCH;
+  sigAction.sa_flags = SA_RESTART;  // Useless if we are using poll.
+  if (sigaction(SIGWINCH, &sigAction, &oldSigAction))
+    perror_exit("can't set signal handler for SIGWINCH");
+  sigemptyset(&signalMask);
+  sigaddset(&signalMask, SIGWINCH);
+
+  // TODO - OS buffered keys might be a problem, but we can't do the
+  // usual timestamp filter for now.
+
+  stillRunning = 1;
+  while (stillRunning)
+  {
+    int j, p, csi = 0;
+
+    // Apparently it's more portable to reset these each time.
+    FD_ZERO(&selectFds);
+    FD_SET(0, &selectFds);
+    timeOut.tv_sec = 0;  timeOut.tv_nsec = 100000000; // One tenth of a second.
+
+    // We got a "terminal size changed" signal, ask the terminal
+    // how big it is now.
+    if (sigWinch)
+    {
+      // Send - save cursor position, down 999, right 999,
+      // request cursor position, restore cursor position.
+      fputs("\x1B[s\x1B[999C\x1B[999B\x1B[6n\x1B[u", stdout);
+      fflush(stdout);
+      sigWinch = 0;
+    }
+
+    // TODO - Should only ask for a time out after we get an Escape, or
+    //        the user requested time ticks.
+    // I wanted to use poll, but that would mean using ppoll, which is
+    // Linux only, and involves defining swear words to get it.
+    p = pselect(0 + 1, &selectFds, NULL, NULL, &timeOut, &signalMask);
+    if (0 > p)
+    {
+      if (EINTR == errno)
+        continue;
+      perror_exit("poll");
+    }
+    else if (0 == p)  // A timeout, trigger a time event.
+    {
+      if (pendingEsc)
+      {
+        // After a short delay to check, this is a real Escape key,
+        // not part of an escape sequence, so deal with it.
+        strcat(sequence, "Esc");
+        buffer[0] = buffIndex = 0;
+      }
+      // TODO - Call some sort of timer tick callback.  This wont be
+      //        a precise timed event, but don't think we need one.
+    }
+    else if ((0 < p) && FD_ISSET(0, &selectFds))
+    {
+      j = xread(0, &buffer[buffIndex], sizeof(buffer) - (buffIndex + 1));
+      if (j == 0)    // End of file.
+        stillRunning = 0;
+      else
+      {
+        buffIndex += j;
+        buffer[buffIndex] = 0;
+
+        // Send raw keystrokes, mostly for things like showkey.
+        event.type = HK_RAW;
+        event.sequence = buffer;
+        event.isTranslated = 0;
+        handle_event(extra, &event);
+
+        if (sizeof(buffer) < (buffIndex + 1))  // Ran out of buffer.
+        {
+          buffer[buffIndex] = 0;
+          fprintf(stderr, "Full buffer - %s  ->  %s\n", buffer, sequence);
+          for (j = 0; buffer[j]; j++)
+            fprintf(stderr, "(%x) %c, ", (int) buffer[j], buffer[j]);
+          fflush(stderr);
+          buffer[0] = buffIndex = 0;
+        }
+      }
+    }
+
+    // Check for lone Esc first, wait a bit longer if it is.
+    pendingEsc = ((0 == buffer[1]) && ('\x1B' == buffer[0]));
+    if (pendingEsc)  continue;
+
+    // Check if it's a CSI before we check for the known key sequences.
+    // C29B is the UTF8 encoding of CSI.
+    // In all cases we reduce CSI to 9B to keep the keys table shorter.
+    if ((('\x1B' == buffer[0]) && ('[' == buffer[1]))
+      || (('\xC2' == buffer[0]) && ('\x9B' == buffer[1])))
+    {
+      buffer[0] = '\x9B';
+      for (j = 1; buffer[j]; j++)
+        buffer[j] = buffer[j + 1];
+      buffIndex--;
+    }
+    csi = ('\x9B' == buffer[0]);
+
+    // Check for known key sequences.
+    // For a real timeout checked Esc, buffer is now empty, so this for loop
+    // wont find it anyway.  While it's true we could avoid it by checking,
+    // the user already had to wait for a time out, and this loop wont take THAT long.
+    for (j = 0; j < ARRAY_LEN(keys); j++)
+    {
+      if (strcmp(keys[j].code, buffer) == 0)
+      {
+        strcat(sequence, keys[j].name);
+        buffer[0] = buffIndex = 0;
+        csi = 0;
+        break;
+      }
+    }
+
+    // Find out if it's a CSI sequence that's not in the known key sequences.
+    if (csi)
+    {
+      /* ECMA-048 section 5.2 defines this, and is unreadable.
+       * So I'll include some notes here that tries to simplify that.
+       *
+       * The CSI format is - CSI [private] n1 ; n2 [extra] final
+       * Each of those parts, except for the initial CSI bytes, is an ordinary
+       * ASCII character.
+       *
+       * The optional [private] part is one of these characters "<=>?".
+       * If the first byte is one of these, then this is a private command, if
+       * it's one of the other n1 ones, it's not private.
+       *
+       * Next is a semi colon separated list of parameters (n1, n2, etc), which
+       * can be any characters from this set "01234567890:;<=>?".  What the non
+       * digit ones mean is up to the command.  Parameters can be left out, but
+       * their defaults are command dependant.
+       *
+       * Next is an optional [extra] part from this set of characters
+       * "!#$%&'()*+,-./", which includes double quotes.  Can be many of these,
+       * likely isn't.
+       *
+       * Finally is the "final" from this set of characters "@[\]^_`{|}~", plus
+       * upper and lower case letters.  It's private if it's one of these 
+       * "pqrstuvwxyz{|}~".  Though the "private" ~ is used for key codes.
+       *
+       * A full CSI command is the private, extra, and final parts.
+       *
+       * Any C0 controls, DEL (0x7f), or higher characters are undefined.
+       * TODO - So abort the current CSI and start from scratch on one of those.
+       */
+
+      if ('M' == buffer[1])
+      {
+        // We have a mouse report, which is CSI M ..., where the rest is
+        // binary encoded, more or less.  Not fitting into the CSI format.
+        // To make things worse, can't tell how long this will be.
+        // So leave it up to the caller to tell us if they used it.
+        event.type = HK_MOUSE;
+        event.sequence = buffer;
+        event.isTranslated = 0;
+        if (handle_event(extra, &event))
+        {
+          buffer[0] = buffIndex = 0;
+          sequence[0] = 0;
+        }
+      }
+      else
+      {
+        char *t, csFinal[8];
+        int csIndex = 1, csParams[8];
+
+        csFinal[0] = 0;
+        p = 0;
+
+        // Unspecified params default to a value that is command dependant.
+        // However, they will never be negative, so we can use -1 to flag
+        // a default value.
+        for (j = 0; j < ARRAY_LEN(csParams); j++)
+          csParams[j] = -1;
+
+        // Check for the private bit.
+        if (index("<=>?", buffer[1]))
+        {
+          csFinal[0] = buffer[1];
+          csFinal[1] = 0;
+          csIndex++;
+        }
+
+        // Decode parameters.
+        j = csIndex;
+        do
+        {
+          // So we know when we get to the end of parameter space.
+          t = index("01234567890:;<=>?", buffer[j + 1]);
+          // See if we passed a paremeter.
+          if ((';' == buffer[j]) || (!t))
+          {
+            // Only stomp on the ; if it's really the ;.
+            if (t)
+              buffer[j] = 0;
+            // Empty parameters are default parameters, so only deal with
+            // non defaults.
+            if (';' != buffer[csIndex] || (!t))
+            {
+              // TODO - Might be ":" in the number somewhere, but we are not
+              // expecting any in anything we do.
+              csParams[p] = atoi(&buffer[csIndex]);
+            }
+            p++;
+            csIndex = j + 1;
+          }
+          j++;
+        }
+        while (t);
+
+        // Check if we got the final byte, and send it to the callback.
+        strcat(csFinal, &buffer[csIndex]);
+        t = csFinal + strlen(csFinal) - 1;
+        if (('\x40' <= (*t)) && ((*t) <= '\x7e'))
+        {
+          event.type = HK_CSI;
+          event.sequence = csFinal;
+          event.isTranslated = 1;
+          event.count = p;
+          event.params = csParams;
+          handle_event(extra, &event);
+          buffer[0] = buffIndex = 0;
+          sequence[0] = 0;
+        }
+      }
+    }
+
+    // Pass the result to the callback.
+    if (sequence[0] || buffer[0])
+    {
+      char b[strlen(sequence) + strlen(buffer) + 1];
+
+      sprintf(b, "%s%s", sequence, buffer);
+      event.type = HK_KEYS;
+      event.sequence = b;
+      event.isTranslated = (0 != sequence[0]);
+      if (handle_event(extra, &event))
+      {
+        buffer[0] = buffIndex = 0;
+        sequence[0] = 0;
+      }
+    }
+  }
+
+  sigaction(SIGWINCH, &oldSigAction, NULL);
+}
+
+void handle_keys_quit()
+{
+  stillRunning = 0;
+}
diff --git a/src/boxes/handlekeys.h b/src/boxes/handlekeys.h
new file mode 100644
index 0000000..868183f
--- /dev/null
+++ b/src/boxes/handlekeys.h
@@ -0,0 +1,76 @@
+/* handlekeys.h - Generic terminal input handler.
+ *
+ * Copyright 2012 David Seikel <won_fang@yahoo.com.au>
+ */
+
+enum keyeventtype{
+  HK_CSI,
+  HK_KEYS,
+  HK_MOUSE,
+  HK_RAW
+};
+
+struct keyevent {
+  enum keyeventtype type;       // The type of this event.
+  char *sequence;               // Either a translated sequence, or raw bytes.
+  int isTranslated;             // Whether or not sequence is translated.
+  int count;                    // Number of entries in params.
+  int *params;                  // For CSI events, the decoded parameters.
+};
+
+/* An input loop that handles keystrokes and terminal CSI commands.
+ *
+ * Reads stdin, trying to translate raw keystrokes into something more readable.
+ * See the keys[] array at the top of handlekeys.c for what byte sequences get
+ * translated into what key names.  See dumbsh.c for an example of usage.
+ * A 0.1 second delay is used to detect the Esc key being pressed, and not Esc
+ * being part of a raw keystroke.
+ *
+ * handle_keys also tries to decode CSI commands that terminals can send.
+ * Some keystrokes are CSI commands, but those are translated as key sequences
+ * instead of CSI commands.
+ *
+ * handle_keys also sets up a SIGWINCH handler to catch terminal resizes,
+ * and sends a request to the terminal to report it's current size when it gets
+ * a SIGWINCH.  This is the main reason for HK_CSI, as those reports are
+ * sent as CSI.  It's still up to the user code to recognise and deal with the
+ * terminal resize response, but at least it's nicely decoded for you.
+ *
+ * Arguments -
+ *  extra           - arbitrary data that gets passed back to the callbacks.
+ *  handle_event    - a callback to handle sequences.
+ *
+ * handle_event is called when a complete sequence has been accumulated.  It is
+ * passed a keyevent structure.  The type member of that structure determines
+ * what sort of event this is.  What's in the rest of the keyevent depends on
+ * the type -
+ *
+ * HK_CSI
+ *   sequence is the fully decoded CSI command, including the private  and intermediate characters.
+ *   isTranslated is 1, since the CSI command has been translated.
+ *   count is the count of translated CSI parameters.
+ *   params is an array of translateted CSI parameters.
+ *   Empty parameters are set to -1, coz -1 parameters are not legal,
+ *   and empty ones should default to something that is command dependant.
+ *
+ * HK_KEYS
+ *  sequence the keystrokes as ASCII, either translated or not.
+ *  isTranslated if 0, then sequence is ordinary keys, otherwise
+ *  sequence is the names of keys, from the keys[] array.
+ *  count and params are not used.
+ *
+ * For HK_KEYS handle_event should return 1 if the sequence has been dealt with,
+ * or ignored.  It should return 0, if handle_keys should keep adding more
+ * translated keystroke sequences on the end, and try again later.
+ * 0 should really only be used if it's a partial match, and we need more
+ * keys in the sequence to make a full match.
+ *
+ * HK_MOUSE
+ *   sequence is the raw bytes of the mouse report.  The rest are not used.
+ *
+ */
+void handle_keys(long extra, int (*handle_event)(long extra, struct keyevent *event));
+
+
+/* Call this when you want handle_keys to return. */
+void handle_keys_quit();
diff --git a/src/boxes/showkey.c b/src/boxes/showkey.c
new file mode 100644
index 0000000..de1f804
--- /dev/null
+++ b/src/boxes/showkey.c
@@ -0,0 +1,149 @@
+/* showkey.c - Shows the keys pressed.
+ *
+ * Copyright 2014 David Seikel <won_fang@yahoo.com.au>
+ *
+ * Not actually a standard, seems to be three different versions.
+ * The original kbd - http://kbd-project.org/
+ * The kbd fork console-tools - http://lct.sourceforge.net/
+ * A utility invented by Eric S. Raymond - http://catb.org/esr/showkey/
+
+USE_SHOWKEY(NEWTOY(showkey, "", TOYFLAG_USR|TOYFLAG_BIN))
+
+config SHOWKEY
+  bool "showkey"
+  default n
+  help
+    usage: showkey
+
+    Shows the keys pressed.
+*/
+
+#include "toys.h"
+#include "lib/handlekeys.h"
+
+typedef void (*eventHandler) (void);
+
+struct keyCommand
+{
+  char *key;
+  eventHandler handler;
+};
+
+GLOBALS(
+  unsigned h, w;
+  int x, y;
+)
+
+#define TT this.showkey
+
+
+static void quit()
+{
+  printf("Quitting.\r\n");
+  handle_keys_quit();
+}
+
+// The key to command mappings.
+static struct keyCommand simpleKeys[] =
+{
+  {"^C",        quit}
+};
+
+// Callback for incoming sequences from the terminal.
+static int handleEvent(long extra, struct keyevent *event)
+{
+  int i;
+
+  switch (event->type)
+  {
+    case HK_RAW :
+    {
+      printf("RAW ");
+      for (i = 0; event->sequence[i]; i++)
+      {
+        printf("(%x) ", (int) event->sequence[i]);
+        if (32 > event->sequence[i])
+          printf("^%c, ", (int) event->sequence[i] + 'A' - 1);
+        else
+          printf("%c, ", (int) event->sequence[i]);
+      }
+      printf("-> ");
+      break;
+    }
+
+    case HK_KEYS :
+    {
+      int l = strlen(event->sequence);
+
+      if (event->isTranslated)
+        printf("TRANSLATED - ");
+      else
+        printf("KEY - ");
+      printf("%s\r\n", event->sequence);
+
+      // Search for a key sequence bound to a command.
+      for (i = 0; i < ARRAY_LEN(simpleKeys); i++)
+      {
+        if (strncmp(simpleKeys[i].key, event->sequence, l) == 0)
+        {
+          // If it's a partial match, keep accumulating them.
+          if (strlen(simpleKeys[i].key) != l)
+            return 0;
+          else
+            if (simpleKeys[i].handler)  simpleKeys[i].handler();
+        }
+      }
+      break;
+    }
+
+    case HK_CSI :
+    {
+      // Is it a cursor location report?
+      if (strcmp("R", event->sequence) == 0)
+      {
+        printf("CSI cursor position - line %d, column %d\r\n", event->params[0], event->params[1]);
+        return 1;
+      }
+
+      printf("CSI command %s - ", event->sequence);
+      for (i = 0; i < event->count; i++)
+        printf("%d ", event->params[i]);
+      printf("\r\n");
+      break;
+    }
+
+    default :  break;
+  }
+
+  return 1;
+}
+
+void showkey_main(void)
+{
+  struct termios termIo, oldTermIo;
+
+  // Grab the old terminal settings and save it.
+  tcgetattr(0, &oldTermIo);
+  tcflush(0, TCIFLUSH);
+  termIo = oldTermIo;
+
+  // Mould the terminal to our will.
+  // In this example we are turning off all the terminal smarts, but real code
+  // might not want that.
+  termIo.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL
+                     | IUCLC | IXON | IXOFF | IXANY);
+  termIo.c_oflag &= ~OPOST;
+  termIo.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL | TOSTOP | ICANON | ISIG
+                     | IEXTEN);
+  termIo.c_cflag &= ~(CSIZE | PARENB);
+  termIo.c_cflag |= CS8;
+  termIo.c_cc[VTIME]=0;  // deciseconds.
+  termIo.c_cc[VMIN]=1;
+  tcsetattr(0, TCSANOW, &termIo);
+
+  handle_keys(0, handleEvent);
+
+  tcsetattr(0, TCSANOW, &oldTermIo);
+  puts("");
+  fflush(stdout);
+}