Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!ptsfa!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.emacs
Subject: Re: What's wrong with flow control?
Message-ID: <1385@hoptoad.uucp>
Date: Tue, 2-Dec-86 03:49:51 EST
Article-I.D.: hoptoad.1385
Posted: Tue Dec  2 03:49:51 1986
Date-Received: Tue, 2-Dec-86 08:10:24 EST
References: <8612020023.AA05566@ucbvax.Berkeley.EDU>
Organization: Nebula Consultants in San Francisco
Lines: 24

In article <8612020023.AA05566@ucbvax.Berkeley.EDU>, rwells@PROPHET.BBN.COM writes:
>               Your terminal or terminal emulator could have a mode in
> which it translates keyboard entry of Control-S and Control-Q into
> something else - either multi-character escape sequences or other
> control characters.  You then initialize emacs to recognize these
> translated sequences as equivalent to real ^S/^Q...

Therein lies a problem.  Only a few of the Emacs dependencies on
^S and ^Q are in the nice keymaps; the rest are hardwired into Lisp
or MockLisp code.  E.g. in incremental search in Gosmacs, the mlisp
macro reads the keyboard, checks for ^R or ^S (to change the direction
of search) and then does the search for that character.  Changing
^S to M-S in the keymaps won't make M-S work properly inside incr-search.
Quote characters like ^Q tend to be embedded even worse.

So far nobody seems to have define a way to ask "Does this character
map to the function 'incr-search'?".  Even that would not be powerful
enough to cope with a multi-character sequence for ^S, or for 
environments where ^S is bound to a function that does some work
and *then* calls incr-search.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
Call +1 800 854 7179 or +1 714 540 9870 and order X3.159-198x (ANSI C) for $65.
Then spend two weeks reading it and weeping.  THEN send in formal comments!