🚀 go-pugleaf

In article <4935@ingr.com> nik@ingr.com (Nik Simpson) writes:
>
>SVR3.1 version of pg behaves strangely when pressented with a file where the
>lines are exactly 81 characters long including the \n.  If your terminal is
>set to autowrap you will see this behaviour.  If the terminal is not set to
>autowrap then pg clearly fails to generate newlines so the document does not
>print sensibly.

There is nothing wrong with the way pg behaves (at least, not that I
can see).

pg uses the terminfo terminal information to determine how it should
act.  If your TERM environment variable is set to VT200, VT220, or
VT100 (among others), programs which use this information (pg, rn,
editors, etc.) will understand that your terminal has 'automatic
margins'.  Changing the terminal setup does not change terminfo's
understanding of your terminal capabilities.  If you want pg to know
that your terminal does not auto-wrap, you must set your TERM
environment variable to the name of a suitable terminfo definition.

The auto-wrap function of the DEC VTxxx-series does function in
exactly the way expected of the auto-margin capability of terminfo,
but that's another posting.

--
Guy "I am a VT220-nam32r" Streeter
ingr!b11!guy

In article <464@b11.INGR.COM> ingr!b11!guy (Guy Streeter) writes:
>The auto-wrap function of the DEC VTxxx-series does function in
>exactly the way expected of the auto-margin capability of terminfo,
>but that's another posting.

Excuse me, but it most certainly does not.
The VT100's margin wrap feature is exceedingly baroque and does
not match the model associated with termcap/terminfo "am" capability,
which describes a simple immediately-wraparound feature (the VT100
maintains internal state and defers wraparound until it thinks it
should have been done, but it gets confused by certain character
sequences).
VT100 termcap/terminfo descriptions should NOT specify "am" even if
the margin wrap option of the terminal is enabled.

In article <10038@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <464@b11.INGR.COM> ingr!b11!guy (Guy Streeter) writes:
>>The auto-wrap function of the DEC VTxxx-series does function in
>>exactly the way expected of the auto-margin capability of terminfo,
>
>Excuse me, but it most certainly does not.

That's what I get for not carefully proofreading my posting.  It was supposed
to say "... does _not_ function in ...".

The difference is that auto-wrap on the DEC VT-series will wrap if a
printable character or a space (but not a tab) is output with the cursor
at the rightmost edge of the screen.  Commands to move the cursor
forward will not cause wrap.  The terminfo/termcap "am" capability
implies that the wrap will occur in any case.

>VT100 termcap/terminfo descriptions should NOT specify "am" even if
>the margin wrap option of the terminal is enabled.

More specifically, the auto-wrap option of the VT terminal should be
turned off, and "am" not specified in termcap/terminfo, when a program
which uses curses is to be run.

--
Guy "I proofread this one, he said" Streeter
b11!guy@ingr.com
...uunet!ingr!b11!guy

In article <10038@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> The VT100's margin wrap feature is exceedingly baroque and does
> not match the model associated with termcap/terminfo "am" capability,
> which describes a simple immediately-wraparound feature (the VT100
> maintains internal state and defers wraparound until it thinks it
> should have been done, but it gets confused by certain character
> sequences).

VT100 deferred autowrap waits until it receives the 81st character
on a line before thinking about an autowrap.  If this character is
printable, wrap occurs before it is printed, but if the character is
a newline then it is only done once.

This "feature" lets you look at an 80-column card image without
getting the double spacing that immediate autowrap would cause.
Since many more of us read 80-column card images than use screen-
oriented editors, this is a good thing.

> VT100 termcap/terminfo descriptions should NOT specify "am" even if
> the margin wrap option of the terminal is enabled.

Some terminals (HDS, for instance) let you specify which kind of
autowrap you want to use, and System V terminfo (on the 3B2, at least)
lets you specify that this happens: look at "eat_newline_glitch" or
the capname "xenl".

We used to have all kinds of problems with our vt220-compatible
terminals, but when we set "xenl" and "am" together, it never messes
up anymore, except for all those bugs it puts in my C code :-).

     Steve

-- 
Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 
3B2-kind-of-guy   / friedl@vsi.com  / {attmail, uunet, etc}!vsi!friedl

"I'm making a fashion statement: I'm saying I don't know how to dress." - me

In article <1096@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes:
>VT100 deferred autowrap waits until it receives the 81st character
>on a line before thinking about an autowrap.  If this character is
>printable, wrap occurs before it is printed, but if the character is
>a newline then it is only done once.

No, that's the intention, but the actual VT100 implementation has
numerous glitches in its 8085 microcode.  As I said, the exact
behavior is exceedingly baroque.

>the capname "xenl".

That's an abuse of that capability; it still doesn't handle all the
VT100 weirdness because the exact internal state of the VT100
microcode is not and cannot be simulated in such simple terms.
Perhaps later VT models such as the VT220 are not quite so badly
broken (in other words, don;t quite emulate a VT100); I don't know.

We go through this discussion every couple of years.