Command argument macro expansion moving to IO manager

I consider the :
cmd arg1 $path $1; # expand some command line macrs

to be a command editing function, done where the command line is edited, and that is the intelligent IO manager.  The easiest method is to have a front end symbol table for IO manager, and any or all the arguments can be potential expansions if they exist in the table.

The default mechanism is that IO manager assembles a command line, and possibly calls tokenizer, I am not sure.  But if IO manager tokenizes a cmd string, then is it a one step process to check for argument expansion.  Then IO manager can have some sophisticated controls, editing methods, symbol definitions maintained by the syntax engine.  It can manage a simple scroll, or it can swap out xchars and swap in qt_lite, do a full set of widgets.

Default cursor?
White space, same as default bash.  The io manager I am writing will give simplicity a new meaning, it knows nothing of cursors, it can write a char, write a string to rectangle, and that is the limit of its graphics.

PutStr rect White_Char x y;  ## place the cursor

Beyond that, IO manager has space for unlimited spaghetti in line completion, line editing, line history.  Make a world of spaghetti in io manager.    But the spaghetti I am adding is just whatever popular line editing snippet I can find. It has the msg loop, standard symbol table, and line editing spaghetti, all cutnpasted.

Namespacing introduced.

xchars, as an entry point, is a real system address, like ExecCommand.  modules can register their module name like a built in, avoid the module search.  The io manager, can get the pointer and call xchars directly, they can bond, and we have primitive name spaces going on.  Soon, console loop symbol table mus be partitioned and upgraded, version 2.  But for now, it can upgrade entry points, and may do that as a matter of course, eliminating module searches. That is actually code removal, odule searches were never directed from module names, and should have been.

The universal interface is still entry, but that can be a pseudonym for the real entry point, module name:
GetModule name

A new built in command returns the actuall address pointer of module 'name'.  IO manager calls it directly with tokenized arguments.  In fact, io manager can call it raw binary, by passing symbol look uyp entirely and keep binary xcb variables.  Dunno yet, I might make one binary, open ended interface to xcb in xchars, make binding much faster, especially for games with rapid IO.

Move tokenizer to IO manager

If IO manager is the main keyboard and mouse entry point, it has the command line editing tools; then it should manage the tokenizer process.  String cmds are not out preferred format on the Bus, we should tokenize ASAP that all snippets can read the new stuff. Tokenize, argument macros, command line spaghetti, command line history all belong in io manager, it converts all input into Bus compatible linux args sequences.

Now we have simplified our syntax engine interfaces, they can install a modified io manager, prepare the tokens the way they like, and bind to io manager.  In fact, syntax engines can maintain their own gui, just have io manager run as a snippet. hey can make command line editing, or have their own source editor function, built in.  Python, for example, would execute a using command in their source to set up a complete Bus environment, selecting the components it needs, from make and configure utilities to io managers to sql_ite to qt_lite to..... A world of snippets.