Input Line Editing

[Guy Harris]

> The 256 character character font example was just for ease of
> presenting the idea.  It would work equally well if the terminal had
> less characters.  The unassigned pixel values would just not be used
> in the (1 pixel by 1 pixel) X font (the same way conventional X fonts
> don't use every possibly pixel combination).

OK, so what happens when "xterm" tries to paint a scrollbar?

> You don't.  That's exactly the point.  With a server implemented this
> way, *millions* (tens of millions, etc.) of existing,
> cursor-addressible, character-based terminals would instantly become
> X-compatible.

*SORT OF* X-compatible.  Boatloads of X applications won't run worth a damn on
them.

> The whole point of this was not just to have multiple character
> windows (although I don't see why this is such a bad way to get them).

It's a bad way to get them because:

	1) The other ways exist (e.g., 4.3BSD's "windows"), and this doesn't.
	   Until somebody builds this mythical "X on dumb terminals" server, I
	   won't believe it's necessarily even *possible*.

	2) It's a lot more work than doing something like "windows", and if
	   only a tiny number of X programs will run under it, it's not clear
	   the extra work is worth it.

> It was to have a consistent interface to the input and output devices.
> 
> With a character-based X server, all interactive programs could be
> written using X facilities.  Xterm would no longer be needed, except
> as a compatibility tool.  Termcap would no longer be needed, except as
> a configuration language for the character-based X server.

Again, if by "consistent interface" you just mean an interface that doesn't
require programs to know about N different kinds of terminals, something like
"windows" gets you this; it emulates a "standard" sort of terminal.