Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!cmcl2!rna!n44a!ima!haddock!dan From: dan@haddock.UUCP Newsgroups: net.unix-wizards Subject: Re: Orphaned Response - (nf) Message-ID: <108@haddock.UUCP> Date: Wed, 14-Mar-84 23:58:39 EST Article-I.D.: haddock.108 Posted: Wed Mar 14 23:58:39 1984 Date-Received: Fri, 16-Mar-84 02:03:06 EST Lines: 39 #R:iedl02:-170200:haddock:16800008:177600:1709 haddock!dan Mar 12 21:58:00 1984 From: brian beattieWhat about lines longer than the terminal width. "stty line 80" may not work due to control chars. unless you want "more" in the kernel with the reading of /etc/termcap and all you will always end up with either a partial solution or will be able to handle only one type of terminal. beattie@mitre And what about whether a terminal wraps or not? I'll stick with the traditional Unix definition of a line - a sequence of characters terminated by a \n. Much more elegant. (And much better than systems like VMS or TOPS-10 with their commands like SET TERM/VT100 !!!) The kernel already looks at each character that goes out to your terminal, in order to convert \n to \r\n and to expand tabs. The latter means that it has to keep track of the current column, so it already "knows" about the distinction between control characters and nonprinting characters. The "traditional definition" of a line is not what tty.c uses. Knowing whether the terminal wraps or not is a trivial thing compared to all the options already in the terminal driver. Everyone who thinks that kernel paging is a terrible idea because it "doesn't belong in the kernel" should also, to be consistent, turn off line editing too. After all, it's not much trouble to hit interrupt and retype the line whenever you make a mistake, and line editing clearly "doesn't belong in the terminal"--what's EMACS (or vi) for, anyway? After you've used UNIX without kernel line editing for a while, you'll understand how those of us who once used kernel paging, and can't anymore, feel about "more". (More is less...) Dan Franklin