🚀 go-pugleaf

It was recently suggested in net.news that VT100 escape sequences
be used to highlight text in news articles. That idea was justifiably
shot down because it would screw up many users' terminals.

The question of storing information in the form of ANSI 3.64 commands
and converting them with termcap is of great interest to me and goes
far beyond the issue of news postings.

I have designed and am maintaining a large CAI system which presently
contains modules which teach income tax law. During our experimental phase,
we have used VT-100 terminals (with the Advanced Video features), and I
found many of the VT-100 capabilities extremely useful in highlighting
and presenting information. Accordingly, I wired in these sequences
throughout the system, assuming I could deal with terminal independence
at a later time if the experimental project was successful.

I am now at the stage of preparing a conversion to a new UNIX system
which will support up to 30 users at a time, at least some of whom will
be using non-VT100 terminals. I have to make a fundamental decision as
to the best way of handling highlighting, cursor control and other visual
attributes. This decision will affect courses to be developed in other
areas of the law as well.

Highlighting (underlining, boldface, flashing, etc.) occurs in my
course in several ways:
	- in text files which are copied straight to the screen.
	- in lessons which are interpreted by a CAI interpreter
	  ("Calypso") at run-time. Text, questions and answers in
	  these lessons are copied to the screen and often contain
	  highlighting.
	- in complex quizzes which are written as C programs, e.g.,
	  printf("This looks \033[4mvery\033m underlined.\n");


I need a convenient standard for storing this information. As well
as highlighting, I occasionally use clear-screen commands and cursor
control in a rather minimal way. I also use double-width characters
in a few headers.

It seems to me that the ANSI 3.64 (as used by the VT100) sequences
provide a simple way to do this. As long as I am working on a VT-100,
text files will appear exactly as their final output will (even when
I'm creating or modifying them with an editor). Some conversion
mechanism is a must to let them run on other terminals; my preference
is to leave this conversion until the final output to screen, and only
do the conversion work if(vt100flag==0), so to speak. This can be
done in putc() in such a way as not to affect the rest of the package.

I asked on the net for programs which convert vt-100 sequences
to something termcap can use, and received useful programs from
four different people. I also received scathing attacks from
two people for planning on embedding VT100 sequences in my code.

=====================================================================
=  
=  I would like people's comments on this basic question: is it so
=  terrible to embed VT100 sequences into my code, and if so, what's
=  a better way? (Before you reply, read the below.)
=  
=====================================================================

MY REASONS (i.e., why I don't think it's such a bad idea):

1. ANSI 3.64 is an internationally recognized standard which
   many terminals follow. As long as I have to encode the information
   \somehow/, this seems as good a way as any.

2. One person has suggested nroff-like \fB, \fI and so on. Then
   what do I do for clear-screen, move-up-one-line, boldface *and*
   underlined at the same time, etc.? There is no standard convention
   I know of for these things which contains only ASCII-printable
   characters.  (Does anyone think using "^[" for ESC would be
   a good idea? Then the only translation for vt-100's at run-time
   would be to convert the two-char "^[" to 033. Has anyone tried this?)

3. As noted above, I don't have to use any kind of filter to read
   the text as I'm writing it in my editor (as long as I have a
   vt-100 to work on).

4. No computation/interpretation/translation is needed by the machine
   for the student who is on a VT-100 terminal.

5. All translation for students on other terminals is isolated in
   my revised "putc". The only change needed to all source which
   contains VT-100 sequences is "#undef putc" after the "#include <stdio.h>".
   Since putc is a standard stdio macro, this can be guaranteed to work on
   any UNIX system (my putc will, once it's finished, do whatever the putc
   macro in <stdio.h> would have done in the first place).

6. Once I implement a revision to putc() to handle all sequences properly
   and generate calls to termcap routines (or whatever), the next person
   to maintain/revise the code needn't worry about what terminal the user
   faces, or anything like that. The system *will* be terminal-independent.


OK, netters, what do you think? If the net can agree on a standard
for storing this stuff, I'm willing to follow it. I remain to be
convinced that ANSI 3.64 is not the best way.


Dave Sherman
The Law Society of Upper Canada
Toronto
-- 
 {allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!dave