On Fri, 25 Nov 2011 13:17:05 -0600 Rob Landley <[email protected]> wrote:
> On 11/22/2011 11:31 AM, David Seikel wrote: > >> When I do an editor I want to make the keybindings flexible enough > >> that it can do vi, nano, microemacs, and ye olde wordstar > >> keybindings (ala joe, turbo C, and so on) from the same engine. > >> (I want a _C_ programming framework for manipulating a text > >> buffer.) > > > > That's exactly what I'm talking about. B-) > > Woot! > > But I'm focusing on vi first because SUSv4 is the only publicly > available standard I've found (so far) that's worth following for this > sort of thing. > > >>> I'd also want to eventually add a very simple > >>> version of midnight commander (mc). > >> > >> I'm up for adding an mc clone if somebody wants to do that. I > >> don't personally use it, but I do miss xtree gold from DOS and > >> OS/2. :) > > > > B-) > > > >>> I'm thinking it would be useful to have some common support for > >>> full screen terminal driving. The more command could probably > >>> use it to. So that would be four commands that could use it right > >>> off the bat, which is handy to help keep the design sane. More, > >>> vi, something like nano, and something like a basic cut down mc. > >> > >> Priorities are wrong there. > > > > Don't think I mentioned priorities, just that more COULD use it to, > > or just be as brain dead as simple can make it. After all, > > toybox's main design goal is simple. > > I like simple. :) I woke up this morning with the remnants of a dream about how to get started on my MC clone. Sometimes I program in my sleep. Spent much of the rest of today writing it down and blowing life into it as a proper design for a useful toybox full screen handling library and generic editor (with flexible keybindings as stated above), with pretensions of supporting MC style stuff to. I even started writing out suitable data structures. I'm guessing that we don't want a full vi clone, just a minimal one. As mentioned in this thread long ago, I don't use vi. So I would want those that do use vi to agree on an absolute bare minimal subset that we should implement. And perhaps a second almost minimal "nice to have" subset. I can do the same for MC's editor, and nano is likely minimalist enough. Wordstar I used long ago, and can probably find the relevant details. Microemacs I think I used once, emacs fans can sort that out for us. Then see what that adds up to as a common set of bare minimum editor features to write generically. One of the more interesting ideas I came up with was to implement lots of MC, and fancy editing features as some sort of special purpose scripting language with shell abilities. So there would be the full screen handling library, with bindable functions for editing and other basic generic functions, with callbacks. Then there would be a toy I'm calling toyboxes. You pass it a script, the script binds keystrokes to functions, perhaps binds some functions to a menu, then calls the generic editor. An MC script could bind keys and menus as before, create two boxes on the screen, send the output of "ls" to each box, and bind some callbacks to other keys. The library handles moving the file selector up and down one of the two boxes, as well as scrolling the box contents, switching between the boxes, etc. The library passes stuff back to the script when the user hits return on one of the lines. The script notices it was a directory, changes to that directory, then sends another "ls" commands output to the box again. Or notices it's a file and opens the proper viewer. Similar for the other standard MC keystrokes, they get bound to a callback in the script, the script does the MC stuff, the library handles the generic box and content stuff. Add a shell alias for "mc" to be "toyboxes mc" and you get an MC replacement. Or "toyboxes vi", "toyboxes nano", etc. I once wrote a program to run any program as a separate process, read commands from it's stdin, execute those commands, then send the result back through stdout. The results where implemented as a callback system, though it was all just plain text. It was up to the external program to figure out what to do with the results. I think something similar might work here. Then people can use the language of their choice to implement stuff using the toyboxes library. This keeps the toybox binary small and simple, while allowing people to create full blown MC / editor / whatever replacements. People can still write toys for toybox that use it internally. I can reuse some of that code. Almost finished my virtual worlds web site redo, and just got paid to get back to the embedded contract (I make him pay in advance, coz he has a hard time coming up with money). So I might not have much time to bang on it. See what I can get done. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
