[comp.emacs] Need Help with GNU Emacs, VT131, and VMS

templon@silver.bacs.indiana.edu (jeffrey templon) (03/11/89)

	What a hairball!  OK, I have looked in the TERMS. file, in the
VMSXXX files, and the manual.  I tried looking in the termcap file - hence
the word, "hairball."

	The editor - GNU Emacs 18.52.  Vax/VMS 4.6.  I have two problems:
first is that there is no termcap entry for a VT131.  Can someone send me
one?  I have *no* desire to learn how to do this if someone else already has.

Second problem: I got around (temporarily) this problem by setting the VT131
to VT100 (i.e. SET TERM/VT100).  This allows me to use the emacs, but whenever
the screen scrolls, I get this horrible mess in the minibuffer:

Failing I-search:^S^S^S^Q-

Once I got    Failing regexp I-search: OB^S^Q-   this was when the scroll
resulted in the end-of-text moving onto the screen.  I have searched through
the VMS SET TERM docs and have seen some stuff about the system sending
c-s and c-q to regulate flow control, but i didn't understand it.  I should
point out that the terminal line runs through a GANDALF multiplexer before
getting to the terminal, I don't know if that does anything with control chars.

Final problem (yeah, I know I only said two): I can't get control-S!  VMS
uses control-s to tell the process "stop sending data, you ugly beast."  So
when I type c-x c-s, emacs just sits there forever, waiting for me to type
control-q so it can send data again.

Someone must have dealt with this already.... help!  I should note in closing
that when I use emacs using my mac running versaterm thru a modem and a
LATserver to the VAX, I don't have this failing I-search mung.  I still
have the control-S problem though.

						jt

phd_ivo@gsbacd.uchicago.edu (03/12/89)

>Second problem: I got around (temporarily) this problem by setting the VT131
>to VT100 (i.e. SET TERM/VT100).  This allows me to use the emacs, but whenever
>the screen scrolls, I get this horrible mess in the minibuffer:
> 
>Failing I-search:^S^S^S^Q-
> 
>Once I got    Failing regexp I-search: OB^S^Q-   
>...   I should
>point out that the terminal line runs through a GANDALF multiplexer before
>getting to the terminal, I don't know if that does anything with control chars.
> 
>Final problem (yeah, I know I only said two): I can't get control-S!  VMS
>uses control-s to tell the process "stop sending data, you ugly beast."  So
>when I type c-x c-s, emacs just sits there forever, waiting for me to type
>control-q so it can send data again.
> 

I am neither a GNU, nor a VMS expert. In addition, we are running an old
version of GNU emacs here. However, your symptoms look familiar to me.
^S and ^Q were two unfortunate choices for control character usage, since
it just asks for all sort of problems.

First, we run an ethernet server here, and when I want to make it pass ^S
^Q through to the terminal (yes our server traps it; switch off with "set
flow disabled"), and I resume my session, I get a ^S ^Q sequence passed
to my process, resulting in emacs waiting for a quoted search.

Second, at least our vms doesn't trap ^S/^Q, but leaves it to our server.
There are some witches of interest, though, like "set terminal/nottsync",
which control vms behavior.

Finally, vt100 themselves may trap ^S/^Q, and you may have to set your
terminal to not freeze the display on itself. Usually, that's called
xon/xoff or flow control, if I am not mistaken.

So, the missing vt131/100 termcap entry may be your least problem.

ivo welch	phd_ivo@gsbacd.uchicago.edu

ngo@tammy.harvard.edu (Tom Ngo) (03/13/89)

In article <3425@silver.bacs.indiana.edu> templon@silver.bacs.indiana.edu (jeffrey templon) writes:

>  ... I get this horrible mess in the minibuffer:
>  Failing I-search:^S^S^S^Q-

You comment later in your note that you suspect a flow-control
problem.  You are absolutely correct.  Your terminal and host send ^S
and ^Q characters to each other to say "Hold on!  You're talking too
fast!" and "OK, go ahead now."  FIX:  Include the lines below in your
.emacs file.  You do not have to change your ^S and ^Q key bindings.

It is more compact to set the keyboard-translate table to the correct
string without using a loop to construct it, but this method is far
easier to read and modify.

;;; Solve flow-control problem by binding ^\ as ^S and ^/ as ^Q
(set-input-mode nil t) ; do describe-function for more info
;; Set keyboard-translate-table to do no translations
(setq keyboard-translate-table (make-string 128 0))
(let ((i 0))
  (while (< i 128)
    (aset keyboard-translate-table i i)
    (setq i (1+ i))))
;; Whenever a ^\ is received, have emacs see a ^S
(aset keyboard-translate-table ?\^\\ ?\^s)
;; Whenever a ^^ is received, have emacs see a ^Q
(aset keyboard-translate-table ?\^^ ?\^q)
;; Whenever a ^S or ^Q is received, have emacs see nothing
(aset keyboard-translate-table ?\^s 0)
(aset keyboard-translate-table ?\^q 0)

--
     --Tom Ngo

     e-mail:    ngo@endor.harvard.edu
     US mail:   12 Oxford St Box 201
		Cambridge, MA  02138
     Phone:     (617) 495-1768 (office)

jr@bbn.com (John Robinson) (03/13/89)

In article <2240@tank.uchicago.edu>, phd_ivo@gsbacd writes:
>>Second problem: [ flow control getting to emacs ]
>> 
>I am neither a GNU, nor a VMS expert. In addition, we are running an old
>version of GNU emacs here. However, your symptoms look familiar to me.
>^S and ^Q were two unfortunate choices for control character usage, since
>it just asks for all sort of problems.

^S and ^Q were unfortunate choices for flow-controlling the
terminal/host.  Below is my canned file tallking about flow control
and how to cope.  Also follow its references into files in the emacs
distribution.
--
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
jr@bbn.com or bbn!jr