Input Line Editing

[Jeff Siegal]

In article <60001 at sun.uucp> guy at gorodish.Sun.COM (Guy Harris) writes
(in reply to my article)

>> Consider an 80x24 terminal with a 256 character font.
>99 44/100% of the terminals out there don't have 256-character fonts, so it
>won't work on 99 44/100% of the terminals out there.

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).

>If you need a special terminal for this

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.

>If all you want an "X server on a dumb terminal" for is to have multiple
>*character* windows on a dumb terminal, [...]there are *FAR*
>better ways [...]

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 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.

Jeff Siegal