NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/gnu/emacs/help/3704

Internet Message Format | 1992-08-12 | 3.8 KB

Path: sparky!uunet!elroy.jpl.nasa.gov!ames!sun-barr!rutgers!news.cs.indiana.edu!umn.edu!thompson
From: [e-mail] (T. Scott Thompson)
Newsgroups: gnu.emacs.help
Subject: Re: C-s problems
Message-ID: <[e-mail]>
Date: 12 Aug 92 14:16:57 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (Usenet News Administration)
Distribution: gnu.emacs.help
Organization: University of Minnesota
Lines: 67
Nntp-Posting-Host: kiyotaki.econ.umn.edu

[e-mail] (Kevin Broadey) writes:

>In article <[e-mail]> [e-mail] (Ted Pedersen) writes:

>   I am a new emacs user and am having a very good time learning my way around.
>   However, a problem has come up. It seems that whenever I use the C-s key
>   (either as a part of a C-x C-s command or to do a forward search) I just
>   lock up. Nothing registers on the little mini buffer and I usually have to
>   bail all the way out of emacs. Note that C-r (the backward search) works very
>   well. Anybody have any ideas of what this might be and/or what I can do to
>   get around it.

>   Thanks,
>   Ted Pedersen


>This looks like a flow control problem, because C-s (otherwise known as XOFF)
>is a standard way for a terminal to tell the host to stop sending it
>characters.

>Now, Emacs ought to set the terminal driver to pass flow control characters
>straight through (rather than action them), so my guess is you're using
>something like a DEC-VT220...

>In the `Communications Set-Up' menu is a field at the start of the second line
>which reads "XOFF at 64", "XOFF at 128" or "NO XOFF".  If it is set to one of
>the first two, typing `C-s' causes the VT to lock the display _immediately_,
>wait for a few more characters (maybe), then send `C-s' to the host.  What you
>need to do is set it to "NO XOFF" so that the VT passes `C-s' straight to the
>host.

This doesn't sound right to me.  More precisely, it is incomplete.
Your explanation essentially states that the terminal sends C-s (XOFF)
to the host when you press C-s at the keyboard.  This is undoubtably
correct, but is probably not the source of the problem.  After all,
sending out C-s is exactly what we want the terminal to do!

I do not know the specifics of the DEC-VT220, but I suspect that the
various "XOFF" commands mentioned control how the terminal responds to
data arriving too fast from the host.  That is, when you set "XOFF at
64" this probably means "OK terminal, if your input buffer has less
than 64 free bytes you should _automatically_ send out a C-s to tell
the host to stop sending."

But this is a digression.  The real problem is that when the host
_receives_ the C-s it is interpretting it as the message "stop sending
characters" instead of passing it along to emacs.  That is, the
flowcontrol processing _at_the_recieving_end_ prevents emacs from ever
seeing the C-s.  It also causes the host to temporarily stop echoing
characters back to the terminal, which is why your terminal _appears_
to be locked.  (It isn't really locked in all likelihood.)

Ideally emacs will turn off XON/XOFF flowcontrol at the host
automatically when it is in command. However there are situations when
emacs cannot do the job.  For example, I usually connect to my host
through a network terminal server that does its own flowcontrol
processing.  Unless I turn that off (manually) when I make the
connection, the host never even receives the C-s, since it is
intercepted and processed by the terminal server.

Bottom line: The problem _is_ flow control.  The solution is likely to
be more complicated than simply turning off XON/XOFF flowcontrol at
the terminal end.

T. Scott Thompson               [e-mail]
Dept. of Economics
University of Minnesota