[comp.emacs] Visual searching

merritt@iris613.gsfc.nasa.gov (John H Merritt) (04/30/89)

We have some Visual Technology 603's, emulating a vt100, and
they don't seem to do very well with GNUemacs.  Whenever I try
to scrolling, the scroll takes place and I am placed in
'I-search'.  It seems to only happen when the cursor is on the top
or bottom line of the editing window.  The status line at the bottom
of the screen reads:

I-search: ^Q-

It definately is 'I-search' because any characters I type are found, if
they exist, meaning that ^Q- is ignored!

Other terminals, also emulating a vt100, seem to work fine. I think
something needs to be done with the Visual terminal, or the terminfo entry
to remedy this problem.  I would appreciate any help in this matter.

Incidently we are running GNUemacs Version 18.54.2 on an IRIS 4D/70.


Thank you,
+---------------------------------------------------------------+
| John H. Merritt                 | "Yesterday I knew nothing,  |
| merritt@iris613.gsfc.nasa.gov   |  Today I know that."        |
+---------------------------------------------------------------+

spolsky-joel@CS.YALE.EDU (Joel Spolsky) (04/30/89)

In article <192@dftsrv.gsfc.nasa.gov> merritt@iris613.gsfc.nasa.gov (John H Merritt) writes:
|We have some Visual Technology 603's, emulating a vt100, and
|they don't seem to do very well with GNUemacs.  Whenever I try
|to scrolling, the scroll takes place and I am placed in
|'I-search'.  It seems to only happen when the cursor is on the top
|or bottom line of the editing window.  The status line at the bottom
|of the screen reads:
|
|I-search: ^Q-

The terminal is sending a ctrl-S (XOFF character) to pause incoming
text while it tries to scroll. Emacs interprets ^S as i-search. Then
it sends a ctrl-Q (XON) to resume incoming text. Emacs interprets this
as quote-next-character. Indeed ^Q followed by a non-special character
is ignored; that's what it means.

|It definately is 'I-search' because any characters I type are found, if
|they exist, meaning that ^Q- is ignored!

Well, if, for example, you wanted to search for an escape character
without confusing emacs, you would type ^S ^Q Escape. The ^Q isn't
always ignored.

|Other terminals, also emulating a vt100, seem to work fine. I think
|something needs to be done with the Visual terminal, or the terminfo entry
|to remedy this problem.  I would appreciate any help in this matter.

Look in the manual for a way to shut off XON/XOFF in the terminal's
setup mode (or maybe dip switches?) Hopefully the terminfo entry
should know how long to wait after sending a scroll command to avoid
losing data.

+----------------+----------------------------------------------------------+
|  Joel Spolsky  | bitnet: spolsky@yalecs.bitnet     uucp: ...!yale!spolsky |
|                | internet: spolsky@cs.yale.edu     voicenet: 203-436-1483 |
+----------------+----------------------------------------------------------+
                                                      #include <disclaimer.h>

hedrick@geneva.rutgers.edu (Charles Hedrick) (05/01/89)

Spurious ^Q commands indicate that your terminal can't keep up without
output, and is doing XON/XOFF.  There are several approaches,
including changing emacs to use different commands for search and
quote.  But I recommend doing two things:

  - set options on the terminal to make it as fast as possible.
	This probably means turning off smooth scroll.  If the
	terminal has different window sizes and type fonts, timing
	may depend upon the setup.

  - 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.

I find the whole idea of terminals that issue XOFF unacceptable, but
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.

jr@bbn.com (John Robinson) (05/03/89)

In article <Apr.30.21.17.58.1989.4520@geneva.rutgers.edu>, hedrick@geneva (Charles Hedrick) writes:
>I find the whole idea of terminals that issue XOFF unacceptable, but
>DEC seems to have started it with the VT100.

They really sealed the fate with the VT101 (or was it -102?).  That
beast not only couldn't keep up at 4800 baud, if you sent it nulls (or
whatever) as padding it still spent so much time throwing away the
padding that it fell further behind.  No amount of padding worked; you
*had* to use real delays (which not many terminal drivers support, and
which is useless across any sort of network).

>					    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.

You still need to learn how to map other keys to ^S and ^Q so you can
search and quote, since typing these characters will generally be
impossible on terminals that insist on flow control.  It is also a bug
that some terminals don't let you turn flow control on and off with an
escape sequence, the way they do, say, reverse-video.

Recent postings about the keyboard-translate-table talk about
remapping keys.  (or write me if you really need this and can't find
it in your manual or info or help files).
--
/jr
jr@bbn.com or bbn!jr
C'mon big money!

rbj@dsys.icst.nbs.GOV (Root Boy Jim) (05/03/89)

? 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?