Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.sources.d
Subject: Re: when using termcap, get it right!
Message-ID: <6828@mimsy.UUCP>
Date: Thu, 28-May-87 23:14:20 EDT
Article-I.D.: mimsy.6828
Posted: Thu May 28 23:14:20 1987
Date-Received: Sat, 30-May-87 09:37:04 EDT
References: <1149@carthage.swatsun.UUCP> <8601@tekecs.TEK.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 55
Keywords: termcap, curses

>In article <1149@carthage.swatsun.UUCP> schwartz@swatsun (Scott
>Schwartz) writes:
>>... At Swarthmore we have lots of Adds Viewpoint terminals.  On
>>these beasties the escape sequences to enter standout mode, underline
>>mode, normal mode, etc all take up one space on the screen (gaak).

(I do not recall this of the Viewpoint:  It had one mode that could
always be displayed; that mode could be any of inverse, blink, or
underline, and perhaps one other.  These may be different Viewpoints.)

>>The problem is that lots of programs that go to lots of trouble
>>to figure out what the termcap entries for these things are never
>>bother to check the width of the entries as printed.

In article <8601@tekecs.TEK.COM> snoopy@doghouse.gwd.tek.com (Snoopy) writes:
>Am I missing something here, or should these termcap entries include
>a backspace to return the curser to where it belongs?

Alas, this simply does not work.  The way these terminals work is
rather bizarre.  The manufacturer decided to save one whole memory
chip, using only seven bits per character.  Since, however, better
terminals provide inverse video, underline, blink, and bold, these
terminals do too.  But without extra bits, this information must
come from elsewhere.  It is inserted into the display by storing
control characters in screen RAM.  These are programmed to display
as blanks, yet they are *not* blanks:  They alter the state in the
video generator such that all following characters are displayed
in inverse video, or underlined, or whatever.

These `marker' control characters that display as though they were
blanks are referred to as `magic cookies'.  Terminals that behave
this way are said to have the `magic cookie glitch'.  This is a
horrid thing for a terminal to do, and there is now no justification
for it: memory is cheap, and 2K by 8 bit display RAMs are available
on a single chip.  (Indeed, I suspect that by now, 2K by 11 or more
bit dual ported RAMs with one of the ports internally interfaced
to a video controller are available.)

If you manage to position the cursor on top of one of these magic
cookies, and write a real character, it replaces the magic cookie
and the inverse video (or underlining or whatnot) on succeeding
characters instantly vanishes.  Whether it is possible to position
the cursor on one of these cookies, and whether text will overwrite
or simply skip the cookie, depends on the terminal firmware.

>Why screw up a bunch of code to get around brain-damaged hardware
>if it can be fixed in the termcap entry?

Why keep a terminal that uses magic cookies, when real displays
are cheap?  :-)  Actually, faced with such a terminal, I might just
leave out the `so' and `se' termcap capabilities.  We did this with
the Datamedia 2500, whose only standout mode was `blink'....
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris