XChars c bindings

int xchars(int *argc,char * args[]) { // should return NOTFOUND=0 or a non-zero.
// PutStr rect gc string
struct { char *cmd; char * rect;char * string
} *PutStr_ptr;
// NeWin conn win
struct { char *cmd; char * rect;char * string
} *NewWin_ptr;
// NewConn conn win
struct { char *cmd; char * conn;char* win;
} *NewConn_ptr;
// NewGC conn gcname
struct { char *cmd; char * conn;char * gc
} *NewGC_ptr
// SetFont gc font_name
struct { char *cmd; char * gc;char* font_name;
} *SetFont_ptr;
// SetRGB gc for_rgb back_rgb
struct { char *cmd; char * gc;char* fore_digits;char* back_digits;
  } *SetRGB_ptr;

// NewRect win gc rect x y width height   
struct { char* cmd; char* gc; char* rect; 
char* x;char* y;char* width;char* height;
    }*NewRect_ptr;
 // SetRect rect gc
 struct { char* cmd; char* rect; char* gc;
   } *SetRect_ptr;

// for example:
SetFont_ptr = (void *) args;
printf("%s %s %s\n",
ptr->cmd,ptr->gc,ptr->wfont_name);
}

OK,  this was semi-automated using the look and type method, but it is simple.   Use them in the proper order.  Notice, the struct pointers are just mapped to args list for use. Thislikely does not exactly compile, but this is the correct c binding approach.

Your basic Xchars API for the window. Later we get Xmice and Xboard.  Use SetRect api to associate a rect with another gc.  Basically this replaces putchar on the command line to putstr on the box.  Everything is null terminated text, names, digit strings. The general rule is,  readable names less than eight chars, but string arguments to the screen any length. The front end symbol table isd faster than anything we need, ad small, but really greases the interface.

The mouse events and keyboard events will be equally simple, and there will be a declared call back type.  I think when we have mouse then client and xchars will reserve a portion of args list for message passing.

Xchar text files

Not a problem, make a set of line terminated strings in the model above, see in the comments:

NewConn MyConn; // semi colon optional here
NewWin MyConn MyWin;
NewGC MyConn MyGC;
NewRect MyWin MyGC MyRect 10 20 300 200;
PutStr MyRect "Hello World";

 Once you have your script use ExecFle file_name; // at the command line

 Be sure Xchars was loaded: LoadMod xchar.so; // I think, if I remember

Keep your loadable local. /home/loadables  // for example.

Notice the two formats, linux command line text and compiled. The difference between the two is the console loop tokenizer, Default is not involved.

The Xchars symbol table

It will be a balanced tree for most well written scripts. A well written script is Huffman encoded, the script names allocate more char spaces for significant differences between set members. as in:

HeaderGC;
MidTxtGC;

Note, the common group names have shortest character allocation in a name.  The simple table will end up sorting on the first part, where character are complex.  If the first characters are sufficiently informative, then the symbol tree will be balanced. 32 names becomes a five step hop through the symbol tree,  short  test and jumps. Putting the fast eight char symbol tables up front of loadables is a good idea. The concept can be extended to 16 char names easily and double your test instruction to two test and jumps.

Making symbols even faster

We need text8 type: `allfitin` // which becomes a long packed with chars. then we have:

struct { text8 cmd; text8 rect; text8 gc } *SetRec_ptr;

Categorizing symbols:

Rare, seldom used symbols cal them nearly the same name:

Rarely000;
Rarely001;
.
This puts all the seldom used ont a separate branch, the informative, rapid fire commands take one step then split the remaining tree amongst themselves. Extreme Huffman encoding, actually the central algorithm for the theory of everything, pure sphere packing.