Xref: utzoo comp.unix.xenix:2503 comp.terminals:754
Path: utzoo!attcan!uunet!husc6!uwvax!rutgers!mtunx!whuts!homxb!hropus!ki4pv!tanner
From: tanner@ki4pv.uucp (Dr. T. Andrews)
Newsgroups: comp.unix.xenix,comp.terminals
Subject: Re: SCO and the attribute byte
Summary: these terminals \fBcan\fP be dealt with.  (trust me, he says...)
Keywords: professional lyrix televideo
Message-ID: <6957@ki4pv.uucp>
Date: 18 Jun 88 02:15:31 GMT
References: <38@wzlr.UUCP> <691@nod2sco>
Organization: CompuData, Inc., DeLand
Lines: 55

In article <691@nod2sco>, rosso@sco.COM (Ross Oliver) writes:
) [ notes SCO's reluctance to deal with "magic cookie" terminals ]
) This is NOT a software problem, it is an artifact of some terminals.
)  ...  For instance, if you attempt
) to display the words "SCO Professional" with the characters "Pro"
) in reverse video, the terminal would display "SCO *Pro*fessional",

As one who has written rather a lot in support of terminals plagued
by the magic cookie glitch (sg#1, ug#1), allow me to offer a little
easily forgotten advice.

First of all, choose what you reverse-videate (highlight) carefully.
If you can arrange that it is surrounded by spaces, you win.  That's
where you put the "magic cookie".  (Yes, I've written lots and lots
of stuff which uses reverse video and the occasional underline.  You
forgot ug#1, didn't you?  This approach is viable)

There is the occasional case where you will have to tolerate a spare
space where a magic cookie lives.  An editor which highlights a block
of text will almost assuredly suffer here.  It won't be painful if
the program is aware of the spaces eaten by the terminal, but if the
program doesn't notice that sg#1 is set in the termcap file then
there will be a real problem.

One example of a program which is not very clever in this regard is
"more", which takes sequences of "x\b_" to generate an underlined "x"
using "us" and "ue" strings.  It doesn't look at "ug#1", and so
"nroff" output piped through it looks bad on such lines.  Try it to
see where the pitfalls of the "magic cookie" lie.

) This prevents reverse and normal characters from being displayed next
) to each other,
Unless the normal character (the blank on a tvi doesn't appear in RV)
happens to be a blank.  In many applications (eg: a database package
showing columns of crud, with an entry highlighted) there will be
room for a magic cookie instead of a regular space.

There is of course another problem, widely ignored, which I choose to
call "flash".  Take a screen without any magic cookies.  Put a reverse
video "magic cookie" up there, in preparation for display of some RV
text.  Notice that the screen flashes.  Ugly, isn't it?  The "good"
thing to do is to first stick the "se" magic cookie where you expect
the end of the string to be.  Position the cursor to drop in the "so"
magic cookie (if you have room for it, position one char BEFORE the
text is to be displayed, to allow room for that magic cookie).  This
way, the display works nicely.

Seeing that I've been addressing this problem with nice displays from
back in our CP/M days, I have little sympathy for folks who don't make
at least a good effort.  Saying "sorry, but you really should have
bought a different terminal" doesn't wash.  (That tvi950 I use is a
survivor from our CP/M days.  Still works.)
-- 
rutgers!bpa!cdin-1!cdis-1!ki4pv!tanner  (better than it looks!)
or...  {allegra codas killer decvax!ucf-cs}!ki4pv!tanner