nik@ingr.com (Nik Simpson) (04/12/89)
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. This behaviour was first observed on a Intergraph 3050 workstation running CLIX 3.1 which is the Intergraph Licensed version of AT&T SVR3.1. |----------------------------------------------------------------------| | | | Disclaimer | | The author denies any responsibility for | | anything you disagree with, He was on holiday at | | the time. | | | |----------------------------------------------------------------------| Nik Simpson Senior Systems Engineer System Technology Marketing Group Intergraph UK Ltd. ph +44-793-619999x333 (voice) ph +44-793-618508 (fax) UUCP : uunet!ingr!nik From HSV : ingr!nik (will be forwarded) From Europe : swndn!st_nik!nik Internet : nik@INGR.COM
guy@b11.INGR.COM (Guy Streeter) (04/12/89)
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
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/16/89)
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.
guy@b11.INGR.COM (Guy Streeter) (04/16/89)
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
friedl@vsi.COM (Stephen J. Friedl) (04/17/89)
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
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/17/89)
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.