Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!gatech!ukma!psuvm.bitnet!cunyvm!unknown
From: rrk@byuvax.bitnet
Newsgroups: comp.os.vms
Subject: Re: Using an ANSI emulator with VMS editors
Message-ID: <89rrk@byuvax.bitnet>
Date: 5 Mar 88 08:54:43 GMT
Lines: 51

I agree wholeheartedly...

SMG is garbage for programming of serious applications.  I tried for months
to get SMG to do lots of those low level things and finally gave up and
wrote my own screen handler with its own TERMTABLE type files (but much
more sophisticated, flexible, and efficient) so that I could (among other
things) read a whole slew of escape sequences in one QIO and then translate
them, and it wouldn't hurt either logic or efficiency if my QIO happened
to terminate in the middle of an escape sequence.  It also allowed me to
do lots of other things like perform some operation to the screen which
modified the screen external to the screen handler and then tell the screen
handler about this change on the PHYSICAL screen so that it could properly
know what was there for the next update without having to invalidate and
repaint what it didn't place there itself.  Another function I had to have
(and built into my own screen handler) was the ability to turn on hardware
insert mode and tell the virtual screen that it was on so that people could
insert text into the middle of a line without having to have the line repainted
with every keystroke.  I found no way to do this through SMG.  Another thing
that was very important, but lacking in SMG was the ability to imbed attribute
and positioning strings into the text.  If you store screens in files separate
from the main program, there is no easy way to imbed codes giving control
information to the screen such as cursor control or attribute changes like
bolding certain words.  I recognize that you can set the ALLOW ESCAPE flag
and theoretically send VT100 control codes through, but SMG choked on lots
of codes that a VT100 would have had no problem with, and the SMG documentation
discourages use of this flag and there are many things that still can't
be done in this way...

SMG is also very inefficient in the control codes it sends out. It wastes
lots of characters in many places.

Other essential features missing in SMG include:

A nice way to get SMG to batch things without the programmer having to call
begin_update and end_update everywhere.  The obvious solution here was to
make updates occur only at user input or when specifically asked for (via
a special code) or during forced delays.

Something to cause update to be disabled even during periods of input if
theuser gets ahead of the application, allowing the screen manager to skip
unnecessary screens until the application or baud rate catches up with the
user.

The concept of a set of SMG routines for use by applications designed to
be terminal independant is nice, but good design is a must.  I hope SMG
is scrapped or revamped in a major way in 5.0.  Otherwise, it is a sad excuse
for a screen handler, and without a real future.