Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!wjh12!harvard!seismo!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.info-terms Subject: Re: vt100, :am:, :xn:, :in: Message-ID: <368@umcp-cs.UUCP> Date: Tue, 16-Oct-84 21:19:24 EDT Article-I.D.: umcp-cs.368 Posted: Tue Oct 16 21:19:24 1984 Date-Received: Sun, 21-Oct-84 10:21:23 EDT References: <459@uwvax.UUCP> <5084@brl-tgr.ARPA> <194@bragvax.UUCP> <297@ptsfa.UUCP> <5339@brl-tgr.ARPA> Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 64 * From: gwyn@brl-tgr.ARPA (Doug 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