Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bbn!jr@bbn.com From: jr@bbn.com (John Robinson) Newsgroups: comp.emacs Subject: Re: how come vt100? (was Re: running vi inside GNU emacs vs. ftp-find-file) Message-ID: <39993@bbn.COM> Date: 16 May 89 14:30:41 GMT References: <39714@bbn.COM> <860007@hpcljms.HP.COM> <60618@yale-celray.yale.UUCP> Sender: news@bbn.COM Reply-To: jr@bbn.com (John Robinson) Distribution: comp Organization: BBN Systems and Technologies Corporation, Cambridge MA Lines: 61 In-reply-to: Ram-Ashwin@cs.yale.edu (Ashwin Ram) In article <60618@yale-celray.yale.UUCP>, Ram-Ashwin@cs (Ashwin Ram) writes: >I would also like to see a vt100 emulator -- surely it can't be less useful than >terminal.el? Why would you *not* want vt100 emulation? > >-- Ashwin. Well, no one could honestly answer that. However, there are a lot of tough issues implied by this seemingly innocent question. And some easy ones. 1. Someone needs to volunteer to write it. I doubt we can prevail upon the FSF to consider this near the top of their wish list. VT100's can run emacs, and why should they care if an emacs can emulate a vt100 running vi or EDT or what-have-you? This sounds like the ideal candidate for contributed software, from someone who has specific need and the warm body to do the work. 2. Everyone has a different model of what a vt100 does. Just from the discussion here, these range from something that can run vi (the terminal-emulator already does this, though apparently it has a bug somewhere that vi tickles). Or something that can run programs on systems that have never heard of any terminals save vt100's. Or something that provides ANSI X3.64 capabilities (this is *not* equivalent to a vt100 - each has features missing from the other, and X3.64 realy specifies a list of functions and no definition of what compliance with the standard means - do you have to support all the functions defined in the standard?) 3. If you choose to model the vt100, do you include the magic cookies in DEC's internal manual whose intent paraphrases to "this is the list of undocumented features of the vt100 family of terminals that you are allowed to use in DEC software and will be supported on all DEC terminals in this family"? Lots of VMS software will not work properly without these hacks, though I think that software vendors are coming around to realize that terminal-dependence sells fewer terminals *and* fewer software copies, hence is bad. [I suppose the existence of that manual could be an urban legend - I have never seen it]. 4. What happens when emacs can't do something the vt100 can? Remember that emacs demands very little of its terminal - it has to operate with a subset of capabilities to ensure the widest compatibility. When a program asks for something like 131 columns, reverse video, double-width or height, graphic characters, etc., what should the emulator do? Solving this will consume a lot of your effort in building the emulator. Even if you ignore the control sequence, you still have to parse it and throw it away. (X3.64 helps here - it specifies a standard form for the control sequences that makes this fairly straightforward). I think getting it right would require the help of someone who has written a terminal emulator already. A different approach might be to enhance terminal.el to support arbitrary termcaps (again, up to a point). There is even a comment in that file pointing out where you would change things to make this possible. Again, who'll volunteer? -- /jr jr@bbn.com or bbn!jr C'mon big money!