G:alpines (03/31/83)
Subject: XON/XOFF with Emacs under 4.2bsd I have found that one cannot use XON/XOFF protocol with Emacs. For those terminals which use this (in place of padding), it can be disastrous. I just tried using Emacs (I should mention that this is James Gosling's Emacs) on a Tandberg TDV2220 and since it does add/delete lines rather slowly, its buffer (be it 256 characters long) fills up before it finishes the add or delete operations, while Emacs is merrily sending along lines. Has anyone encountered this problem? How does it work with VT100's, which also use XON/XOFF? Does CCA Emacs have this problem? Harry Weeks
jim (03/31/83)
We have several Gigis here. Gigis must have been a total marketing disaster, because DEC has given a half dozen or so to every University I know of in an attempt to clear out their warehouses. Anyway, Gigis are about the worst offenders I know of as far as XON/XOFF. I've tried several padding schemes and none work. So I have modified our emacs to take a flag which turns on XON/XOFF protocol, and my login file aliases emacs to "emacs -x" when I am on a Gigi. This works fine except that you lose ^S, ^Q, ^X-^S, ESC-^S, etc. I will be glad to send my mods to anyone who is interested.
crc (03/31/83)
All EMACS have the same problem with XON/XOFF. Usualy one can get around it by using a slower baud rate. This of course only appears with SLOW terminals. With today's technology there really is no excuse for making a terminal to slow to handle EMACS at 9600 baud. I'v noticed an alarming trend! HP is now making their terminals slower that in the past! The old HP 2621P and 2621A would work at 9600. The 'new' replacement, 2621B is too slow. So are the fancy 2623B and 2624B. WE SHOULD REWARD THESE PEOPLE BY NOT BUYING SLOW TERMINALS. The VT100 is also too slow - don't buy it. Terminals that are OK - I've tested them personally to 9600 baud. VT52 VS200 (Visual 200) Ann Arbor Abassador (some times good to 19.2K baud) HP 2621A (Not tested, but should work) HP 2621P
jr@BBN-UNIX (04/01/83)
From: John Robinson <jr@BBN-UNIX> I assume that padding doesn't work? The most straightforward way to run with such terminals is to modify the editor to run in cbreak mode, which lets the kernel do flow control for you. Unfortunately, this means you have to give up ^S and ^Q as function characters. Also, the editor has to catch quit and interrupt or undefine them (preferable, probably) and worry about other tty driver features interfering (crmod, tabs, etc.). The Tandberg terminal has (or should soon have) the ability to do flow control using its RS232 modem control lines. We have gotten this to work with the C70, and it's a nice improvement, especially since it works in raw mode (and doesn't steal ^S and ^Q). However, it does appear that the effective speed of the terminal is no better than 4800 baud anyway (and it still needs flow control at this speed). I disagree with harpo!floyd!crc that slowness is a misfeature. If a terminal has better functionality-per-character, but sometimes needs padding or flow control, it may still be faster at supporting emacs. And of course many other considerations drive most poeple's choice of a terminal. /jr
crc (04/01/83)
What is a Gigi? What is the maximum speed it will run and swallow screens from Emacs? Which Emacs?
ka (04/01/83)
Don't count on the HP 2621P working at 9600 baud. They come close to being fast enough, so that if you try out two or three of these terminals you should find that one of them processes characters fast enough. Kenneth Almquist
mark (04/02/83)
The 2621 and the Ambassador both come very close to not needing padding, but they do sometimes. For example, clearing the screen takes a while (especially on the Ambassador, which must clear 60 lines of memory a byte at a time). Since both terminals do xon/xoff, you rarely notice it, but since EMACS and xon/xoff are not compatible, it is possible to overflow their buffers. But it's pretty hard. The claim that there is no excuse for a modern terminal needing padding is silly. Bitmapped terminals and workstations tend to need LOTS of padding to scroll, since they must BitBlt lots of rasters around. Most modern terminals need some padding some where if you don't do any flow control.
guy (04/04/83)
But what if you like smooth scrolling, where the slowness is not due to the
hardware being slow but the "meatware" being slow (i.e., I can sometimes read
stuff zipping past in rough scroll BUT I prefer not to). In this case, there
is no substitute for XON/XOFF.
Guy Harris
RLG Corporation
{seismo,mcnc,we13}!rlgvax!guybillw (04/09/83)
#R:populi:-54000:sri-unix:18100001:000:295 sri-unix!billw Apr 6 12:43:00 1983 what with the current cost of memory, there shouldnt be any reason to ever need to do flow control. All you need is a great big FIFO buffer on the (interupt driven) serial line. A communications program I wrote for the IBM PC uses up to 65535 bytes for its fifo... try to overrun that! BillW