Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!mit-eddie!uw-beaver!sumax!thebes!polari!tm
From: tm@polari.UUCP (Toshi Morita)
Newsgroups: comp.sys.apple2
Subject: Stuff
Keywords: ProTERM Eric
Message-ID: <2263@polari.UUCP>
Date: 31 Jul 90 14:40:19 GMT
Distribution: na
Organization: Seattle Online Public Unix (206) 328-4944
Lines: 52

nrunyon%peruvian.utah.edu@cs.utah.edu (Neil Runyon) writes:

>        I was contacted by Eric Mueller (the IIgs editor of 8/16) and he said
>that the first disk was not copyrighted, so they could distribute it, and
>give people an idea what they are all about, so it posting is okay.
>

Is this the same Eric Mueller that lived at 4-300 Williwaw Way at EAFB in
Alaska? I think it is...and if it's the same Eric then I'd like to get in touch
with him. I can be reached at 206-485-9544 for two weeks.
(Sorry to post this on net but my mail bounces 50% of the time)


greg@hoss.unl.edu (Hammer) writes:

>I'm having problems using ProTERM's scrollback buffer.  It seems that
>when in vt-100 mode (maybe others as well, I don't know) when a line is
>exactly 80 columns long, the program generates an unwanted blank line and
>continues on the line after the blank one.  (It shouldn't line-feed
>driver so that I can use vi without switching word-wrap modes, but while
>reading usenet messages, I want to scroll back and re-read parts of a
>message or capture it for reading offline, and I am annoyed that the line
>after the aforementioned blank line disappears from the scrollback
>buffer, and can't be recaptured other than re-reading the message and
>using the copy buffer (which also captures that --More-- prompt).

This is the ProTERM problem I complained about earlier - but some people
misunderstood and told me to turn off the word wrap mode or something.
ProTERM handles characters in the same fashion COUT does:
it performs a C/R immediately after printing on the 80th column.
This algorithm really isn't acceptable for a terminal program.
ProTERM should defer C/R until the next character to see if it really
needs it or not. Something like:

If (column == 81)
    if (char = 0x0d)
        Carriage_Return(); 
    else {
        Carriage_Return();
        putc(char);
        }
else
        putc(char);

(Apologies for any errors in pseudo-code)

The ESC character method of turning word-wrap on and off is unacceptable:
it's an attempt to use a feature to rememdy a inherent flaw in the terminal
program. 


tm@polari.UUCP