My command line editor needs to scroll

In the more general case, the application needs a call back to handle it own strings. But in the simple case of default command line editor, scrolling in a rectangle is required.  Left and right and echo and enter only happen on the bottom line, where the command is being constructed. 

Rectangles need scrolling does that? In the ong term, client side does its own work, and in this case, the application needs to prep its own output string and xchars will render it. I keep with that philosophy, and io manager will have one default command line editor, and one default scroll rectangle function. Thiss hould be an application function but default rules over rule in thi case. The default system needs a command line editor without dependencies, it has t have that default function in io manager.

Simple enough. It will physically shift the string around in the string history buffer, then tell xchars to draw the string.  Rendering fonts, ultimately, will be efficient when xchars adopts cairo, so redraw string works perfectly fine.  Not many lines of code to shift a line, however IO manager will be truncating lines that exceed line width, a constant at compile time, sorry. So, I manager, itself the default IO manager, has no dependencies except the linux file input architecture, hasd a fixed size string buffer nd manages the calls to xchrs, including a 'xcb_poll_event ' timeout, optional, for redraws.

Up and down arrows just ump from new line to new liner, as represented by nulls, and provide a text  fill for the command line.  Command line will be a separate rectangle, and can be drawn by itself. All of this seems reasonable, and seems to define the minimal default. Everything focused on a swappable system, some snippets deliberately designed to force user to swap into more taylored functions, having the same namespace.. Many functions swappable, using symbol table lookup to locate alternative entries.