wjc@ho5cad.ATT.COM (Bill Carpenter) (05/13/89)
> > The terminal-emulator is close to a real solution, but isn't very > > clean. Does anyone have a real vt100 emulator? When I see questions like this, I always wonder what folks really want: 1. Do you want a vt100 emulator because you go to non-UNIX systems that aren't flexible on terminal types (nothing like termcap/ terminfo)? 2. Do you just want the terminal emulator to be something recognized by the UNIX system you're on? (Not likely that most people have termcaps for the emulator's codes, but they can be built readily.) 3. Or are you really finding things that the terminal emulator doesn't do correctly, even after you set up a terminfo or termcap entry? I wonder this because I've tried running "vi" inside the terminal emulator (on a SUN3/SunOS 4.0) just to see if it would work. No problems, but I don't know how to do much in "vi" (the help key is "<ESC>:q!", right? :-). I also once ran GNUemacs inside a terminal emulator inside a GNUemacs inside a terminal emulator inside a GNUemacs (three deep). Although I was starting to lose track of my place in the time-space continuum, I didn't see the emulator making any mistakes. So, what's the real question? Why do you want vt100 emulation? -- -- Bill Carpenter att!ho5cad!wjc or attmail!bill
shapiro@athos.rutgers.edu (Joel Shapiro) (05/15/89)
Why a terminal emulator? Because a number of us need to use VMS vaxes, and like to do it from a Sun window. I could really use a good vt220 emulator, complete with downloadable characters. But even a full featured vt100 (able to answer inquire) would be more that any of the several emulators I have tried. PS - don't really want it inside emacs, an independant emulator is what I would like. A Sunview tool emulator whould be even better. Joel Shapiro shapiro@ruhets.rutgers.edu
ell@Ed (Edward L. Lafferty) (05/16/89)
In article <May.14.18.51.18.1989.18924@athos.rutgers.edu>, shapiro@athos (Joel Shapiro) writes: >Why a terminal emulator? Because a number of us need to use VMS >vaxes, and like to do it from a Sun window. I could really use a good >vt220 emulator, complete with downloadable characters. But even a full >featured vt100 (able to answer inquire) would be more that any of the >several emulators I have tried. > PS - don't really want it inside emacs, an independant emulator is >what I would like. A Sunview tool emulator whould be even better. > Joel Shapiro shapiro@ruhets.rutgers.edu The vt100tool for Sun OS 4.0 is ftp'able from titan.rice.edu. Look for vt100tool.tar.Z (either in sources or incoming) and then decompress and untar it into a directory. Then do a make and you should be OK. Let me know if you have troubles. This is the same emulator that I posted several years ago for version 2 and 3. I tries for full fidelity to a vt100 including double width and height chars, graphics, bold, etc. Regards, Ed ----------------------------------->> External: Internal Mail addresses at MITRE: ell@linus.mitre.org ell@mbunix ell@linus
Ram-Ashwin@cs.yale.edu (Ashwin Ram) (05/16/89)
In article <WJC.89May13164908@ho5cad.ho5cad.ATT.COM>, wjc@ho5cad.ATT.COM (Bill Carpenter) writes: > > > The terminal-emulator is close to a real solution, but isn't very > > > clean. Does anyone have a real vt100 emulator? > > When I see questions like this, I always wonder what folks really > want: > > 1. Do you want a vt100 emulator because you go to non-UNIX systems > that aren't flexible on terminal types (nothing like termcap/ > terminfo)? > > 2. Do you just want the terminal emulator to be something recognized > by the UNIX system you're on? (Not likely that most people have > termcaps for the emulator's codes, but they can be built readily.) > > 3. Or are you really finding things that the terminal emulator > doesn't do correctly, even after you set up a terminfo or termcap > entry? > > [...] > So, what's the real question? Why do you want vt100 emulation? For reasons 1 and 2. Many non-Unix systems don't like non-vt100 terminals (or need to be cajoled into working with them), and even on Unix systems I think it would be hard for someone with less experience to create a termcap entry and to write shell script code to use the correct termcap entry (since now the new entry would be in a different place from all the standard entries in /etc/termcap). Plus the emulator in terminal.el doesn't have all the features of vt100 terminals. 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.
jr@bbn.com (John Robinson) (05/16/89)
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!
bet@dukeac.UUCP (Bennett Todd) (05/17/89)
In article <May.14.18.51.18.1989.18924@athos.rutgers.edu> shapiro@athos.rutgers.edu (Joel Shapiro) writes: >Why a terminal emulator? Because a number of us need to use VMS >vaxes, and like to do it from a Sun window. I have managed to leave VMS completely, praise be, but occasionally have to deal with its heir, terminfo-based UNIX systems. While I could stomp up a terminfo definition to match the termcap definition, I generally say to heck with it and run vtem. Part of the vttool package, it is a simple pty-based filter that maps vt100 sequences onto whatever you've got. If you want something for under Sunview the whole vttool package might be handy, since that wraps a button manager around vtem to give you a mouseable vt100 keypad. I don't use vttool; I like mgr better than Sunview, and I'm allergic to mice. Check the anonymous FTP archives at titan.rice.edu, probably in sun-sources. -Bennett bet@orion.mc.duke.edu
darin@nova.laic.uucp (Darin Johnson) (05/18/89)
In article <1408@dukeac.UUCP> bet@dukeac.UUCP (Bennett Todd) writes: >In article <May.14.18.51.18.1989.18924@athos.rutgers.edu> shapiro@athos.rutgers.edu (Joel Shapiro) writes: >>Why a terminal emulator? Because a number of us need to use VMS >>vaxes, and like to do it from a Sun window. > >...run vtem. Part of the vttool package, it is a simple pty-based >filter that maps vt100 sequences onto whatever you've got. If you want >something for under Sunview the whole vttool package might be handy, since >that wraps a button manager around vtem to give you a mouseable vt100 keypad. >I don't use vttool; I like mgr better than Sunview, and I'm allergic to mice. > >Check the anonymous FTP archives at titan.rice.edu, probably in sun-sources. Also Sun sells a vt100 emulator. I checked out about 3 or 4 pd programs, but most of them had little problems that made them annoying - including header files that didn't exist, requiring sun source code, etc. One that seemed to work fine in UNIX, never worked when I tried to use it when talking to VMS. Problem turned out that all it did was read in the termcap entry for vt100 and used that to map vt100 escape sequences :-) Sun's version isn't that expensive ($415 GSA) and is included with the DECnet package. It also allows remapping of function keys which is "mandatory" for VMS editors. It is the only one I have seen that also supported double-width double-height characters, 132 column mode, etc. While vt100 mode in emacs would be convenient, I don't think it should be part of the core distribution - otherwise it may end up supporting all sorts of wierd terminals (like those IBM beasts). Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.