From xemacs-m  Wed Feb 12 20:48:22 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 UAA20625
	for <xemacs-beta@xemacs.org>; Wed, 12 Feb 1997 20:48:22 -0600 (CST)
Received: by corona.pixar.com (Smail3.1.29.1 #2)
	id m0vurCa-0001YdC; Wed, 12 Feb 97 18:47 PST
Sender: retnuh@pixar.com (Hunter Kelly)
Sender: retnuh@corona
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: xemacs-beta@xemacs.org
Subject: Re: fixing gnuattach
References: <yvt7mkdef0r.fsf@corona.pixar.com> <kigbu9pfrin.fsf@jagor.srce.hr>
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 18:47:11 -0800
In-Reply-To: Hrvoje Niksic's message of 13 Feb 1997 02:01:35 +0100
Message-ID: <yvt67zxe828.fsf@corona.pixar.com>
Lines: 41
X-Mailer: Gnus v5.4.11/XEmacs 19.15

Hrvoje Niksic <hniksic@srce.hr> writes:

> Hunter Kelly <retnuh@corona.pixar.com> writes:
> 
> > 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.
> 
> gnuattach, definitely.  Although, you are probably right about the
> level above, too (there's no need to change the name of the function).
> I think that the checks from the above paragraph should be in
> `suspend-or-iconify-emacs', which should check whether to call
> `iconify-emacs' (if the current frame is on a window system),
> `suspend-emacs' (if the current frame is a tty frame controled by an
> Emacs process), or `suspend-controling-process' (if the current frame
> is a tty frame controlled by an external process).

Okay.  I am going to start implementing this, and send in a big ol'
patch soon.

> As a related issue, how about trying to implement more frames on one
> tty?  I don't think that's hard at all -- I tried removing the check:
> 
>   if (!NILP (DEVICE_FRAME_LIST (d)))
>     error ("Only one frame allowed on TTY devices");
> 
> in frame-tty.c, and the resulting behaviour was astonishinglyu close
> to what we want to have.  E.g. the multiple-frame stuff practically
> worked, only you had to press C-l after `C-x 5 o', etc.

So the concept of multiple frames on a tty is that frames are
essentially containers for different window configurations?  Hmmm, I
think that I like that.  I'll have a go at that, too...

> -- 
> Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
> --------------------------------+--------------------------------
> "Psychos _do not_ explode when sunlight hits them."

Hunter

