forrest@blia.BLI.COM (Jon Forrest) (01/23/87)
Could someone summarize the bug with vt100 terminals having to do with line wrapping. I recall it has something to do with what happens when a certain character appears in column 79 (80?). Thanks, Jon Forrest ucbvax!mtxinu!blia!forrest
colin@vu-vlsi.UUCP (01/23/87)
In article <1504@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >Could someone summarize the bug with vt100 terminals having >to do with line wrapping. I recall it has something to do with >what happens when a certain character appears in column 79 (80?). It's not a bug, it's a feature! Honest. First off, this only applies when line wrap is set on in SETUP. Here goes: The behavior is that when a character is printed in column 80, most terminals advance the cursor to column 1 of the next line. The vt100 and its descendants don't do this--they just make an internal note somewhere that the cursor _should_ be on column 1 of the next line; the blinking cursor is left where it was, in column 80. Now if a printable character arrives next, it is put in column 1 of the next line, and the cursor is advanced to column 2, just the way line wrap behaves on most "normal" terminals. However, if a newline arrives next (carriage return followed by line feed) the cursor winds up in column 1 of the next line, not two lines down as you'd expect on "normal" terminals... Why this behavior? Well, for one reason, it allows the last character position on the screen (line 24 column 80) to be used. Also, it works pretty well when just dumping lines of text to the screen separated by newlines (e.g. the VMS TYPE command): lines of exactly 80 characters will look fine, rather than leaving an extra blank line following... I hope this helps! -Colin Kelley ..{cbmvax,pyrnj,psuvax1,bpa}!vu-vlsi!colin
gwyn@brl-smoke.UUCP (01/24/87)
In article <1504@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >Could someone summarize the bug with vt100 terminals having >to do with line wrapping. I recall it has something to do with >what happens when a certain character appears in column 79 (80?). Ok, here is a summary of what I am aware of about this. The VT100 designers thought that it would be nifty if upon receipt of the 80th character in a line during normal "glass tty" operation, the cursor would stay positioned on top of the 80th character instead of immediately scrolling a line the way most auto-wrap features do. I think their rationale was two-part: first, that normally a carriage-return, line-feed would follow, which would result in double-line spacing (unless special handling were given to CRs just after an auto-wrap, as I believe some newer terminals do); second, sometimes output is "overstruck" (intended for printers), and auto-wrap would mean that overstrikes would appear on separate lines (again, unless special CR-after-auto-wrap handling were used); note that these are essentially the same phenomenon. In any case, the internal firmware implementation (running on an 8085, I think) sets a flag to keep track of the state when the 80th column is printed. Unfortunately, under some circumstances the flag is not properly handled by the firmware; this is most often seen when cursor positioning is done to place characters in columns 80 and 1 of various rows (eventually some end up in the wrong places). The only know fix for this is to treat the screen as only 79 characters wide (co#79 in termcap). A related problem is that many VT100 termcap descriptions I have seen specify "am" for the VT100. This is absolutely wrong and should be removed; if present, software is entitled to assume that immediate (not deferred) auto-wrap occurs, which can cause it to make errors in updating the VT100's display, since deferred wrap doesn't act the same as real wrap under all circumstances.
scott@tg.UUCP (01/24/87)
In article <1504@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >Could someone summarize the bug with vt100 terminals having >to do with line wrapping. I recall it has something to do with >what happens when a certain character appears in column 79 (80?). > >Thanks, >Jon Forrest I'm not sure why this happens, but I ran into this when I started my current job and got my hands on a REAL VT100. However, the fix I found for this, which works on the VAX in my office running 4.1bsd (no flames on 4.1 please, I have been waving the 4.3 banner since I got the license to be signed). I configure the terminal to line-wrap and set the termcap entry that the terminal does not have hard margins (I don't remember the code off hand). It seems to work, for me at least :-) ! Scott Barman philabs!tg!scott
wsr@lmi-angel.UUCP (01/26/87)
In article <1504@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >Could someone summarize the bug with vt100 terminals having >to do with line wrapping. I recall it has something to do with >what happens when a certain character appears in column 79 (80?). It sounds like you are refering to the infamous 'xn' bug (the bug described by the 'xn' entry in termcap.) This is only a problem in line wrap mode (ie. if you are using the 'am' flag in your termcap, and have line wrap set on your terminal). The bug is that the cursor 'sticks' in the 80th column after you enter the 80th character. For forward motion the cursor is in the 81's column, eg. the next character will end up in the 1st column of the next line. For reverse motion (deleting and/or arrow keys) the cursor is in the 80th column, and the first deletion or other backwards motion takes you to the 79th column. Where you are depends on where you are going. (It's not a bug it's an undocumented feature !!) :-) What is sad, is that this bug was actually introduced (by some misguided fool) in an attempt to solve another problem. With line wrap on and the normal behavior on column 80, it would have been impossible to write the last character on the last line of the screen without the terminal scrolling. (Now it's impossible to write the last character on any line..... without lots of extra work.) Why I wonder, didn't they just leave it alone, and tell people to turn off line wrap? -- Wolfgang Rupprecht {harvard|decvax!cca|mit-eddie}!lmi-angel!wsr
george@mnetor.UUCP (George Hart) (01/27/87)
>In article <1504@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >Could someone summarize the bug with vt100 terminals having >to do with line wrapping. I recall it has something to do with >what happens when a certain character appears in column 79 (80?). I ran into this a few years ago while porting an editor to a V6 (yes he did say V6 :-) system. The bug can be demonstrated in the following way: 1. turn line wrapping on 2. using direct cursor positioning, place the cursor in the second to last column. 3. type a character 4. using direct cursor positioning, place the cursor in the first column of the next (or any line). 5. type a character Instead of the character appearing in the first column of the line you moved to in 4, it appears one line further down. It appears that earlier rev's of the VT100 firmware did not reset an internal flag used to indicate "wrap at the next character". I don't know if this bug still exists. -- Regards, George Hart, Computer X Canada Ltd. UUCP: utzoo >!mnetor!george seismo BELL: (416)475-8980
burj@iros1.UUCP (02/01/87)
From reading the termcap(5) manual entry and the comments in the
/etc/termcap file (on 4.2BSD systems), I gather that the "xn"
capability was originally intended for terminals like the Concept
which eat a newline immediately after wrapping: i.e. after 80th
character, cursor wraps to col. 1 of next line but doesn't move
down again if a newline comes next. With much gnashing of teeth
("all versions of vi before 3.7 don't handle xn right on vt100",
says the comment in /etc/termcap) the "xn" capability was modified
to work with vt100s.
But this is unnecessary maligning of the poor vt100. The vt100,
with wrap turned on or off in SET-UP, behaves just like a terminal
with no wrap at all, *as long as the program does not purposely
hammer against the right margin*. In particular, with wrap turned
on, vi works fine whether the termcap has "am" and "xn" set or not.
(Just don't set "am" without also setting "xn".)
The way I see it, the vt100 lets programs that do screen management
pretend that the terminal never wraps, leaving the choice of whether
to wrap or not while typing plain text entirely up to the user.
(I was rather surprised to see that the Ultrix termcap file lets
all the criticism stand. No one at DEC came to the defense of
their own terminal!)
In article <5559@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn) writes:
> A related problem is that many VT100 termcap descriptions I have
> seen specify "am" for the VT100. This is absolutely wrong and
> should be removed
It's no problem if "xn" is there as well. But why bother with two
separate termcaps (vt100-am and vt100-nam)? Why not, as Doug Gwyn
suggests, just drop "am" (and "xn") and put a comment in termcap
saying "vt100s work fine no matter how you set the wrap in SET-UP!"
justindave@lsuc.UUCP (02/02/87)
In article <121@lmi-angel.UUCP> wsr@lmi-angel.UUCP (Wolfgang Rupprecht) writes: > >What is sad, is that this bug was actually introduced (by some >misguided fool) in an attempt to solve another problem. With line wrap >on and the normal behavior on column 80, it would have been impossible >to write the last character on the last line of the screen without the >terminal scrolling. (Now it's impossible to write the last character >on any line..... without lots of extra work.) Why I wonder, didn't >they just leave it alone, and tell people to turn off line wrap? Yecch. That would be even worse. I use a VT-100 compatible terminal (Esprit 10/102) which supports this feature. Turning off line wrap would lose data every time I wanted to display something which goes beyond the end of the line (which happens all the time). Admittedly, the VT-100 feature (or bug, as you will) causes more work for people who write termcaps and the like, but I think it's a pretty neat way of using the last column. It's not just the last line -- it works on every line. From the ordinary user's point of view, the only time it's bothersome is when you want to erase char 80. David Sherman The Law Society of Upper Canada Toronto -- { seismo!mnetor cbosgd!utcs watmath decvax!utcsri ihnp4!utzoo } !lsuc!dave
gwyn@brl-smoke.UUCP (02/08/87)
In article <103@Mannix.iros1.UUCP> burj@iros1.UUCP (Justin Bur) writes: >... the "xn" capability was modified to work with vt100s. No, it wasn't. Don't believe everything you read. "xn" means that the terminal ignores a line-feed immediately after an auto-margin wrap, no more and no less. This does not correctly characterize the DEC VT100. >... In particular, with wrap turned >on, vi works fine whether the termcap has "am" and "xn" set or not. >(Just don't set "am" without also setting "xn".) No, no, no! I don't know whether "vi" happens to work, but the VT100 in general violates the simple model for auto-wrap assumed by termcap, as several people have discussed already. Its actual behavior is very state-dependent, and attempting to specify "am" exacerbates the problem. The VT100 does NOT behave in a way that could reasonably permit one to specify "am"; in particular, it has not wrapped after displaying the character in the last column, so its cursor is in the wrong place for an "am" terminal. (Sometimes the VT100 will compensate for this and sometimes it won't, but in any case the visual result is wrong.) The only complete solution for the VT100 is to NOT specify "am", and if you leave auto-wrap enabled (as most people do) then set "co#79", so that the VT100 firmware bug is not triggered. Don't get me wrong; I've been rather fond of VT100s, but they really do have a bug in their auto-wrap logic. - Douglas A. Gwyn 4.3BSD TERMCAP(5) editor (with assistance of others)
ado@elsie.UUCP (02/09/87)
> The only complete solution for the VT100 is to NOT specify "am", and if > you leave auto-wrap enabled (as most people do) then set "co#79", so > that the VT100 firmware bug is not triggered. A better solution, in use here at elsie for three years now: go ahead and leave auto-wrap enabled (as most people do), but *don't* set "co#79". Instead, set "ti=\E[?7l:te=\E[?7h". Doing this arranges things so that programs that do cursor motion turn off auto wrap when they start up and turn auto wrap back on when they finish. The advantage of the ti/te approach as opposed to the co#79 approach: you get an 80-column terminal rather than a 79-column one. -- VT-100 is a Digital Equipment Corporation trademark -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.
gwyn@brl-smoke.UUCP (02/11/87)
In article <7328@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >Instead, set "ti=\E[?7l:te=\E[?7h". ADO's suggestion is generally a good one, if you're willing to have auto-wrap turned on when you leave a visual program (even if it was off when you started). I suspect most people have no problem with this. Too bad there's no way to save terminal modes then restore them.
dave@lsuc.UUCP (02/11/87)
In article <103@Mannix.iros1.UUCP> burj@iros1.UUCP (Justin Bur) writes: > >(I was rather surprised to see that the Ultrix termcap file lets >all the criticism stand. No one at DEC came to the defense of >their own terminal!) Oh well, at least Ultrix removed the line saying "Mail changes to csvax:mark, csvax.mark@Berkeley or ucbvax!mark or lose them!". You'd be amazed how many UNIX systems still have this anachronism in them. (Hey Mark, do you still get termcap updates forwarded from ucbvax to cbosgd?) David Sherman The Law Society of Upper Canada Toronto -- { seismo!mnetor cbosgd!utcs watmath decvax!utcsri ihnp4!utzoo } !lsuc!dave