From xemacs-m  Sun Jun  1 00:49:35 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id AAA17824
	for <xemacs-beta@xemacs.org>; Sun, 1 Jun 1997 00:49:33 -0500 (CDT)
Received: by crystal.WonderWorks.COM 
	id QQcrzz05146; Sun, 1 Jun 1997 01:49:34 -0400 (EDT)
Date: Sun, 1 Jun 1997 01:49:34 -0400 (EDT)
Message-Id: <QQcrzz05146.199706010549@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: [PATCH] 20.3-b3: new tty frame selected too soon
In-Reply-To: <kigk9kfoyy5.fsf@jagor.srce.hr>
References: <QQcrzc00937.199706010008@crystal.WonderWorks.COM>
	<kigraenp3xg.fsf@jagor.srce.hr>
	<QQcrzh01829.199706010116@crystal.WonderWorks.COM>
	<kiglo4vp0t4.fsf@jagor.srce.hr>
	<QQcrzj02290.199706010154@crystal.WonderWorks.COM>
	<kigk9kfoyy5.fsf@jagor.srce.hr>
X-Mailer: VM 6.32 under 20.3 XEmacs Lucid (beta3)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

Hrvoje Niksic writes:
 > Kyle Jones <kyle_jones@wonderworks.com> writes:
 > 
 > > You're fighting the system's design, I'm afraid.  The frames
 > > should all be considered visible, 
 > 
 > Why should they all be considered visible?  The word "visible" has a
 > determined meaning for the redisplay system.  By the current design of 
 > frame.el, the visible frames are all I'll ever want to select, and
 > that's obviously flawed.

It is flawed if you assume "visible" means frames that you
can currently see.  But it doesn't really mean that.  Frames
can be obscured partially or totally by other frames and
still by "visible" as far as the display engine is concerned.
Tty frames fit better into the current scheme of things if
they are considered to be "visible" and permanently stacked
on top of one another.  The current setup in frame-tty.c
doesn't work this way that but it seemed pretty clear from
looking at the rest of XEmacs that it should.  If it did work
that way then invisible tty frames would be skipped by C-x 5 o
as they should be.

That is what I meant by working against the design of the system.
Change your perspective on what "visible" means and things become
lots simpler.  Treat frame raise/lower operations like focus changes
and things (might) get simpler still.  XEmacs has generic code to deal
with focus changes.  I've tested it on tty frames and it works so 
far.

GIven the above, your 'selectability' proeprty isn't needed to
fix the basic problem with C-x 5 o.  But it deserves separate
consideration.  When you have a lot of stacked frames, stepping
through them to find the one you want can be tedious.  It woul
dbe useful if C-x 5 o in a VM frame could be configured to only jump
to another VM frame, instead cycling through C source files and
everything else I have frames opened on.

 > > and the display code should only repaint the selected one.
 > 
 > Huh?

The redisplay code is probably what convinced you that only one
tty frame should be considered visible.  But the redisplay code is
schizo in some areas.  On tty frames f->visible can't have the
same meaning to the output side of the display engine as it does
for X frames.  You only have one physical frame to draw on and so
you would get a jumbled mess if outptu were genreated for all
visible frames.  The display code has to know which frame is at
the top of the tty frame stack so that it knows which one of the
"visible" frames to show to the user.  raise-frame and lower-frame
would control this stack, rather than controlling
f->visible as they do now.  The top of this stack is what I meant 
by "should only repaint the selected one" above.

The remaining issue that I'm still trying to work out is what to
do async frame selection.  I think faking focus events for all
selections that don't involve a direct call to select-frame is
the right way to go, but I need to test it some more before
torturing the rest of you.  As I've been experimenting, I've
enjoyed infloops and crashes, so I'd like to spare you if I
can. :)

