gnu@hoptoad.uucp (John Gilmore) (07/25/86)
In article <691@batcomputer.TN.CORNELL.EDU>, hsgj (Dan Green) writes: >> ED: Erase in Display. ESC [ Ps J >> EL: Erase in Line. ESC [ Ps K >> The bug is that no matter what you specify for the "Ps" parameter in either >> of these functions, the [Amiga] CONSOLE always performs function 0, which is >> "erase from current position to end of line/screen". > Public Apology: I just rechecked my references, and noticed that these > are *not* ANSI codes, but only VT100 codes. This is incorrect. I have a copy of the ANSI X3.64 standard here and the parameter for ED and EL is defined. The problem is: for a terminal, or terminal emulator, to claim ANSI X3.64 compatability does NOT mean that it implements everything in the standard. Rather, it means that IF it implements a certain function, it uses the standard escape code to represent that function. X3.64 contains all sorts of wierd escape codes for proportional spacing, typesetters, multiple fonts and colors, etc; if you were required to implement it all, nobody would use it. If you don't implement anything but the default parameter for Erase Line, you are free to ignore the parameter. Your alternative is to ignore the whole escape code and do nothing. Either is acceptable under the standard. Now, for a terminal or program to claim VT100 compatability, I would expect that in all cases it does what a VT100 does. However, having consulted to a terminal company that built an enhanced VT100 clone (Anderson Jacobson), I can inform you that finding all the nuances of the VT100 is a tough thing to do. Sometimes what you find is clearly wrong -- you found a VT100 bug. Mostly you just found a condition not defined by the ANSI standard, like what happens when the cursor hits the right margin on the bottom line when you are in insert mode, and you and the VT100 just didn't happen to do the same thing. If you are a conscientious "VT100 compatible" then you fix it. Mostly you aren't, so you don't bother -- or you don't even notice til a customer complains. Then the traditional response is "Well, it was Marketing that said it was a VT100, we just built it to be X3.64 compatible.". Moral: If you're writing a program, don't depend on VT100-private escape codes (clearly marked in the manual), and use as few oddball codes (like clear from here to beginning of line) as possible; this will make your program more portable, and it will run on "most" X3.64 terminals. Better to use termcap/terminfo, then your code will run on substantially *all* terminals. (There is a PD terminfo, for you non-unix types. See mod.sources archives "pcurses".) Morel #2: If you are marketing a terminal emulator, don't claim it's a VT100 unless you have made damn sure that it is. Unless you've spent a hundred man hours at it, you aren't sure yet. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!
campbell@maynard.UUCP (Larry Campbell) (07/28/86)
A company with which I am affiliated has a product called VT-Test which
is an automated VT100/VT200 validation and test suite. This was developed
under contract to a Major Computer Manufacturer, and is now being sold
on its own. I have used it to verify a VT100 emulator I wrote; I found
it very useful indeed. It's probably not cheap -- it's complete and
extensive and targeted towards terminal manufacturers who have a large
financial stake in being very compatible with the VT100.
For more information, contact:
Teleprocessing, Inc.
120 Fulton Street, 2nd floor
Boston, MA 01754
(617) 367-3210
--
"There are two kinds of science: physics, and stamp collecting."
Larry Campbell The Boston Software Works, Inc.
ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846jqj@gvax.cs.cornell.edu (J Q Johnson) (07/30/86)
I would be curious to know how well DEC products do at passing validation suites such as Larry Campbell's VT-Test. Note that DEC manufactures, or has made, several "vt100-compatible" terminals, including several models of vt100 hardware/firmware, vt100+avo, vt101, vt102, vt132, and [less compatible] the vt2xx series. My experience has been that even pure vt100s can differ substantially in their behavior, especially in tests where timing is involved (like RMS, I'd prefer not to use XON/XOFF).