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?