From xemacs-m  Wed Feb 12 18:18:00 1997
Received: from corona.pixar.com (corona.pixar.com [138.72.20.84])
	by xemacs.org (8.8.5/8.8.5) with SMTP id SAA16230
	for <xemacs-beta@xemacs.org>; Wed, 12 Feb 1997 18:17:59 -0600 (CST)
Received: by corona.pixar.com (Smail3.1.29.1 #2)
	id m0vuor7-0001YKC; Wed, 12 Feb 97 16:16 PST
Sender: retnuh@pixar.com (Hunter Kelly)
Sender: retnuh@corona
To: xemacs-beta@xemacs.org
Subject: fixing gnuattach
Mime-Version: 1.0 (generated by tm-edit 7.103)
Content-Type: text/plain; charset=US-ASCII
From: Hunter Kelly <retnuh@corona.pixar.com>
Date: 12 Feb 1997 16:16:52 -0800
Message-ID: <yvt7mkdef0r.fsf@corona.pixar.com>
Lines: 38

So, I've been playing around with gnuattach.  I realized that the ^G
problem was that SIGQUIT was getting sent to the gnuattach process,
not the emacs process.  I whipped up some code that essentially passes
some of the more important signals on to the emacs process, and lets
it deal with them.  This has fixed the ^G problem, and from what I can
tell works fine.  Even makes gnuattach a good tool, finally.

There is, however, still a problem with ^Z now.  The problem is that
^Z insists on suspending the emacs process.  There is even the
following comment in Fsuspend_emacs:


  /* There used to be a check that the initial console is TTY.
     This is bogus.  Even checking to see whether any console
     is a controlling terminal is not correct -- maybe
     the user used the -t option or something.  If we want to
     suspend, then we suspend.  Period. */


However, this does not take into account the fact that the user might
want to be suspending a gnuattached process instead of the emacs
process.

I propose a change such that:  tty devices (possibly others, too?)
keep track of the process controlling it.  Then, Fsuspend_emacs can
check the current_frame, see if is a tty, and check the controlling
pid of the tty.  If it the same as emacs-pid, then suspend emacs, as
it usually does.  But if it isn't the same as emacs-pid, send SIGSTOP
(or whatever the appropriate signal is) to the controlling process.

If the above is better done a level above suspend_emacs, that is fine
with me.  Maybe have and suspend_or_iconify_emacs_or_gnuattach or
whatever.  I am just looking for consensus on whether we should
suspend emacs or the gnuattach process.

I'll implement any changes needed.

Hunter

