emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in CVS Emacs frame positioning under X


From: Francis Litterio
Subject: Re: Bug in CVS Emacs frame positioning under X
Date: Thu, 23 Mar 2006 14:53:34 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

On 3/22/06, I (Fran Litterio) wrote:

> On 3/22/06, Richard Stallman wrote:
>
> > In the latest CVS Emacs under X, there seems to be a frame positioning bug
> > that is timing related.
> >
> > Does it happen in older CVS versions too?  For instance,
> > did it happen a month ago?  6 months ago?
>
> Unknown. I'll check-out the older sources and rebuild. I'll let you know.

I have checked out the CVS Emacs source code from October 1, 2005, and
the bug existed at that time.  Additionally, I have found a simple way
to reproduce the problem:

  1. Start Emacs under the X Window system using the command: emacs -q

  2. Evaluate the following Elisp:

        (dolist (i '(1 2 3 4 5 6 7 8 9 a b c))
          (let ((frame (make-frame '((top . 50) (left . 50)))))
            (set-frame-position frame 200 200)
            (set-frame-position frame 300 300)
            (sit-for 0.5)))

You may have to evaluate the above Elisp more than once to see the
malfunction (although I see it every time).

The symptom is that not all of the frames end up positioned at x/y
coordinates 300/300.  Some frames are positioned at 300+A/300+B, where
A is the width of the left border drawn by the window manager and B is
the height of the top border drawn by the window manager.  Some frames
even end up at 400/400 !

I think the cause of this problem is the fact that src/xterm.c assumes
(incorrectly) that, after calling XMoveWindow() for a given frame, the next
ConfigureNotify event to be received for that frame will contain the position
data from the call to XMoveWindow().  In fact, the ConfigureNotify event can
sometimes contain the position of the frame before the call to XMoveWindow()
(this may be a race condition, but I'm not sure).

This incorrect assumption interacts badly with the code in
x_check_expected_move(), which attempts to use the position data from the most
recently received ConfigureNotify to validate that the most recent XMoveWindow()
call correctly positioned the frame.

I don't yet know how to fix this.
--
Fran Litterio






reply via email to

[Prev in Thread] Current Thread [Next in Thread]