Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!iuvax!news!tagore!dflahert
From: dflahert@tagore.helios.nd.edu (Dennis Flaherty)
Newsgroups: comp.sys.cbm
Subject: Re: DesTerm 128 v2.00 (bug report)
Message-ID: <416@news.nd.edu>
Date: 12 Sep 90 06:42:04 GMT
References: <57272@microsoft.UUCP> <1990Sep9.011304.1616@uoft02.utoledo.edu> <414@news.nd.edu>
Sender: news@news.nd.edu
Organization: PDP-11 Gurus Anonymous
Lines: 41

In article <414@news.nd.edu> I wrote:
> When the emulator is run initially, and whenever a
> menu is left, the emulator is placed in vt100 "bold" (escape
> sequence ^[[1m) mode.  Many applications (such as rn and more/less)
> put some characters in reverse video (^[[7m) and reset with ^[[m.
> This turns off the bold mode as well, making the following
> characters darker than what the user was used to.

I've found out the cause of this problem, so hopefully by
posting I'll save someone else some trouble.

In the User Environment menu, Char Colour can be selected to
choose the color of the characters in normal terminal-mode
communication.  The choices are black, blue, green, cyan, red,
purple, brown, and grey, and the "light" version of each of these.
Since all of these colors are supported by the 80-column video
chip, I had thought that "light cyan" would simply be color #4.
Not so.  Instead of using color #4, DesTerm uses #12, dark cyan,
and puts the emulator in "bold" mode.  As soon as it receives
the ^[[m sequence, the character color changes to dark cyan.
I suspect that the rest of the "light" colors are done this
same way.

So my recommendation is, unless this is fixed in a next release,
that the "light" versions of the colors should not be used for
character color, since they aren't distinct colors at all.

Another tip: if you find that by moving the cursor left, over
characters in applications like vi, causes characters to
misteriously disappear, change the backspace mode to
non-destructive.  In most operating systems, the destructive
behavior of the delete key in a command line is due to the
mainframe sending a backspace-space-backspace sequence, not
because the local terminal makes backspaces destructive.

I hope there's a patch to keep the program from begging 
for money all the time.
--
Dennis Flaherty              dennisf@ndcvx.cc.nd.edu
U of Notre Dame      Dept. of Electrical Engineering
  Notre Dame *tells* me what opinions to have.