Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!bbn!uwmcsd1!ig!agate!pasteur!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: autowrap
Message-ID: <67210@sun.uucp>
Date: 7 Sep 88 19:42:47 GMT
References: <3861@bsu-cs.UUCP> <460@umbio.MIAMI.EDU>
Sender: news@sun.uucp
Lines: 39

> Huh?  What if my application doesn't want autowrap, like if I am a
> modem dialing in and my xmodem process is sending through the driver, if it
> decides to line wrap (by sending characters obviously) with x number of
> characters then my xmodem is gone.

What if your application doesn't want tab expansion, or conversion of '\n' to
CR-LF, or....

Autowrap would presumably not be enabled in raw mode, and there would be a bit
to turn it off in cooked or cbreak mode.  Unfortunately, applications would
have to be modified to know about this bit.

In a driver with a POSIX/S3/S5-style "ioctl" interface, fewer applications
would break because turning OPOST off would shut off all output processing,
including autowrap; some applications might break because they individually
turn off the features OPOST controls rather than turning OPOST off, but those
applications (or libraries those applications use, such as "curses") should be
fixed anyway because in many implementations turning OPOST off makes the "tty
driver" run faster (it passes characters straight through without even looking
at them).

> Besides if you really want to do wrap (good wrap), where it breaks at words,
> not just at 'x' number of characters it requires much more definition than
> you could ever send to a terminal driver.

Yes, but the purpose of autowrap isn't to do "good wrap", it's to make life
easier for users with suboptimal terminals that don't do autowrap themselves.
Terminals that *do* provide autowrap generally break at "x" number of
characters, not at words; the intent is not to implement a word processor, it's
to deal with the occasional very long line, and breaking at "x" number of
characters handles this adequately and is easier to implement either in a
terminal driver or in a terminal's firmware.

The question is "are there enough terminals that will be attached to UNIX
systems in the future out there and that don't provide their own autowrap to
make it worth putting autowrap into the OS?"  I haven't deal with terminals of
that sort recently, so I don't know if it's worth it or not.  Presumably there
are people who *have* dealt with such terminals, and who would think it's
worthwhile.