[comp.unix.ultrix] curses is broken for 3.0 -- or is it?

peirce@gumby.cc.wmich.edu (Leonard J. Peirce) (06/14/89)

A while ago, someone mentioned in this group that keypad(3cur) is broken
under 3.0.  Well, I got a copy of Don Baumgartner's curses library from
Rice University, built it, and tried a small test program on it and
got the same behaviour as the Ultrix curses library.  I built Donn
Baumgartner's library on a 4.3BSD machine and keypad() worked perfectly.

Perhaps the problem isn't in the keypad(3cur) after all.  Could it be
in the terminal driver?  Has anyone out there gotten keypad to work
on 3.0?
-- 
Leonard J. Peirce               Internet:  peirce@gumby.cc.wmich.edu
Western Michigan University                peirce@gw.wmich.edu
Academic Computer Center        UUCP:      ...!uunet!sharkey!wmichgw!peirce
Kalamazoo, MI  49008            Voice:     (616) 387-5469

grr@cbmvax.UUCP (George Robbins) (06/14/89)

In article <761@gumby.cc.wmich.edu> peirce@gumby.cc.wmich.edu (Leonard J. Peirce) writes:
> A while ago, someone mentioned in this group that keypad(3cur) is broken
> under 3.0....
> 
> Perhaps the problem isn't in the keypad(3cur) after all.  Could it be
> in the terminal driver?  Has anyone out there gotten keypad to work
> on 3.0?

Make sure that you're doing it BSD style.  I'm pretty sure 'rn' didn't
work when the auto=-configuration software saw "termio" and decided to
use it.  Recompiling w/o termio fixed it.

Is anyone out there having problems with terminal servers under 3.0?
We have a number of DECserver 200's and DECSA'a, and users have reported
that they can no longer upload with kermit, xmodem, etc - this used to
work fine.  I haven't been able to clearly define the problem yet though.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

peirce@gumby.cc.wmich.edu (Leonard J. Peirce) (06/21/89)

Something else that I have noticed with curses under 3.0 is the inability
write in the last cell (bottom right-hand corner) of the screen.  Writing
to it doesn't cause any problems; it just isn't displayed.  Perhaps a
boundary condition in the curses code is incorrect.
-- 
Leonard J. Peirce               Internet:  peirce@gumby.cc.wmich.edu
Western Michigan University                peirce@gw.wmich.edu
Academic Computer Center        UUCP:      ...!uunet!sharkey!wmichgw!peirce
Kalamazoo, MI  49008            Voice:     (616) 387-5469

jmg@cernvax.UUCP (john gerard) (06/21/89)

In article <776@gumby.cc.wmich.edu> peirce@gumby.cc.wmich.edu (Leonard J. Peirce) writes:
>Something else that I have noticed with curses under 3.0 is the inability
>write in the last cell (bottom right-hand corner) of the screen.  Writing
>to it doesn't cause any problems; it just isn't displayed.  Perhaps a
>boundary condition in the curses code is incorrect.

This matches a problem with which I am wrestling at the moment, whilst
rewriting large chunks of the 3270 emulation program (to use termcap but
not curses: too slow). The VTxxx style emulators, even when in automatic
margins (wrap) mode, often do NOT scroll on the last character of a line, but
only when they get the first character of the next line. This means that
you can of course write the bottom right hand character without a scroll.
However, I can see no way that this capability can be deduced from any
termcap entry (other than the name). Of course, the question comes up as
to where the hell is the cursor when you do write the last character of the
line - it appears to hover over this character - and what happens if you
now do cursor control movements (left, right, up, down, destructive
backspace) or other escape sequences based upon the cursor position (clear
to end of line).

You can also add to this the unfortunate fact that a termcap entry
apparently cannot even deal with a VTxxx escape sequence for moving the
cursor right n positions (it only has ch, which is for both directions, but
they are different sequences). I need this for efficient rewriting of a
line which is similar to what is already on the screen (and did you ever
notice that refresh is liable to switch back into non-standout mode, generate
a cursor move sequence and switch back into standout mode all because a
single character in a line was already correct! If you want a mod to refresh
to avoid that then ask me).

Beyond that, and as noticed in some other news group (but I forget where),
there is the requirement for extra goodies such as colour. I would like
to know if a terminal can support colour, and if so then what are the
sequences for switching to various colours.

All in all, a sort of extended set of termcap definitions might seem
necessary. I could frig things for my emulator mods, but that might be
reinventing the wheel. Surely someone has already attacked this problem!
-- 
 _ _  o |             __                    |    jmg@cernvax.uucp
| | |   |     _      /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)     |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___    \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland