chas@gtss.gatech.edu (Charles Cleveland) (07/12/89)
I reported here a problem with the new version of VLT (4.036) involving
problems with vi on a Sun when using the command "open a blank line after
this one and enter insert mode at its start" aka "o". This involves a
reverse scroll. Someone else reported a scrolling problem with 4.036 at
the end of an unrelated article but I don't know if its connected.
After the first brief description and capture file I sent to Willy didn't
allow him to reproduce the problem I got a hexifying program from him for
which he has a decoder (uuencode is not so good because his BitNet mail goes
through an IBM which has a tendency to swap certain characters and he has
to fix these up manually). I will happily send this hexifier to anyone with
VLT problems so you can submit complete bug reports (through me if necessary)
to Willy. I zoo'ed up an archive which included a more complete capture file,
and screen captures before and after the offending instruction,.... I sent
if off. I got no response.
Meanwhile Steve Walton sent me his VTPrefs.dat file, with which he'd had
no problems. I didn't either. After a brief stab at finding the difference
I sent him mine.
Next Monday morning (yesterday), I had a message from him saying that the
difference apparently was that I was using Normal Rendering mode and he was
using Quick (the story isn't quite over yet). I also got all my most recent
messages to Willy back as undeliverable. Steve had carbon-copied his last
message to me to Willy. I finally broke down and logged into an IBM mainframe
and used TELL through BitNet to see if I could get through that way
(apparently no problem, but Willy wasn't there at the moment).
This morning I heard from Willy. He'd apparently gotten all my stuff in spite
of the (apparently) undeliverable messages. Don't know if he got Steve's or
not. He couldn't reproduce the problem from the capture of my session but
realized what was happening from my screen captures (bizarre as they were).
He has fixed it (he thinks). He didn't say when we'd see v. 4.036+.
I asked if I should tell people to use Quick Rendering or just avoid Normal.
He said the bug was present in ALL rendering modes.
Maybe so. But Quick has been working great for me lately and if you've had
problems and are using another mode, TRY QUICK while you wait for the next
release.
MORALS
* Including screen captures in email bug reports may be a good idea. I
used Grabbit. I then had trouble finding a viewer that could handle
the overscan image. I finally used loadpic from the recent fish disk
with the HAM overscan pictures of cars. But I think loadpic has
problems with more normal images. (I sent Willy the executable to
loadpic too.) Check that your IFF file works with common viewers or
send one that it will work with.
* If anybody needs to send a binary file to Willy, I've got an encoder,
in C and as an executable, and will serve as intermediary.
* Steve and Willy are good guys.
* BitNet sucks and IBM's idea of a character set and how to interface
with the ASCII standard are jokes.
--
"Our vision is to speed up time, eventually eliminating it." -- Alex Schure
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430
UUCP: ...!gatech!gtss!chas INTERNET: chas@gtss.gatech.edu