[comp.emacs] spurious i-search

jfjr@MITRE-BEDFORD.ARPA (Freedman) (10/15/87)

  I am using a vt100 on Ultrix running Emacs 18.49. We have just been
moved to a new location with a whole new networking system. I find
I get "Failing-isearch: ^Q" often enough to tempt me into encouraging
my terminal to go airborne. I looked around in the installation
notes and "PROBLEMS" in particular and my problem was described along
with several possible solutions. The one I tried and which seems to
work is to evalutate (set-input-mode nil t). I did it, it seems to
work and I put it in my .emacs. Now here's my question(s). The
author of problems describes this solution as drastic and enough
to get emacs "semi" working. Well gee, it seems to work fine. Am I
missing something? Will my terminal blow up or all my files go to
the bitbucket?. What dangers am I skirting? 
 Next question. I looked in site-init.el and saw where the
construction of the keyboard-translate-table. It maps ^S to ^S
and ^Q to ^Q (as well as ^\ to ^S and ^^ to ^Q). Can I get into
trouble if I override this in my .emacs - which is loaded first?
site-init.el or .emacs? By overriding I mean map ^S to something
harmless but still mapping ^\ to ^S. This type of thing is also
referred to as drastic too by the way - How drastic is it?



Jerry Freedman, Jr      "As you wander through life
jfjr@mitre-bedford.arpa   Whatever be your goal
(617)271-6248 or 7555    Keep your eye upon the doughnut
                          and not on the hole"

dph@beta.UUCP (David P Huelsbeck) (10/16/87)

In article <8710151837.AA10134@mitre-bedford.ARPA> jfjr@MITRE-BEDFORD.ARPA (Freedman) writes:
>
>  I am using a vt100 on Ultrix running Emacs 18.49. We have just been
>moved to a new location with a whole new networking system. I find
>I get "Failing-isearch: ^Q" often enough to tempt me into encouraging
>my terminal to go airborne.
 [...]
>with several possible solutions. The one I tried and which seems to
>work is to evalutate (set-input-mode nil t). I did it, it seems to
>work and I put it in my .emacs. Now here's my question(s). The
>author of problems describes this solution as drastic and enough
>to get emacs "semi" working. Well gee, it seems to work fine. Am I
>missing something? Will my terminal blow up or all my files go to
>the bitbucket?. What dangers am I skirting? 
 [...]
>
>Jerry Freedman, Jr      "As you wander through life
>jfjr@mitre-bedford.arpa   Whatever be your goal
>(617)271-6248 or 7555    Keep your eye upon the doughnut
>                          and not on the hole"


I'm following up only because I think this problem is much more
wide spread than the folks at FSF think. (not a flame, I love GNU)

I had the same problem. I tried shutting of Xon/Xoff on my vt100.
No dice. My vt100 has one of the optional printer ports. It seems
that when one of these is put into a vt100 it locks it into Xon/Xoff
mode to deal with the local printer. I could have replaced my vt100
with another sans printer port (have one sitting in my office) but I
wasn't willing to give up local printing. I tried adding the extra 
buffering that rms suggests, that didn't work to well either. So I
eventually found a solution while trying to do something else.

The solution is "screen". The virtual terminals package allows you to
work in Xon/Xoff mode and still send ^S & ^Q to any applications running
directly under it. (I say directly because I suppose you'd run into the
same problem if you logged in, fired up screen, and the rlogged and fired
up emacs.) I've also found that I like the virtual terminals better than
the GNU shell mode or terminal emulator. (Just my personal preference, sorry
if you don't agree.) 

"screen" was just posted to one of the sources groups not to long ago.
I'm sure you can find someone to mail you a copy.


	David Huelsbeck
	dph@lanl.gov.arpa
	{cmcl2,ihnp4}!lanl!dph

#include <std/disclaimers.h>

olsen@XN.LL.MIT.EDU (Jim Olsen) (10/16/87)

In a recent article, jfjr@MITRE-BEDFORD.ARPA (Freedman) writes:
>I am using a vt100 on Ultrix running Emacs 18.49.  I find I get
>"Failing-isearch: ^Q" often enough to tempt me into encouraging my
>terminal to go airborne.  [The solution] which seems to work is to
>evaluate (set-input-mode nil t).

>Now here's my question(s). The author of problems describes this solution
>as drastic and enough to get emacs "semi" working. Well gee, it seems to
>work fine.  Am I missing something?  What dangers am I skirting?

There are no hidden dangers in using (set-input-mode nil t).  However,
it does mean that ^S and ^Q are no longer available, so you may want
to rebind their functions to other keys.  I have bound isearch-forward,
quoted-insert, and save-buffer to keypad keys on my VT100.  I have
also redefined some of the search control characters, using:

		(setq search-repeat-char ?\C-z)
		(setq search-exit-char ?\C-x)
		(setq search-quote-char ?\C-c)

to make searching more convenient.  Emacs works fully and completely for me.

Apparently, the author of 'problems' thinks systems using XON/XOFF
flow-control are "brain-damaged" and should go away.  Fortunately, one
needn't accept all of the GNU philosophy in order to use GNU software.

lamy@utegc.UUCP (10/19/87)

Seems to me that so much traffic on this list is generated by ^H and ^S fixes
that an "official" solution ought to be available in a future release. Why not

a) have whatever character stty specifies as the delete character act as
   the delete character.
b) Consider the behaviour where help prints messages ignoring the keyboard
   translation to be a bug instead of a feature?
   Ordinary mortals don't want to know...
c) Provide a trivial function call to replace ^S and ^Q
   (xon-xoff-braindamage-workaround control-S-repl control-Q-repl)
   Ordinary mortals should not have to worry about translation tables...

I don't care myself, as the terminals I use have nice big delete and meta key
and are well behaved wrt flow control, but I'm getting sick of having to tell
people to rewire their brains and use DEL or include 10 lines of incantations
in their .emacs ('cause I'm the one they come to see to get them).

Jean-Francois Lamy                     lamy@ai.toronto.edu, lamy@ai.toronto.cdn
AI Group, Dept of Computer Science     lamy%ai.toronto.edu@relay.cs.net
University of Toronto, Canada M5S 1A4  {uunet,watmath}!ai.toronto.edu!lamy