Alternate character modes on magic_cookie_glitch terminals (long)

Xref: xenitec comp.terminals:1825 sco.opendesktop:592 comp.unix.programmer:1163
Keywords: qvt101, freedom100, curses
Message-ID: <10513 at scolex.sco.COM>
Date: Thu, 28 Feb 91 20:26:18 GMT
References: <1502 at rascal.UUCP> <10248 at scolex.sco.COM> <1504 at rascal.UUCP>
Sender: news at sco.COM


In article <1504 at rascal.UUCP> theo at rascal.UUCP (T. Kramer) writes:
>In article <10248 at scolex.sco.COM> staceyc at sco.COM (Stacey Campbell) writes:
>>You must define an acsc string for your terminal.
>
>Unfortunatly ACS is not portable across UNIX V.2, XENIX V.2 etc. This is
>however, a strict requirement for our code.

ACS_ macros work fine on both Xenix 2.3.2 (and later) and SCO Unix with
the proviso I mentioned in the previous post that the Xenix tic command
does not grok acsc in terminfo source files; in which case use the Unix
tic and transport the ticced file back to Xenix.  Some SCO products are
now moving to curses color, so we develop on Unix and ship the color
applications and color terminfo files for Xenix.

>I would agree with you
>that if I used the ACS_ defines I would not need (w)attron and (w)attrof,
>but because our code must be portable including, hopefully, our terminfo
>source files I can not depend on ACS_ defines.

I've developed a fair bit of public domain code that compiles on BSD,
System V.2, V.3.0, and V.3.2 curses and have come to the conclusion
that it is very important to follow the manual for System V.2 and
System V.3.[0-2] curses.  Trying to fake out the ACS_ characters to maintain
code portability with non-System V curses can be done, but because
non-System V curses doesn't have a generally recognized way of storing
ACS information, you will have to develop a system that works for every
single terminal you plan on supporting.  I usually find myself writing
the following code;

#ifdef ACS_HLINE
	box(win, 0, 0);
#else
	UseCruftyBoxHack(win);
#endif

If you aren't willing to use ifdefs or use a seperate source pool
(as seems to be the case) then adding, for example, color to a curses
portable application becomes near impossible.

>>"REMEMBER THAT sgr AND sgr0 MUST ALWAYS BE SPECIFIED".
>
>I need the call to (w)attrof as in my actual code I need to output
>normal character information after for example having painted a box on
>the screen.

If you absolutely must use non-standard methods to put alternate
characters on your screen then wattron() and wattroff() _will_ do
what you want.

>The point of my request for
>help, however, is why does SCO Opendesktop Development System curses
>not output an \E% or \E%% or \E\% but does output AA and BB and \E$ and ...
>for the (w)attroff call? I seriously believe that this is a serious bug
>in the curses package which makes it difficult if not impossible for me,
>and I am sure many others who have selected curses for portability, to
>generate production binaries using the SCO UNIX and Opendesktop development
>systems!

Which prompted me to go back to your original post and try out
your program and terminfo file again.  :-)  The reason the qvt101+so
entry is failing isn't exactly glaring, but once you see it all
becomes clear.  Your qvt101 entry contains the numeric capability
xmc#0.  The guy who wrote System V.3.2 curses claims that it deals
with magic cookies correctly (he posts occasionally to Usenet),
though I have yet to see a scrap of documentation that explains
what is required of the terminfo file and the curses program (obviously
something, otherwise your program would work).

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.  Either way, if xmc#0 is removed from the qvt101+so
terminfo file the program will emit rmacs.  The curses source implements 
in a number of places;

	if (! magic_cookie_glitch)
		turn_off_attributes();

I've added comp.unix.programmer to the Newsgroups line because I
know there's some folks there who have dealt with this problem.
A simple way to fix the problem is to see if your terminal supports
_any_ attributes without magic cookies, then remove xmc and set
smso and rmso to that attribute, for Wyse 50s I think this attribute
is protected mode.

Here is a program that demonstrates the problem;

#include <curses.h>

int main()
{
  int index;
  int y, x;

  initscr();
  addch(ACS_ULCORNER);
  for (index = 1; index < 20; index++)
    addch(ACS_HLINE);
  addch(ACS_URCORNER);
  refresh();
  endwin();
}

Here's the original terminfo file (with acsc and sgr0 added);

# Terminfo source code for my (theo's) qvt101 terminal
qp|qvt101+so|Qume qvt101 + terminal,
	cr=^M, cud1=^J, ind=^J, bel=^G,
	is2=\E0P\Ew\E.4\E(\EC\E%\EX\E\047\E+\Ef^M\Eg,
	clear=\E+, tbc=\E3, hts=\E1, sam, cols#80, lines#24, cr=^M, nel=^J,
	xmc#0,
	khome=^^, kcuf1=^L, kcub1=^H, kcud1=^J, kcuu1=^K, 
	cup=\E=%p1%' '%+%c%p2%' '%+%c, cvvis=\E.1, cnorm=\E.4\E*,
	cbt=\EI, cud1=^J, cuf1=^L, cuu1=^K, home=^^,
	cub1=^H, ul, smso=\E), rmso=\E(, el=\Et, ed=\Ey, il1=\EE,
	dl1=\ER, dch1=\EW, ich1=\EQ, smul=\EG8, rmul=\EG0, rmacs=\E%%,
	smacs=\E$, sgr0=\E(\E%%,
	kf1=^A@^M, kf2=^AA^M, kf3=^AB^M, kf4=^AC^M, kf5=^AD^M, kf6=^AE^M,
	kf7=^AF^M, kf8=^AG^M, kf9=^AH^M, kf0=^AI^M,
	acsc=kkllmmjjnnwwvvuuttqqxx,
-- 
                             Stacey Campbell       
                        Internet: staceyc at sco.com
     UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc