kwang@uicsrd.csrd.uiuc.edu (06/25/89)
To Emacs users thru modem at home:
I found that all kinds of commands to repaste/fill a region or screen
always generate "Regexp I-search: ^Q-" command in the mini buffer. That
is very annoying.
e.g. ^V, esc-V, esc-Q(tex mode), ^N or ^P on screen boundary,....
also issue "I-search" command after filling out the screen.
I tried to fix the problem from modem, terminal, .. but no help.
Thankyou for any help. -kwang
modem: USrobotics 2400e
terminal: wyse50
p.s. I also found that in "vi" editor, J(left) and K(right) keys are
not effective.jr@bbn.com (John Robinson) (06/26/89)
In article <44000012@uicsrd.csrd.uiuc.edu>, kwang@uicsrd writes: >To Emacs users thru modem at home: > > I found that all kinds of commands to repaste/fill a region or screen > always generate "Regexp I-search: ^Q-" command in the mini buffer. That > is very annoying. > e.g. ^V, esc-V, esc-Q(tex mode), ^N or ^P on screen boundary,.... > also issue "I-search" command after filling out the screen. > > I tried to fix the problem from modem, terminal, .. but no help. > Thankyou for any help. -kwang > > modem: USrobotics 2400e > terminal: wyse50 > >p.s. I also found that in "vi" editor, J(left) and K(right) keys are >not effective. [I was going to reply by mail, but maybe it is time for a periodic reposting of the note at the end of this message.] You didn't say *which* emacs. I will try to reply generically, though I am more familiar with GNU emacs than the various small emacses. Either your terminal or your modem is sending your host flow control characters when the host tries to send large blocks of output. The character control-S (^S, also called DC3, or XOFF) is what the terminal or modem uses to tell the host to stop sending. Emacs sets things up, however, so that it gets all characters, and so ^S has the meaning to it of "regular expression search". The ^Q character (DC1, or XON) is the terminal or modem telling the host to resume sending, but to emacs it has a different meaning, typically quote the next character. If it is the terminal that is sending the characters, try setting its flow control to off. Emacs is supposed to put in enough padding that the terminal won't fall behind, based on the termcap entry. If you are also going through a network or terminal front-end, make sure the host knows your exact terminal speed (stty 2400) so that emacs can compute the proper amount of padding. If this fails to stop it, you may want to check out the termcap entry. GNU Emacs provides two alternate termcap files in ...emacs/etc/, if you have it. If it is the modem that is sending it, you have a defective modem (that is, its design is defective). The modem is supposed to provide a transparent connection from your terminal to your host, but that is not the case - it sends all those extraneous characters. Try to persuade your computer center to provide better modems. Or find out how you can configure them to avoid using flow control. If none of those approaches work, you can tell GNU emacs (if that is the version you are using) to respect the flow control characters. This means that you will not be able to type them when you want to search or quote a character, and you will have to find other characters for this duty. I have appended a file that talks about how to do this in GNU emacs, and it in turn points you to other files in the GNU emacs distribution that will tell you more about this problem. The problem with vi may be due to an incorrect termcap entry. /jr, nee John Robinson What a waste it is to lose one's mind--or not jr@bbn.com or bbn!jr to have a mind. How true that is. -Dan Quayle -------- GNU Emacs and Flow Control Copyright (c) 1989 Free Software Foundation, Inc. Permission is granted to anyone to make or distribute verbatim copies of this document as received, in any medium, provided that the copyright notice and permission notice are preserved, and that the distributor grants the recipient permission for further redistribution as permitted by this notice. Permission is granted to distribute modified versions of this document, or of portions of it, under the above conditions, provided also that they carry prominent notices stating who last changed them, and that any new or changed statements about the activities of the Free Software Foundation are approved by the Foundation. GNU emacs (version 18.48 and later) provides several options for coping with terminals or front-ends that insist on using flow control characters. Listed in estimated order of preference. 1. Have Emacs run in CBREAK mode with the kernel handling flow control. Issue (set-input-mode nil t) from .emacs. It is now necessary to find other keys to bind to the commands isearch-forward and quoted-insert. Traditional nominees are C-^ and C-\. There are two ways to get this effect: 1a. Use the keyboard-translate-table to cause C-^ and C-\ to be received by Emacs as though C-S and C-Q were typed. Emacs (except at its very lowest level) never knows that the characters typed were anything but C-S and C-Q, so the use of these keys inside isearch still works - typing C-^ while incremental searching will move the cursor to the next match, etc. Here's some code for this: (setq keyboard-translate-table (make-string 128 0)) (let ((i 0)) (while (< i 128) (aset keyboard-translate-table i i) (setq i (1+ i)))) (aset keyboard-translate-table ?\^\\ ?\^s) (aset keyboard-translate-table ?\^^ ?\^q) 1b. Simply rebind the keys C-^ and C-\ to isearch-forward and quoted-insert. To get continued searches inside isearch it is also necessary to set search-repeat-char to C-^. 2. Don't use CBREAK mode, and cause C-S and C-Q to be bound to a null command. The problem with this is that whatever sent the flow control characters is apt to be falling behind the characters being sent to it, and so what finds its way to the terminal screen will not in general be what is intended. It will be still be necessary to find other keys to bind to isearch-forward and quoted-insert; see 1a and 1b above. Here is a suitable null command: (defun noop () "Do nothing; return nil." (interactive)) 3. Don't use CBREAK mode, and global-unset-key the keys C-S and C-Q. This is similar to #2, except that the flow control characters will probably cause beeps or visible bells. Note that, if the terminal is the source of flow control characters and kernel flow control handling is enabled, it will not in general be necessary to send padding characters as specified in a termcap or terminfo entry. It may be possible to customize a termcap entry to provide better Emacs performance on the assumption that flow control is in use. This effect can also be simulated by announcing (with stty(1) or its equivalent) that the terminal is running at a very slow speed, provided the terminal is not directly wired to the host. Some Background This section attempts to answer the question "Why does emacs choose to use flow-control characters in its command character set?" For another view, please read the comments on flow control in emacs/INSTALL from the distribution; for help with termcaps and DEC terminal concentrators see emacs/etc/TERMS. Flow control was not necessary for most terminals once upon a time, so use of C-S and C-Q for command characters was reasonable. Emacs, for economy of keystrokes and portability, chose to use the control characters in the ASCII character set for its functions, and tried to use mnemonic assignments (S for search, Q for quote). There are other (albeit less common in practice) ways to do flow control that preserve transparency of the character stream. Once emacs' precedent was established, it was too hard to undo. One might even argue that emacs' use of these control characters predates their use by terminals and front-ends for flow control. Notice also that the latter use is ONLY a de-facto standard. In fact, on the model 33 teletype with a paper tape punch (which is VERY old), they were used for the host to turn the punch on and off! So which usage is "right", emacs' or the terminal/front-end manufacturer's? This is a rhetorical (or religious) question; it has no simple answer. -- /jr, nee John Robinson What a waste it is to lose one's mind--or not jr@bbn.com or bbn!jr to have a mind. How true that is. -Dan Quayle