Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!bbn!gateway!dsys.icst.nbs.GOV!rbj
From: rbj@dsys.icst.nbs.GOV (Root Boy Jim)
Newsgroups: comp.emacs
Subject: Visual searching
Message-ID: <8905022046.AA01906@dsys.icst.nbs.gov>
Date: 2 May 89 20:46:29 GMT
Sender: news@bbn.COM
Organization: National Institute of Standards and Technology
	formerly National Bureau of Standards
Lines: 50

? From: Charles Hedrick <aramis.rutgers.edu!geneva.rutgers.edu!hedrick@rutgers.edu>
?   - modify your termcap entries by increasing the amount of
? 	padding for things that take time, such as insert and
? 	delete line and character, and scrolling.  You'll
? 	need to do this experimentally.
                        ^^^^^^^^^^^^^^
See below.

? I find the whole idea of terminals that issue XOFF unacceptable, but

I find the idea of having to experiment unacceptable.

? DEC seems to have started it with the VT100.  Once you accept that the
? terminal will uses XOFF and XON to control output, the theory is that
? exact timings become non-critical, so terminal vendors don't seem to
? worry about how fast their terminals are.  My recommendation is that
? you leave XON/XOFF turned on in the terminal, and modify termcap so
? that there is enough padding that XON/XOFF are never actually
? generated.  Then when you are outside emacs (and other programs that
? use termcap), XON/XOFF will work, but when you go into a program that
? uses termcap, you'll get enough padding that XON is never triggered.

And that padding may be too much, so you actually lose. I find the
whole idea of padding offensive, an ancient concept invented when
terminals truly were dumb, and had no buffering. The concept of
baud rate is no longer accurate when connected thru concentrators,
multiplexors, and networks. What is the "baud rate" of an ethernet
or an X.25 PAD?

DEC didn't invent the concept, ANSI did. They just used it widely first.

Note: I am firmly in the "^Q/^S are sacred" camp, but that is another
issue. While I somewhat lament giving up these keys (some kind of
hardware flow control would be nice if it were universal), the padding
solution is far worse. Consider the complexity this adds to the
termcap code. And add to that the fact that the timings may not be
anywhere nearly correct. Garbage in, garbage out.

With noone using z80's or 2716's anymore, the thing to do is put them
in a terminal and buffer any output bursts.

Besides, sometimes I hit ^S in emacs to freeze my screen anyway, so
it's not like I've lost the key completely. Gimme a terminal with a
`freeze screen' key and a method to actually flow control the sending
process. Then make it as widespread as XON/XOFF and I'll use it.

But I will never stoop to padding to avoid flow control.

	Root Boy Jim is what I am
	Are you what you are or what?