[ On Wednesday, March 29, 2000 at 18:23:32 (-0500), der Mouse wrote: ]
> Subject: Re: Anyone recommend a good terminal type?
>
> > A "termcap" (or "terminfo") entry defines the capabilities of the
> > terminal.
> 
> Well, I'd say "describes"; it's the terminal itself that *defines* its
> capabilities.

Yes, that's a better term....

> Of course, there's no particular reason why they have to emulate any
> particular existing "real" terminal.  When I did my terminal emulator,
> I did exactly that: ignored all "real" terminals.  (Later, I added an
> emulation module designed around ANSI X3.41/X3.64, to which I added
> various DEC extensions, producing a very serviceable VT100 emulator.)

For console emulators there are very strong desires to emulate a common
terminal well enough that it doesn't annoy anyone who uses the console
to remotely access some other system that's likely to know how to speak
to this "common" terminal type.

> Note also that true bug-for-bug emulation will more or less require the
> ROMed code from the original terminal, since AFAIK nobody knows what
> bugs may lurk in corner cases.

In the case of any well known "classic" terminal the bugs that are
important from a terminfo/termcap point of view are all very well known
by now (though sometimes their exact nature is lost in folklore and/or
obscure bits of code in various libcurses implementations).

Certainly for a relatively new, and/or relatively rare terminal the
bugs might not all be known, perhaps not even well enough to create a
true full-function terminfo/termap entry..

>  (I'm also not sure full bug-for-bug
> compatability is a good thing; is it necessarily desirable to have the
> emulated terminal crash when - and in the same way that - the real one
> would?)

In some cases it's absolutely necessary if you want some applications to
behave properly.  Unix applications are generally very forgiving and
unless the "bug" is a really annoying quirk the occasional full-screen
refresh is enough to struggle through.

What's important to keep in mind of course is that bugs in this sense
are only important from a terminfo/termcap point of view -- i.e. do they
affect the way an application using such capabiilties databases will
operate.  If a bug has been either dealt with by a special quirk entry
or by changing or omitting what would otherwise be a correct item
according to the documentation or some expected reference standard then
the emulation must function correctly when driven by an application
expecting to have to use that quirk (or changed item, etc.).  Of course
it's also important that the emulation not require its own quirks,
changes, or omissions in the capabilities description either or else it
too becomes a distinct terminal type.

> > There's nothing more painful and frustrating than a unique terminal
> > "emulation" on a console that doesn't 100% match any real terminal
> > from a terminfo/termcap point of view,
> 
> I don't think I've yet seen a terminal emulation that 100% matches the
> real thing.

MS-Kermit made invalid claims about their emulation for a long time but
they finally did get it right so far as I could tell....  Early versions
of it did require their own terminfo/termcap entries but more recent
versions have been able to use the "real" entries without even a glitch.

>  If nothing else the keybaord layouts are always wrong.

The keyboard layout is not normally important -- what's important is
that keys with the same label mean the same thing to the application.

> (Yes, this can matter, if some program assumes things about the
> keyboard geometry.)

Well, sort of, yes, that's true, though generally the cases I'm familiar
with do not involve any keys that generate complex sequences (i.e. are
simply using alphanumeric keys).

>  Even with respect to output only, I've never seen
> an emulator that was a perfect emulation.

I've directly compared some version of MS-Kermit (post 3.x) to my real
VT100 with all available test suites and many applications and it lives
up to its claims of 100% perfect bug-for-bug emulation.

> With respect to the specific case of an i386 console, I suspect that
> you'll find very few real 25-line terminals, and also suspect you'll
> find comparatively few people willing to give up that 25th line for the
> sake of your desire for an unattainable perfect emulation of some real
> thing.  (As opposed to terminals which have a 25th line in hardware but
> make it accessible only as a "status" line of some sort, which of
> course would be emulable but would lose that line as far as most
> programs are concerned.)

Indeed most of the real "24x80" terminals I have actually display at
least 25 lines physically.  On some you can in fact use that 25th line
for data though usually it's dedicated to being a status line as you
say.  In fact a quick search through the NetBSD termcap file for real
terminals (i.e. after eliminating the emulators) reveals quite a few
25-line terminals.  There are several terminals that can use the 25th
line for data and that are widely enough known, at least in Unix
circles, that they would make a great basis for an emulator for a PC
console.  Indeed almost every Wyse terminal since the wy60 can do that,
as can at least one of the AT&T models I have.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>