EMACS vs. reverse video
Steve Zimmerman
various EMACSes, there are two types of reverse video that cause
problems. The first is that used by the hp's, which is denoted by the
"xs" capability. As Warren Montgomery pointed out, the only way to
clear out reverse video from a location on such a terminal is to send a
"clear line" sequence somewhere in the line before that location. This
is a side effect of the fact that in these terminals reverse video is an
attribute associated with the screen location, not with the character as
in most terminals. Another side effect of this is that if the terminal
also supports character insert, inserting a character on a line
somewhere in front of a reverse video character (such as a highlighted
mark) will cause the following characters to shift down normally, but
the reverse video mark will stay firmly rooted, thereby highlighting the
previous character. The solution is not to use character insert on
these terminals when there is a reverse video character farther down the
line, but instead to clear out the rest of the line and redisplay it
with the reverse video character properly positioned.
The second type of problem terminal is typified by the Televideo; these
terminals all have the "sg" capability. The terminal automatically
inserts one or two spaces on the screen whenever it turns reverse video
on or off; these spaces are actually used to store the information that
the display mode is changing as of the next character, and it is
impossible to get around their presence. As most programs cannot
tolerate extraneous spaces in the display like this, the reverse video
mode on these terminals is essentially useless. Generally, the proper
thing to do is simply for programs not to use reverse video on terminals
where "sg" is present.
Steve Zimmerman
{decvax,linus}!cca!z
ch...@umcp-cs.uucp
4025 in workspace & HP 262x/264x) inserting a character *does* push
the attribute over in the screen. The Tek (and probably the HP)
uses something called a "display tracker" which wanders through
screen memory, interpreting special codes. One of these is for
"start enhancement mode <x>". When you insert a character, the
insertion moves the "start enhancement" code one space to the right,
moving the attribute on the screen.
Also, (again at least on the Tek & HP) you can get rid of the
highlighting without using clear to end of line. Just write a new
highlight code at the same position as the old one. This is how my
windows driver for HPs works.
The easiest way to get around the Televideo type "magic cookie" glitch
is (as Steve Zimmerman said) to not use standout. However, it is
possible to deal with this kind of inverse video, as long as you aren't
trying to mix inverse video and normal characters on the same line, by
noting that one or two "spaces" are there and that cursor motion must
be adjusted, and that the line is shorter than it would be normally.
(If you're in the market for terminals, beware the magic cookie type.
There's an Intel display controller (I can't remember which one) which
seems to be the major reason for the existence of the magic cookie
glitch.)
(Speaking of glitches: the 4025 also has codes for "no-op" and
"anti-no-op" and jump instructions. It's very easy to load up enough
JUMP instructions to get the display all screwed up because the tracker
can't keep up. If you get the long sequence behind a NOP or ANOP the
screen starts to bounce up and down. If you're on a 4025, try (<R> =
return):
!wor 10 h<R>!att e-s<R>a!att s-e<R>b!att e-s<R>c!att s-e<R>d (etc)
With enough of those the screen will start to jiggle about and
you may get cursors on every line. Fun, eh?)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relay