From xemacs-m  Thu Feb 27 12:15:45 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 MAA07312
	for <xemacs-beta@xemacs.org>; Thu, 27 Feb 1997 12:15:10 -0600 (CST)
From: vroonhof@math.ethz.ch
Received: from riesz.math.ethz.ch (vroonhof@riesz [129.132.145.81]) by frege.math.ethz.ch (8.6.12/Main-STAT-mailer) with ESMTP id TAA14154; Thu, 27 Feb 1997 19:14:48 +0100
Received: (vroonhof@localhost) by riesz.math.ethz.ch (8.6.12/D-MATH-client) id TAA18477; Thu, 27 Feb 1997 19:13:43 +0100
Message-Id: <199702271813.TAA18477@riesz.math.ethz.ch>
Subject: Re: 19.15b95 geometry spec make frame undeletable
To: mdb@cdc.noaa.gov (Mark Borges)
Date: Thu, 27 Feb 1997 19:13:43 +0100 (MET)
Cc: xemacs-beta@xemacs.org
In-Reply-To: <vk7mju2n95.fsf@cdc.noaa.gov> from "Mark Borges" at Feb 27, 97 10:05:10 am
X-Mailer: ELM [version 2.4 PL24 PGP2]
Content-Type: text


[list cc'ed because this mail contains an explanation for the patch]

Hi Mark,

Let me cite you out of order.

> I use fvwm (v2.0.45), and perhaps the single most annoying thing with
> XEmacs-20.x (or 19.x for that matter) is the periodic non-redisplay
> when moving about the virtual desktop. An iconify/de-iconify sequence
> brings the XEmacs frame back to life, but this work-around gets old
> quickly.

I found it very annoying too. However I got a lucky break. I found a
way to reproduce the problem almost always. (It involved Gnus, quitting
and catching up in a large group and some virtual desktop flipping).
When I reported this to Steve he reported that Dave had already fixed
the problem for 19.15 and higher. This (and the problem getting more
and more annoying) again lead me to get the betas in the hope I got
rid of it. It didn't work.

So I sat down and an evening of virtual screen flipping with emacs
under gdb and using xev followed. I sure learned a lot about XEmacs redisplay
and X :-). The problem occurs when lisp code calls to frame-visible-p
for a "hidden" frame.

To reproduce: Fire up XEmacs (<19.15-b95 or <20.1-b3) and gnuserv,
switch to another virtual page, open an xterm and type

gnudoit (frame-visible-p (nth 0 (frame-list)))

This should return 'nil' and upon return to the XEmacs frame it is not
properly redisplayed, which I call freezing. (With the fix
frame-visible-p returns t))

> Is that what the `#if 0' segment above attempts to fix? I'm not sure
> if this is what you mean by "freezes". If so, can you provide a
> replacement x_frame_visible_p() -- it appears the patch was mangled
> above.

Yes. Change the #ifdef 0 to #if 0 and you should be fine. It was my
brain that was mangled. Unfortunately the #ifdef 0 works under gcc.
The #if 0 comments out the old, 'wrong' version.

So the old was
     result = xwa.map_state == IsViewable;
     f->visible = result;
and I changed it too
     result = (xwa.map_state != IsUnmapped);
     f->visible = result;

This one way to fix the frame freeze problem. b95 contained an
attempted at a another which had some unfortunate side effects (made the
frame undeletable) and caused problems under olvwm. The current way is
less correct but is simple and works. The more elegant way will have
to wait, probably for later in the 20.x series.

The problem is the following
There are two kinds of visibility with Emacs under X (FSF has the same
problem). There is the f->visible member of the Emacs frame structure
and there is the visibility as reported by the X-Server.

BUT:
Under Emacs f->visible = 1 means "mapped" (i.e. the frame is displayed
"somewhere") which is not the same as the X-visibility if you have a
virtual window manager. Then all the windows on other virtual screens
are Mapped (Emacs visible) but not "X"-visible.
Unfortunately Emacs uses it's idea of visible to optimize the
redisplay and therefore unnecessarily redisplays "hidden" frames.

Now where does frame-visible-p come in? It doesn't trust the
f->visible flag and checks itself. However because of the above
confusion it checks for X-visibility not "Mapped"-ness (or rather it
used to do) _and sets the flag_. So whenever both properties are not
the same (i.e. a frame on another virtual screen) the f->visible flag
gets set to the wrong (i.e. the X way) visibility. This means that
Emacs now thinks the frame is invisible and will no longer redisplay.
Iconizing and de-iconizing (unmapping and mapping the frame) helps
because then Emacs sets the f->visible flag again.

The proper way to fix this is would be to make the Emacs-visible
status closer to the X one. This will get rid of all the superfluous
redisplay too. However it turns out to be nontrivial so thats why
Steve just integrated my patch to fix f-visible-p to check for "The
Emacs Way".


I hope the above was at least close to understandable,

ciao,

Jan

