jeff@cjsa.UUCP (C. Jeffery Small) (11/17/87)
I have had an annoying problem with vi on my 3b1 starting with Version 3.5 of the OS and continuing with 3.51. (I never noticed the problem back under Version 3.0). Occasionally, when I am editing a file with long lines (say 130 cols or more) or when I perform a join (J) of two lines to create a long line, vi will get very confused and loose track of its screen representation. The cursor will appear in one spot but vi thinks it is in another location or, at other times, the long lines will wrap around but the wrapped portion will be mangled in mysterious ways. This is very troublesome since you will delete one or more lines only to find that something else has disappeared. A ^L will repaint the screen correctly, but as soon as you scroll, vi gets confused once again. The really annoying part of this is that I can't make vi repeat this odd behavior in a uniform fashion. Sometimes it works just fine with a file of long lines - other times it acts up. This problem has occurred on more than one machine, so I don't believe that it is a hardware problem. This is occurring on the console with TERM always set to s4. I have never noticed a problem with lines which wrap around just a little (say 85-95 columns) and I have no explanation for this! I know that this is a little too "loose" of a problem to expect someone to track down the cause. However, has anyone else experienced any similar problems on their 3B1/unix-pc machines? -- Jeffery Small (203) 776-2000 UUCP: uunet!---\ C. Jeffery Small and Associates ihnp4!--- hsi!cjsa!jeff 123 York Street, New Haven, CT 06511 hao!noao!---/
ned@ghostwheel.UUCP (Ned Nowotny) (11/17/87)
In article <50@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >Occasionally, when I am editing a file with long lines (say 130 cols or more) >or when I perform a join (J) of two lines to create a long line, vi will get >very confused and loose track of its screen representation. The cursor will >appear in one spot but vi thinks it is in another location or, at other times, >the long lines will wrap around but the wrapped portion will be mangled in >mysterious ways. I have seen this problem, or one very similar to it, on a number of different systems and versions of UNIX. Generally, if wrapmargin ("wm") is non-zero, a join which results in a line of about the lengths you describe will be badly mangled. Many of the characters from the "joined" line are lost. If wrapmargin is zero, these problems do not seem to occur. My suspicion is that this is a fairly widespread vi bug. Ned Nowotny (ned@ghostwheel.aca.mcc.com.UUCP)
robert@pttesac.UUCP (11/18/87)
I dont know about the problems with long lines, but has anyone figured out how to get the screen to flash instead of beep ? God, I hate the bell on the UNIX-PC!
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/19/87)
In article <50@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >Occasionally, when I am editing a file with long lines (say 130 cols or more) >or when I perform a join (J) of two lines to create a long line, vi will get >very confused and loose track of its screen representation. This sounds like a long-standing problem in vi (which I work around by keeping my lines on the screen). The vi line buffer seems to be a fixed length, I believe 128. Longer lines can be accomodated by some other mechanism; but if the line becomes exactly 128 ... or is it 127 ... the works get gummed up. Also, as someone mentioned, if you have your wrapmargin set and try to do "interesting" things with joining lines, vi may lose it completely. Joe Yao jsdy@hadron.COM (not yet domainised) hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM} att,blkcat,cos,decuac,dtix,ecogong,phw5,\ inco,insight,itc3b2,kcwc,netex,netxcom, >!hadron!jsdy empire,rlgvax,seismo,smsdpg,sundc,uunet /
kevin@ttidca.TTI.COM (Kevin Carothers) (11/19/87)
>In article <50@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >>Occasionally, when I am editing a file with long lines (say 130 cols or more) >>or when I perform a join (J) of two lines to create a long line, vi will get >very confused and loose track of its screen representation. >I have seen this problem, or one very similar to it, on a number of different >systems and versions of UNIX. Generally, if wrapmargin ("wm") is non-zero, a >join which results in a line of about the lengths you describe will be badly >mangled. (...) I have had a lot of luck in cleaning up vi on our particular version of UNIX (*) by taking out the /etc/termcap boolean "xn" on a vt100 type terminal. The article failed to mention if UNIX was running native on the PC (SCO Corp. ?) or via Smartterm. Also, make sure that on vt100's that the terminal has "wraparound" mode set. Otherwise your source file turns into a horror show. Toodles Kevin Carothers (*) ------------------------------------------ UNIX is a trademark of AT+T, the last time I heard.
ned@ghostwheel.UUCP (11/20/87)
In article <113@ghostwheel.UUCP> ned@ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes: >In article <50@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >>Occasionally, when I am editing a file with long lines (say 130 cols or more) >>or when I perform a join (J) of two lines to create a long line, ... > >Generally, if wrapmargin ("wm") is non-zero, a >join which results in a line of about the lengths you describe will be badly >mangled. Many of the characters from the "joined" line are lost. If >wrapmargin is zero, these problems do not seem to occur. My suspicion is that >this is a fairly widespread vi bug. Pardon my faulty memory. The problem I described occurs when "putting" (Pp) deleted or yanked text into a line when wrapmargin is non-zero. If the line created is longer than some amount, it becomes mangled. This is true of every implementation of vi that I have used, but I have not encountered the problem with joining lines. Ned Nowotny (ned@ghostwheel.aca.mcc.com.UUCP)
flaps@dgp.toronto.edu.UUCP (11/24/87)
In article <50@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >[with long lines] >A ^L will repaint the screen correctly, >but as soon as you scroll, vi gets confused once again. The Aztec C compiler for the Amiga comes with an editor called "Z" which is basically vi. It has this bug sometimes too with long lines, mostly when they're at the bottom of the screen. Interestingly, it displays a completely meaningless (to me) warning "cur past bot" when this happens. So whenever I see "cur past bot" I know to press ^L. Too bad they didn't just repaint the screen rather than displaying this message... ajr
bart@reed.UUCP (Bart Massey) (11/25/87)
In article <1475@ttidca.TTI.COM> kevin@ttidcb.UUCP (Kevin Carothers) writes: > I have had a lot of luck in cleaning up vi on our particular version of > UNIX (*) by taking out the /etc/termcap boolean "xn" on a vt100 type > terminal. The article failed to mention if UNIX was running native on the > PC (SCO Corp. ?) or via Smartterm. Also, make sure that on vt100's that > the terminal has "wraparound" mode set. Otherwise your source file turns > into a horror show. On a genueene Dec VT one-hunnert or two-hunnert series ternimal, don't do this, but many emulators will require it. The "xn" termcap entry indicates the magic DEC wrapmargin feature: when you get to column 80, do not advance the cursor past it (wrapping) until the next character is sent. Then wrap the character. If the character you're wrapping is a newline, eat it, so that you don't get the effect of two newlines. Most terminals and programs that try to emulate this get it wrong. The classic is to just punt and do normal wrapping. For these emulators, the termcap entries given above ("am:@xn") are correct. Bart
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/26/87)
In article <7793@reed.UUCP> bart@reed.UUCP (Bart Massey) writes: >The "xn" termcap entry indicates the magic DEC wrapmargin feature ... No! The VT100 right-margin behavior is NOT correctly described by "xn"; there is NO correct way to completely characterize the VT100's right-margin behavior, which is much weirder than most people realize, solely by means of combinations of termcap capabilities. Here is the VT100 termcap entry we use at BRL; note that it specifies neither "am" nor "xn": # # DEC VT100 # The "vt100" entry supports the Advanced Video Option if present; # however, AVO is not required for correct operation of the "vt100" entry. # The following SET-UP modes are assumed for normal operation: # ANSI_MODE AUTO_XON/XOFF_ON NEWLINE_OFF 80_COLUMNS # Other SET-UP modes may be set for operator convenience or communication # requirements; I recommend # SMOOTH_SCROLL AUTOREPEAT_ON BLOCK_CURSOR MARGIN_BELL_OFF # SHIFTED_3_# WRAP_AROUND_ON # Unless you have a graphics add-on such as Digital Engineering's VT640 # (and even then, whenever it can be arranged!) you should set # INTERLACE_OFF # Hardware tabs are assumed to be set every 8 columns; they can be set up # by the "reset" or "tabs" utility (use vt100-x, 132 columns, for this). # I have included some compatible code in "rs" for the VT640 if you have one. # No delays are specified; use "stty ixon -ixany" to enable DC3/DC1 flow control! d0|vt100|DEC VT100:\ :ae=^O:as=^N:bl=^G:cd=\E[J:ce=\E[K:cm=\E[%i%d;%dH:co#80:cr=^M:\ :cs=\E[%i%d;%dr:ct=\E[3g:DO=\E[%dB:do=^J:ho=\E[H:is=\E<\E)0:it#8:\ :k0=\EOP:k1=\EOQ:k2=\EOR:k3=\EOS:kb=^H:kd=\EOB:ke=\E[?1l\E>:kl=\EOD:\ :kr=\EOC:ks=\E[?1h\E=:ku=\EOA:l0=PF1:l1=PF2:l2=PF3:l3=PF4:LE=\E[%dD:\ :le=^H:li#24:ll=\E[24H:mb=\E[5m:md=\E[1m:me=\E[m:mr=\E[7m:ms:nd=\E[C:\ :nw=\EE:rc=\E8:RI=\E[%dC:\ :rs=^X\E<\E2\E[?9h^]\E^L^X\E[20l\E[?3;9;6l\E[r\E[m\E[q\E(B^O\E)0\E>:\ :sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:ue=\E[m:UP=\E[%dA:\ :up=\EM:us=\E[4m:vt#3:xo:\ :cl=\E[H\E[J:\ :bs:kn#4:pt: d8|vt100-w|DEC VT100 with AVO in 132-column mode:\ :co#132:\ :rs=^X\E<\E2\E[?9h^]\E^L^X\E[20l\E[?9;6l\E[?3h\ \E[r\E[m\E[q\E(B^O\E)0\E>:\ :tc=vt100: d9|vt100-x|DEC VT100 without AVO in 132-column mode:\ :li#14:ll=\E[14H:\ :tc=vt100-w:
caf@omen.UUCP (Chuck Forsberg WA7KGX) (11/26/87)
In article <7793@reed.UUCP> bart@reed.UUCP (Bart Massey) writes: :In article <1475@ttidca.TTI.COM> kevin@ttidcb.UUCP (Kevin Carothers) writes: :> I have had a lot of luck in cleaning up vi on our particular version of :> UNIX (*) by taking out the /etc/termcap boolean "xn" on a vt100 type :> terminal. The article failed to mention if UNIX was running native on the :> PC (SCO Corp. ?) or via Smartterm. Also, make sure that on vt100's that :> the terminal has "wraparound" mode set. Otherwise your source file turns :> into a horror show. : :On a genueene Dec VT one-hunnert or two-hunnert series ternimal, don't do :this, but many emulators will require it. The "xn" termcap entry indicates :the magic DEC wrapmargin feature: when you get to column 80, do not advance :the cursor past it (wrapping) until the next character is sent. Then wrap :the character. If the character you're wrapping is a newline, eat it, :so that you don't get the effect of two newlines. : :Most terminals and programs that try to emulate this get it wrong. The :classic is to just punt and do normal wrapping. For these emulators, the :termcap entries given above ("am:@xn") are correct. If you need a shareware emulation that gets "xn" right, as well as being compatible with aggressive vt100 termcaps that use set scrolling region, take a look at ZCOMM, available on TeleGodzilla and some other BBS's. ZCOMM also supports euper EGA boards in their higher resolution modes such as 132x44, etc. Chuck Forsberg WA7KGX Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ ...!tektronix!reed!omen!caf Omen Technology Inc "The High Reliability Software" 17505-V Northwest Sauvie Island Road Portland OR 97231 VOICE:503-621-3406:VOICE TeleGodzilla BBS: 621-3746 19200/2400/1200 CIS:70007,2304 Genie:CAF omen Any ACU 2400 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly
jeff@cjsa.UUCP (C. Jeffery Small) (11/28/87)
I want to extend my thanks to everyone who responded to my question about long lines (over 130 chars.) causing screen confusion on the UNIX-pc. To summarize the responses I received, it appears that this is a problem with vi itself and not specific to the UNIX-pc. I received reports of this same disturbing behavior from people on a variety of machines from PCs to NCR to Altos to VAXes. Some people suggested that if wrapmargin is on, this will cause no end of trouble when joining long lines. That was a good point however, wrapmargin has been set to 0 in my case. While no conclusive fixes were provided, the consensus of opinion is that you _MAY_ be able to do something about the problem if you fiddle with the "cm" or "xn" entries in termcap. As I previously mentioned, I became aware of the problem on this machine when I upgraded from OS version 3.0 to 3.5. I would be interested in taking a look at the differences in the termcap entries for the S4 terminal for these versions and I still plan to scan through my V-3.0 diskettes one of these days to locate the old termcap file. To speed things along, if someone reading this still happens to be running 3.0, I would appreciate it if you could mail me a copy of the S4 entry for comparison. Thanks. -- Jeffery Small (203) 776-2000 UUCP: uunet!---\ C. Jeffery Small and Associates ihnp4!--- hsi!cjsa!jeff 123 York Street, New Haven, CT 06511 hao!noao!---/
jdemer@watson.bcm.tmc.edu (Joseph L. Demer) (12/03/87)
In article <50@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: >[with long lines] >A ^L will repaint the screen correctly, >but as soon as you scroll, vi gets confused once again. 2.{9,10} Bsd vi has the same problem. However, it doesn't redraw correct- ly with ^L. I use ':p' or something similar to cause vi I to print "press return to continue" - the screen is okay after that. The problem is caused when a character in the last column of the line at the bottom of the screen causes an autowrap. At least for my version of Unix, if there is white space at the end of the line, the problem does not occur. It seems it should be possible to fiddle with the auto- wrap on the terminal, or else with the autowrap field of the termcap, to fix the problem, but I have had no luck. - Brad Daniels biff@eyeball.ophth.bcm.tmc.edu Once again using Joe Demer's account
mired@ihlpg.UUCP (12/04/87)
I would like to know if anyone at AT&T Bell Laboratories, Naperville Ill knows what type of system hardware we work on. Or where I can find out without spend- ing too much time.