cedman@golem.ps.uci.edu (Carl Edman) (03/12/91)
In article <91070.161058WGLP09@SLACVM.SLAC.STANFORD.EDU> WGLP09@SLACVM.SLAC.STANFORD.EDU writes:
1. I'm checking into adding custom keymap support. Maybe...
I can always hope. :-)
2. I don't understand what you mean by "insert" mode. VLT supports
"inserts" as far as I know.
Again I do not know which party is at fault. Hence I will describe the
problem in detail so that the experts might enlighten me. I am using
HPUX 7.0, the standard curses library and a program using curses
running under HPUX. The program works just fine except for screen
glitches, all of them only happening using vt100 emulations (vt220
e.g. works just fine). I suspect that VLT is not at fault as it also
happens with other vt100 emulators.
All of them are of this type:
A line like this is sent to the output:
"Enter a password: "
This line arrives correctly and after entering the password the next
question should ask for the verification of the password on the same
line, but what appears is:
"Verify thessword: "
What curses apparently tried to do was to erase the old string "Enter
a" and insert "Verify the" instead. But "Verify the" instead simply
overwrites the old text including some text which should have been
kept on the screen. This is not surprising as VT100 terminals do not
have an insert mode.
I tried to trace this bug and decompiled the terminfo entry for vt100.
Quite correctly no 'eim' entry (for entry into insert mode for
terminals which support it) is supplied for vt100. In an effort to
find out what was going on I created a terminal type identical to
VT100 except for the existance of a 'eim' entry (which contained just
a bogus string) and used the program with it. Not surprisingly curses
tried quite correctly to use this bogus 'eim' string when outputing
the above example. What is not correct (as far as I understand) is
that curses tries to use insert mode even when the term info entry
does not mention it.
3. I don't know who's at fault. but since you're talking about RZ, you
must be talking about uploads, not downloads. Up = towards remote,
down = towards you. RZ is for receiving on the host, so it must be
an upload. Now that we're talking in the same terms, I still don't
know why it shouldn't work... 8) But in any case, xprzmodem is
Rick Huebner's baby...
Sorry, did I say downloads ? I meant uploads. Downloads work just
fine. I was not accusing anyone of the parties of guilt but either a)
VLT, b) xprzmodem, c) RZ, d) HPUX or e) me are at fault. I also think I've
heard this bug mentioned before in connection with VLT and ZModem.
"We hold that what one man cannot morally do, a million men cannot
morally do, and government, representing many millions of men, cannot
do." -- Auberon Herbert
Send mail to Carl Edman <cedman@golem.ps.uci.edu>WGLP09@SLACVM.SLAC.STANFORD.EDU (03/13/91)
Okay, I see. At any rate, send me a capture file of the offending
piece of display, and I'll fix it, whether or not it's VLT's fault.
(This is in regards to the "insert" problem). Send capture files in
hex please, uuencoded stuff gets clobbered by our mainframe's character
tables. Any hex will do... (Like type opt h).
Willy.
----------
Willy Langeveld - Bitnet: WGLP09 @ SLACVM - BIX: langeveld