From xemacs-m  Sun Jun  1 07:34:54 1997
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id HAA18678
	for <xemacs-beta@xemacs.org>; Sun, 1 Jun 1997 07:34:30 -0500 (CDT)
Received: (from hniksic@localhost)
          by jagor.srce.hr (8.8.5/8.8.4)
	  id OAA08076; Sun, 1 Jun 1997 14:34:10 +0200 (MET DST)
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: [PATCH] 20.3-b3: new tty frame selected too soon
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> <QQcrzz05146.199706010549@crystal.WonderWorks.COM>
X-Attribution: Hrv
X-Face: Mie8:rOV<\c/~z{s.X4A{!?vY7{drJ([U]0O=W/<W*SMo/Mv:58:*_y~ki>xDi&N7XG
        KV^$k0m3Oe/)'e%3=$PCR&3ITUXH,cK>]bci&<qQ>Ff%x_>1`T(+M2Gg/fgndU%k*ft
        [(7._6e0n-V%|%'[c|q:;}td$#INd+;?!-V=c8Pqf}3J
Emacs: Lovecraft was an optimist.
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 01 Jun 1997 14:34:09 +0200
In-Reply-To: Kyle Jones's message of Sun, 1 Jun 1997 01:49:34 -0400 (EDT)
Message-ID: <kig910upkn2.fsf@jagor.srce.hr>
Lines: 79
X-Mailer: Gnus v5.4.52/XEmacs 20.2

Kyle Jones <kyle_jones@wonderworks.com> writes:

>  > 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.

This doesn't make it less flawed, because there still are frames I'd
like to select which are flagged as invisible.  TTY frames, for one.

> 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'

They would be skipped by `C-x 5 o' if it weren't for the rude patch to 
`next-frame'.

> as they should be.

Hmm.

> 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.

I didn't know about that code, but it would be a good point to it.

> 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.

I'm not sure I'd like it to be the default (because it would make it
hard to access any frames other than VM frames), but it would make for 
a good user-configurable option.

>  > > 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.

Yup.

> 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.

Oh, now I think I see.  So all of them should be "visible", with some
on top of others?  And the redisplay engine + selection handling will
cope with that?  Cool.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
WWW:  World-Wide-Waste.  Waste management corporation, which
      handles the billions of tons of garbage generated by just
      about everybody these days.

