Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!husc6!mit-eddie!fenchurch.mit.edu!jbs From: jbs@fenchurch.MIT.EDU (Jeff Siegal) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <9685@eddie.MIT.EDU> Date: 15 Jul 88 10:02:35 GMT References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> <59697@sun.uucp> <9680@eddie.MIT.EDU> <60001@sun.uucp> Sender: uucp@eddie.MIT.EDU Reply-To: jbs@fenchurch.MIT.EDU (Jeff Siegal) Organization: MIT EE/CS Computer Facilities, Cambridge, MA Lines: 33 In article <60001@sun.uucp> guy@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