Michael Sperber writes:
I meant that this aspect of the behavior of window configurations is
undocumented. What exactly are you referring to?
I'm referring to the X Window System standard for configuring top
level X windows, ie, XEmacs frames. This interaction is specified in
the ICCCM, and I think freedesktop.org
has since extended the
specification, but the basic idea is what I said: the window manager's
idea of what the configuration of a frame's X window is should be
respected, because that came directly from the user. I have trouble
thinking of a sane use-case where that might not be true. (The window
manager is able to enforce its wishes in any case, so Lisp has to be
prepared to be unable to do what it wants to.)
Now, this can happen asynchronously to a Lisp program, as happens here
when Lisp pauses to interact with the user and the user decides to
talk to the window manager first. In that case returning to a window
configuration that requires adjusting the size of the top-level window
against the user's express wish is clearly a no-no. This is more
generally true, however, and violating the principle has caused us
pain in the past (the metacity maximization bug).
It may be that the behavior of window configurations hasn't been
documented to conform to these basic principles of window management
on X, but I think we should conform unless we have a very good reason
not to. And I think that is what policy to date has been; it's just
been buggily implemented so far because of a misunderstanding of how
this works out in practice.
AFAICT, EmacsFrame.c and friends assume that the window manager *will*
enforce its idea of what the X window's size should be. Thus the
window can never be different from what the window manager wants, and
so any time XEmacs would like a different configuration, it may as
well ask for it. What happens in practice, though, is that window
managers seem to assume that applications by and large will not make a
lot of requests from them except when the user explicitly configures
them. So when XEmacs tries to negotiate with them, they assume that
XEmacs knows better than they do what the user wants. metacity is
even more confused than that, but I won't go into detail unless you
ask. The conclusion is that XEmacs needs to be careful not to ask for
changes unless it has a mandate from the user to ask for them.
So I think what should happen in restoring a window configuration is
(1) Lisp should check whether the current frame dimensions are
different from the saved dimensions of the frame.
(2) If they have not changed, go to (4); else
if they have changed but a force-toplevel-reconfiguration flag
is nil, go to (3); else
ask the window manager to change the frames dimensions back, and
on failure go to (3);
else go to (4).
(3) Find out what the new toplevel dimensions are, and then reassign
window real estate to the Emacs windows and other frame
components, overriding the values in the saved configuration.
(4) Restore the Emacs windows from the configuration.
Now, I think this probably needs C level support to do right. But I
think the Lisp level code needs to be aware that it may need to adjust
to new frame paramters even when restoring a window configuration.
 And in general the frame position seems intuitively to be
somewhat harder to think about. At least I don't worry anywhere near
as much about frame position as I do about frame size, so I suspect
I'd be a lot more willing to let XEmacs reposition frames -- eg, in
the case of a cooperative set like in ediff with its control frame, I
*would* want XEmacs to move the control frame "close" to but not
obscuring the "working" frame.
XEmacs-Beta mailing list