chris@umcp-cs.UUCP (Chris Torek) (10/17/84)
* From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) > ... The only difference (problem) I've found so far is that > Crosstalk does not have/support the xn/xenl glitch in column > 80. It does wrap to the next line. This is easy enough to turn > off, but I've also discovered that if you're inserting text > into a line which wraps to the next line, the second line > doesn't get displayed correctly. There is a common misconception about the VT100 and the xn/xenl capability; ... The wrapping upon character insert is independent of auto-margin and is supposed to be described by the "in" capability. I think you're confused about what he's confused about, Doug. [That isn't confusing, is it? :-) ] You might be right about what VT100s should have in their termcap entries (but see below) but I don't think he was talking about :in:. Also, :in: says nothing about the C-100 behaviour (where insertion in the middle of a single line may make it become two lines), it merely says that insertion distinguishes non-written locations from blanks, and thus all blanks within each line must be written. Vi may also assume that it implies that insertion within a full-sized (80 characters or whatever your screen width is) line makes the line "split" over two screen lines, but I haven't seen this in any termcap documentation. Now back to the :am: & :xn: debate . . . :am: says that the terminal has auto margins; that is, after writing a character in column 80 (assuming an 80 column terminal) the cursor is in column 1 of the next line. :xn: says that after writing a character in column 80, one newline (CR/LF sequence really) will be eaten if nothing else is written. (This makes the terminal very nicely split long lines yet not put blank lines after lines exactly 80 characters long. It's a feature!) VT100s have neither behaviour. Instead, after writing in column 80, the cursor is in sort of a ``virtual 81st column''. If you put out a backspace, the cursor goes to column 80 (i.e., it doesn't move). Same for ESC[D. For ESC[C (cursor right) the cursor stays in col. 81. For any printing character, the cursor immediately moves to col. 1 of the next line, then you get the printing character (or tab) done, and then the cursor moves to col. 2. For line feeds and up & down motions in col. 81, the cursor moves to the next or previous line and col. 80. However, what vi does with a terminal with :xn: is that if the cursor gets to column 80 (or whatever), it writes a CR/LF, to satisfy the ``newline eater bug'' [hmmm ... sounds vaguely familiar :-) ]. Therefore, if you write your VT100 termcap to contain BOTH :am: and :xn:, vi should work. If you use NEITHER, then vi may (should!) assume that after writing a character in column 80, the cursor is still in column 80, and that therefore, a backspace should move it to col. 79! This is NOT what happens, so I think VT100 termcaps should have *both* :am: *and* :xn:. Now for my disclaimer: all of these features were tested out on a Datamedia DT80/1 terminal, not a true DEC VT100, but I believe that the internals are exactly the same (i.e., Datamedia is selling repackaged VT100s). -- (This mind accidently left blank.) In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690 UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
barmar@mit-eddie.UUCP (Barry Margolin) (10/18/84)
In article <368@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >VT100s have neither behaviour. Instead, after writing in column 80, >the cursor is in sort of a ``virtual 81st column''. If you put out a >backspace, the cursor goes to column 80 (i.e., it doesn't move). Same >for ESC[D. For ESC[C (cursor right) the cursor stays in col. 81. For >any printing character, the cursor immediately moves to col. 1 of the >next line, then you get the printing character (or tab) done, and then >the cursor moves to col. 2. For line feeds and up & down motions in >col. 81, the cursor moves to the next or previous line and col. 80. > >In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690 >UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris >CSNet: chris@umcp-cs ARPA: chris@maryland I believe that this is not the case for VT100's, although it would be nice if it were. When the cursor is in the "virtual 81st column" it is displayed in the "physical 80th column". If you then backspace (and presumably also when you use the cursor-left escape sequence) you end up in the 79th column (physical AND virtual). I also use Honeywell VIP terminals at work; they do it right (one of the few things that VIPs do right). -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
dsp@ptsfa.UUCP (Dave St.Pierre ) (10/18/84)
> * From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) > There is a common misconception about the VT100 and the xn/xenl > capability; ... The wrapping upon character insert is > independent of auto-margin and is supposed to be described by > the "in" capability. Hmmm ... Then I guess the documentation in terminfo(4) is in error (see Glitches and Braindamage, SV_R2). Also, termcap comes with a rather lengthy discussion on pros and cons. I COULD turn off am/xn; I have to for an emacs I have which doesn't know about the vagaries of vt100's on column 80. I leave it turned on when possible since our default initialization sequence turns on autowrap mode - it gets difficult reading long lines of text when it's all beating on the last column. Televideo 970's appear to be the same as vt100's, TTY 5420's do wrap "correctly", even though they're otherwise vt100 clones. I don't remember what my vt400 did, think it needed xenl. :in: doesn't really seem to be applicable to this problem or this terminal class at all. I've tried various combinations of am/mi/xn and run vi xxx > xxx.out;od -c xxx.out to see what's happening. All terminals issue cursor movement sequences when a line "wraps" in vi in standout mode to get to the next line. If "mi" is off it turns on insert mode and places the character at the beginning of the line; otherwise it just emits the character. Crosstalk just refuses to push ANY characters over to the right on the second line. There's supposed to be a new version of XTALK XVI out soon. Maybe this will be fixed. Or maybe I'll find out it's a feature. Nothing I was able to change in termcap/terminfo seemed to fix the problem. What I thought was more interresting was that the software really does support insert/delete modes. It makes windowing applications bearable. Thanks for all the discussion so far. I should note that I'm on vi 3.9, SV_R2. If anyone really comes up with a fix to termcap, please post it.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/18/84)
My original statements about am, xn, in, and the VT100 were correct. The termcap manual entry makes a big deal about how "in" couples together the two insertion behaviors that really should be separate attributes.
chris@umcp-cs.UUCP (Chris Torek) (10/19/84)
Ok, then that just means that DT80/1s are *not* the same as VT100s.
(They're actually pretty nice....)
--
(This mind accidently left blank.)
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandgwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/19/84)
> Hmmm ... Then I guess the documentation in terminfo(4) is in error > (see Glitches and Braindamage, SV_R2). Very definitely the SVR2 TERMINFO(4) is wrong. To quote: Terminals which ignore a linefeed immediately after an "am" wrap, such as the Concept and vt100, should indicate "xenl". The description does not fit the VT100 (I don't know about the Concept). > I leave it turned on when possible since our default initialization > sequence turns on autowrap mode - it gets difficult reading long lines > of text when it's all beating on the last column. I wasn't recommending against enabling the VT100's auto-wrap feature. I WAS recommending leaving it out of the termcap/terminfo description.