From xemacs-m  Fri Feb 28 03:53:10 1997
Received: from frege.math.ethz.ch (root@frege-d-math-north-g-west.math.ethz.ch [129.132.145.3])
	by xemacs.org (8.8.5/8.8.5) with SMTP id DAA28753
	for <xemacs-beta@xemacs.org>; Fri, 28 Feb 1997 03:53:05 -0600 (CST)
Received: from fresnel.math.ethz.ch (vroonhof@fresnel [129.132.145.6]) by frege.math.ethz.ch (8.6.12/Main-STAT-mailer) with ESMTP id KAA19385; Fri, 28 Feb 1997 10:52:32 +0100
Received: (vroonhof@localhost) by fresnel.math.ethz.ch (8.6.9/D-MATH-client) id KAA16954; Fri, 28 Feb 1997 10:51:16 +0100
Sender: vroonhof@math.ethz.ch
To: xemacs-beta@xemacs.org
Cc: dkindred@cmu.edu
Subject: Re: 19.15b95: delayed redisplay bug [w/ PATCH]
References: <9702272040.AA37950@GS213.SP.CS.CMU.EDU> <m2zpwpoo7o.fsf@altair.xemacs.org>
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
From: Jan Vroonhof <vroonhof@math.ethz.ch>
Date: 28 Feb 1997 10:51:15 +0100
In-Reply-To: Steven L Baur's message of 27 Feb 1997 14:53:31 -0800
Message-ID: <by67zdb6ng.fsf@math.ethz.ch>
Lines: 96
X-Mailer: Gnus v5.4.13/XEmacs 19.15

Steven L Baur <steve@miranova.com> writes:

> > In 19.15b95, I've noticed the following bug.  (I'm not sure
> > whether it's been reported before.)

Thank you Darell. The bug was noticed (it annoyed the hell out of
Steve) but we fixed it the other way not knowing the proper solution was that
simple.

> Darrell's patch corrects the problems I had that were introduced with
> Jan's patch.  I don't like the `Attempt to delete the sole visible or
> iconified frame' when another frame is open but situated on an
> undisplayed virtual console, but I'll survive.

If you will just release b96 with Darell's patch, I'll do what I can :-)

It should be not so difficult to fix that. I think best would be to
change f->visible into a tristate flag. With

f->visible = 0            (Window is unmapped)
f->visible = 1            (Mapped and X-visible)
f->visible = -1           (Mappend and X-invisble)

Then all the redisplay code should check for (f->visible > 0) but the
frame deletion stuff etc can just check for !f->visible.

The difficulty is to know which flags to set for which changes of this
state.

> --- frame-x.c	1997/02/27 06:08:44	1.3
> +++ frame-x.c	1997/02/27 22:11:02
> @@ -2287,18 +2287,8 @@
>  			     XtWindow (FRAME_X_SHELL_WIDGET (f)),
>  			     &xwa))
>      result = 0;
> -#ifdef 0
> -  /* This is wrong. Under XEmacs visible means "Mapped" not really visible.
> -     Under virtual window managers this causes freezes. JV
> -
> -     Fixme: This might be need to be changed, or another
> -            frame->RealyVisible may need to be added to guide the actual
> -	    redisplay. */
>    else
>      result = xwa.map_state == IsViewable;
> -   For now this better.
> -#endif
> -    result = (xwa.map_state != IsUnmapped);
>       
>    f->visible = result;
>    return result;

I am not sure that this is the right thing to do. The problem is
because of this name confusion the current f-visible-p really returns
t if the window is mapped, not caring what to do with the true
visibility state. I think this still what is really wanted hecause of
doc strings like that of set-mouse-position recommending

[
If you have just created a frame, you must wait for it to become visible
before calling this function on it, like this.
  (while (not (frame-visible-p frame)) (sleep-for .5))
]

May be we should make frame-visible-p return

 nil :  The frame is not mapped
 t : Frame is mapped and visible
 hidden  : Frame is mapped and invisible 

This will make the above code work. It will also compatible with the
behaviour out of the lisp manual

- Function: frame-visible-p FRAME
     This returns whether FRAME is currently "visible" (actually in use
     for display).  A frame that is not visible is not updated, and, if
     it works through a window system, may not show at all.
We must loose somewhere however: the current doc string says

Return t if FRAME is now "visible" (actually in use for display).

:-(. I think this awful anyway and we should make this "return non nil".

> +      MARK_FRAME_WINDOWS_STRUCTURE_CHANGED (f);

I setting this the important part.

> +      va_run_hook_with_args (Qmap_frame_hook, 1, frame);

I think this is wrong. map-frame-hook should only be called when the
frame is really mapped. Does anybody use map-frame-hook?

Does that look alright to you? This means I'll have to find out how
define a new hidden atom.


Jan

