geoff@desint.UUCP (Geoff Kuenning) (10/20/84)
Let me see if I can summarize the various flavors of terminal autowrapping I
have seen or seen described (terminology is my own; I invite more reasonable
suggestions):
(1) NO WRAP WHATSOEVER. When the cursor reaches column 80, it stays
there, no matter what. Subsequent characters overwrite column 80.
CR/LF produce the same behavior they would on a terminal of infinite
width, given the same character stream.
(2) "LAZY" AUTOWRAP. When a character is written in column 80, the
cursor immediately wraps to the following line. CR/LF produce the
same behavior you would get on a terminal of infinite width if the
cursor were in the same column at the moment of receiving CR/LF.
The disadvantage of this approach is that you cannot write line 24,
column 80 (okay, 66/80 for you lucky ones with *usable* terminals)
without scrolling the screen.
(3) "SINGLE-SPACED" AUTOWRAP. When a character is written in column 80,
the cursor remains there, but an internal flag is set. If the next
character received is a printing character, the cursor is wrapped
BEFORE the character is written to the screen (on column 1 of the
following line). This has two advantages: you can write 24/80
without scrolling the screen, and 80-character lines do not show up
double-spaced. Of course, from an editor's point of view this
behavior can be thought of as eating the newline that follows an
80-character line; hence "eat_newline_glitch". (But see #4).
There has also been discussion on the net of various ways a
terminal can respond to leftwards-motion commands when the cursor
is in column 80 with the flag set. This can either work exactly
like there really was a column 81 ("virtual column 81"
implementation) or in can work like the cursor was in column 80
with the flag clear ("no column 81" implementation). In any case,
it appears that there is no way to set the internal flag without
actually writing a character in column 80, and it is cleared as
soon as you leave (physical) column 80 by any horizontal motion.
My terminal (not a vt100) does *not* clear the flag if you give it
vertical motion commands, including "<esc>[12;80H"; on other
terminals the flag may be cleared in this case.
(4) "BRAINDAMAGED SINGLE-SPACED" AUTOWRAP. Operates like #2, "lazy"
autowrap, except that an internal flag is set that causes an
immediately following newline to be ignored. I have never
personally encountered a terminal that does this, but I infer
from termcap(5) [or wherever your version of Unix puts it] that
this is the behavior that is referred to by the "xn" capability.
This differs from #3 above in that you cannot write 24/80 without
scrolling the screen.
Note that there are a lot of variations here, especially when you consider the
sub-variations of #3. Technically, since :am: and :xn: are both Boolean,
we could encode four states, but we would be stretching the meaning of the
capabilities by a lot, and we still wouldn't be able to handle the
sub-variations in #3.
My suggestion is to give up on this theory that a full-feature termcap
program (with vi as the obvious example) should be able to make *full* use
of *every* terminal in the most optimal fashion possible. It's really neat
that vi will run at 300 baud without sending any excess characters acrossnaiman@pegasus.UUCP (Ephrayim J. Naiman) (10/23/84)
> Finally, if :am: is set but :xn: is *not* set, you should > assume that you cannot safely write line 24, column 80. (Although, on a > terminal with reverse scrolling, you can actually get a character into that > position by writing the line on line 23, reverse-scrolling it into line 24, > and then painting or correcting the rest of the screen as appropriate. Yuck.) Another way, would be to put the character to be written into the 80th column of the 24th line into the 79th column and using insert_char_mode, if the terminal has it, to move it into the 80th column. I think will be implemented in some later version of curses. -- ==> Ephrayim J. Naiman @ AT&T Information Systems Laboratories (201) 576-6259 Paths: [ihnp4, allegra, hogpc, maxvax, cbosgd, lzmi, ...]!pegasus!naiman
mark@cbosgd.UUCP (Mark Horton) (10/23/84)
What an amazing amount of information and misinformation! Here's the real story. From termcap and terminfo's point of view, there are three ways that terminals wrap. (1) Auto-margins. When you pass column 80 (or cols, actually) the cursor goes back to the beginning of the next line. This scrolls the terminal if you're on the bottom line. This terminal has am. (2) No auto-margins. The cursor hammers on the right margin no matter how much you output. This terminal has neither am nor xenl. This includes the VT100 with the auto-newline flag clear (e.g. vt100-nam). (3) Eat-newline-glitch. This includes the Concept 100, Concept 108, and the VT100 when the auto-newline flag is set (vt100-am.) On this terminal, when you output something in column 80, it goes into a funny state, and if you output a CRLF immediately it eats the CRLF and otherwise acts like (1). If you do anything else while in this state, the action is undefined. (In particular, the Concepts put the cursor on the next line while in this state, the VT100 leaves it on the previous line.) Such terminals have am and xenl (that's am and xn on termcap.) As far as I know, the SVR2 manual page is correct. The Concepts also have in, but that's a different glitch. Strictly speaking, this isn't quite true - the VT100 does not clear the funny state until you actually send it a printing character, so if you do certain things (e.g. go to col 80 of the NEXT line and output a char) you get weird behavior. I don't know how to get around this problem. Some VT100 clones have xenl, some don't. As far as I know, the Datamedia version is a perfect clone except that it is said to need less padding. As to people who want a 99% solution with 10% of the code, I wish you the best of luck. Curses one problem is that the code is rather large, around 30K. I don't recommend running my version on a 16 bit machine. However, the great majority of applications run on 32 bit machines these days and 30K is no big deal. For those of you running on, say, an IBM PC, there is nothing to prevent a special purpose back end from being written that has the same function call interface as curses but only works on the PC screen - it could be very small and simple. Doug Gwyn points out that if you have a VT100 with the auto-newline flag set, and use TERM=vt100-nam, things work. I have not tried this but it seems like it should work. Mark Horton
henry@utzoo.UUCP (Henry Spencer) (10/26/84)
> As to people who want a 99% solution with 10% of the code, I wish you > the best of luck. ... Actually, a 99% solution with virtually no code is to set up your screen-oriented programs so they simply *don't* *use* the last column of the screen. Sure, it's a waste, but in practice it seldom bothers people. The U of T paginator program, "p", wrapped lines one character short for just this reason, and it was years before anybody noticed. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
rh@mit-eddie.UUCP (Randy Haskins) (11/01/84)
> > As to people who want a 99% solution with 10% of the code, I > > wish you the best of luck. ... > > Actually, a 99% solution with virtually no code is to set up > your screen-oriented programs so they simply *don't* *use* the > last column of the screen. Sure, it's a waste, but in practice > it seldom bothers people. The U of T paginator program, "p", > wrapped lines one character short for just this reason, and it > was years before anybody noticed. > Yeah, that's what I've done in a file-viewing program I'm writing for a DEC-20. I've since become more sensitive to the problems of dealing with files that have lines wider than the screen. Don't forget that you can't just spit out W-1 characters, because some of those characters may be Tabs. Also, you have to keep track of when you do lines that take up more than one line on the screen so that you don't try to put too many on the screen. And I just wanted a little program to look at files bigger than those Emacs could deal with.... -- Randwulf (Randy Haskins); Path= genrad!mit-eddie!rh