Xref: utzoo comp.terminals:2666 comp.unix.programmer:1261
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.terminals,comp.unix.programmer
Subject: Re: Alternate character modes on magic_cookie_glitch terminals (long)
Keywords: qvt101, freedom100, curses
Message-ID: <6662@segue.segue.com>
Date: 6 Mar 91 22:04:17 GMT
References: <1502@rascal.UUCP> <10248@scolex.sco.COM> <1504@rascal.UUCP> <10513@scolex.sco.COM>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 50

In article <10513@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes:
>The guy who wrote System V.3.2 curses claims that it deals
>with magic cookies correctly (he posts occasionally to Usenet),

There are a couple of significant bugs related to magic cookies.
One is that, after clearing to end of line it drops a cookie at the beginning
of the cleared area but forgets it did so due to bad parenthesization.
Another is that any change video attributes also forces changing color
attributes, which isn't necessary, at least on HP terminals (which are the
only cookie terminals supporting color that I know of).  curses forgets
that the color cookie was dropped, due largely to bad code organization.

>though I have yet to see a scrap of documentation that explains
>what is required of the terminfo file

Other than setting xmc appropriately, what should be required?

>and the curses program

I don't think curses programs need to know anything, other than that the output
may look horrible on xmc#1 terminals.

>I am somewhat confused by the 0 in xmc#0, the manual says the numeric
>value to xmc is the "number of blank characters left by smso or
>rmso".  If this value is zero then it would seem that there is no
>magic cookie required, therefore xmc should be removed.  Perhaps
>the 0 is special.

xmc#0 means that cookies take no space but that the terminal is still
magic-cookie-like.  For xmc terminals, setting an attribute affects the current
cursor location and all locations to the right of it up to the next magic
cookie.  For xmc#1 terminals, the magic cookie actually takes up a screen
location.  For non-xmc terminals, setting an attribute sets a state which
affects all subsequent output until the next attribute setting.

>The curses source implements 
>in a number of places;
>
>	if (! magic_cookie_glitch)
>		turn_off_attributes();

Actually, the test is usually magic_cookie_glitch >= 0; magic_cookie_glitch is
< 0 if it wasn't specified in the terminfo file.

This is understandable from the above.  If !xmc, turning off attributes turns
them off for subsequent output.  If xmc, this would turn them off at the
current cursor location, which not what is wanted.  It turns out that there
are other glitches in the code where this distinction for xmc terminals isn't
made, because the magic cookie stuff was obviously grafted onto (rather than
integrated into) some already badly organized code.