dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/05/88)
In article <8437@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >(At >present we also don't emulate line wrap for terminals that lack it, >because we don't want the shell to have to depend on termcap.) May I recommend that you, and other designers, do so, please. There is no need to backspace across screen lines, but when normally sending output to the terminal, autowrap emulation would be useful. The screen width ought to be a terminal attribute settable and obtainable like other terminal attributes that stty is used to set. 4.3BSD keeps screen width information somewhere in its tty data structures. We have users here who use both VMS and UNIX from the same terminals. Terminal settings that work for VMS (e.g. no autowrap) ought not to stop working for UNIX, since it's commonly known that UNIX is so much more flexible than VMS. For the same reason, I hope 4.3BSD people will give us no-parity input/output too in the future. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
rob@pbhyf.PacBell.COM (Rob Bernardo) (09/06/88)
In article <3854@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: +In article <8437@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) +writes: +>(At +>present we also don't emulate line wrap for terminals that lack it, +>because we don't want the shell to have to depend on termcap.) + +May I recommend that you, and other designers, do so, please. There is +no need to backspace across screen lines, but when normally sending +output to the terminal, autowrap emulation would be useful. I haven't been following this discussion, so forgive me if I'm posting something irrelevant or something already said. Autowrap might not be as easy to implement currectly in the shell as it seems. I ran into a problem with this in ksh. Ksh uses screen width when presenting a previous command when engaging in command editing. The short of it is that if the whole command undergoing editing doesn't fit between your prompt and the right margin it indicates at one or both ends that the command is only partially displayed. Well, I ran into a problem when my prompt contained escape sequences to do some fancy stuff (e.g. going to the status line, displaying the date, time, cwd, etc and then returning to the normal screen line and displaying the command number in reverse video. Whew!). Well ksh wasn't smart enough to know that all those characters in the prompt weren't occupying space on the current screen line and when I enter command editing, it gave me a teeny editing window. Even if I had done something simpler with the prompt, like putting it in reverse video (without including the status line stuff), ksh's notion of what column the cursor was in would still be mistaken. To get around this I had to set COLUMNS to a much larger number than the 80 it should have been. But I had to make sure not to export COLUMNS, or else vi and other programs would have access to it and have a mistaken notion of the screen width. -- Rob Bernardo, Pacific Bell UNIX Small Bus. Systems Development & Maintenance Email: ...![backbone]!pacbell!rob OR rob@PacBell.COM Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center Residence: (415) 827-4301 R Bar JB, Concord, California
gwyn@smoke.ARPA (Doug Gwyn ) (09/06/88)
In article <3854@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >There is no need to backspace across screen lines, but when normally >sending output to the terminal, autowrap emulation would be useful. To the contrary, you can pipe your output through a "fold" filter, but this discussion was about command-line editing, for which you really need both capabilities whenever the command line gets long. >4.3BSD keeps screen width information somewhere in its tty data >structures. Unfortunately they're only set while a window manager is in control. The standard login sequence really ought to set up this data as well as the TERM environment variable. But then, it may not be wise to make login depend on termcap either. >... I hope 4.3BSD people >will give us no-parity input/output too in the future. You can already get that, with some difficulty. Word is that future BSDs will support the IEEE 1003.1 terminal interface, which should be good enough.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/06/88)
In article <3854@bsu-cs.UUCP> dhesi@bsu-cs.UUCP I wrote: >May I recommend that you, and other designers, [emulate autowrap] please. Please excuse my lack of clarity. I was talking about emulating autowrap as a general user interface philosophy, not just in the case of command-line editing from the shell. The right place emulate autowrap is probably in the terminal driver. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
rick@seismo.CSS.GOV (Rick Adams) (09/07/88)
> >4.3BSD keeps screen width information somewhere in its tty data > >structures. > > Unfortunately they're only set while a window manager is in control. > The standard login sequence really ought to set up this data as well > as the TERM environment variable. But then, it may not be wise to > make login depend on termcap either. The 4.3bsd tset program sets the rows&columns if they aren't already set. This is probably the place to do it, as it's already mucking around with terminal types, etc. --rick
jherr@umbio.MIAMI.EDU (Jack Herrington) (09/07/88)
in article <3861@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) says: > In article <3854@bsu-cs.UUCP> dhesi@bsu-cs.UUCP I wrote: >>May I recommend that you, and other designers, [emulate autowrap] please. > > .......The right place emulate > autowrap is probably in the terminal driver. 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. 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. I think it belongs in the application, the people who advocate a bigger kernel are people who don't want to write little peices of code like this. Now I'm not a purist in that sense, I like alot of the things Berkeley has thrown into the standard tty's and pty's drivers, but things like this are too specific to the affected application. Just my two cents worth. -Jack jherr%umbio@umigw.miami.edu "How can one fool make another wise?" -Kansas ( :-) )
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/07/88)
In article <460@umbio.MIAMI.EDU> jherr@umbio.MIAMI.EDU (Jack
Herrington) explains why autowrap in the terminal driver may interfere
with specific applications.
For this reason autowrap, like most of the other things one sets with
stty, should be switchable. A hypothetical 4.4BSD example:
stty autowrap:yes parity:none columns:80 echo:delayed histedit:vi
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesiguy@gorodish.Sun.COM (Guy Harris) (09/08/88)
> 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.
mouse@mcgill-vision.UUCP (der Mouse) (09/11/88)
In article <3854@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <8437@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >> (At present we also don't emulate line wrap for terminals that lack >> it, because we don't want the shell to have to depend on termcap.) > May I recommend that you, and other designers, do so, please. There > is no need to backspace across screen lines, but when normally > sending output to the terminal, autowrap emulation would be useful. 1) Please don't, ever, do :am:bw@:. This is seriously brain-damaged behavior, and if Sun hadn't done it I wouldn't have quite believed anyone would be crazy enough to. (It's fine if am and bw are independently configurable and the user explicitly asks for it, of course.) 2) I think BRL is right to keep the shell independent of the terminal type and everything that depends on it. > We have users here who use both VMS and UNIX from the same terminals. > Terminal settings that work for VMS (e.g. no autowrap) ought not to > stop working for UNIX, since it's commonly known that UNIX is so much > more flexible than VMS. And what does VMS do to avoid "wrapping" in the middle of an escape sequence? Or does the tty driver track the terminal type and parse all the escape sequences? Where does it keep its database of escape sequences? Oh yes, that's right, if it's not a DEC brand we don't care what happens to it. Use something on UNIX which sits between the real tty and whatever's running and provides whatever features you want. (Can screen do this? I don't know, never having played with it.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mouse@mcgill-vision.UUCP (der Mouse) (09/11/88)
In article <8439@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > In article <3854@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >> 4.3BSD keeps screen width information somewhere in its tty data >> structures. (Also screen height, if some program cares to set it.) > Unfortunately they're only set while a window manager is in control. Or when rloginned from somewhere else where the tty size is set. > The standard login sequence really ought to set up this data as well > as the TERM environment variable. I strongly disagree. This means that if you log in, your tty size gets set to the size of whatever type the line is set to - such as "dialup", "gandalf", etc. Then when you explicitly set your terminal type, you're stuck with the old, probably wrong, size. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
barmar@think.COM (Barry Margolin) (09/12/88)
In article <1306@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >And what does VMS do to avoid "wrapping" in the middle of an escape >sequence? I don't know what VMS's solution is, but in Multics we solved it by implementing a variant of the tty_write system call, called tty_write_whole_string. It guarantees that the string passed will be sent to the terminal together. The Multics equivalent of termcap uses this system call whenever it sends control sequences. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar