Orphaned Response - (nf)

[dan at haddock.UUCP]

#R:iedl02:-170200:haddock:16800008:177600:1709
haddock!dan    Mar 12 21:58:00 1984

    From: brian beattie <decvax!ucbvax!beattie at mitre-gateway.ARPA>
    What 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 at 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