Re: x-popup-menu pops up at funny positions

["Jan D." <jan.h.d@swipnet.se>]

>     > Instead of just deleting that code, can you replace it with code
>     > that does the right job?
> 
>     I did that.  The additions to x/y before assigning them to dummy.root_x/y.
> 
> We are miscommunicating.  "The job" I'm talking about is to read the
> current position.  I'm asking you to correct the code to read the
> current position, instead of deleting it.

I could add a call to x_real_positions.  Any correction
would look exactly like the code in x_real_positions.

> You're claiming that the current position is always accurate, so there
> is no need to read it.  That might be true, but without being able to
> prove this to ourselves informally, I don't think we should rely on it.

How about this:

There is no way to move a window in X without getting a ConfigureNotify
(disregarding buggy X servers, which we can't compensate for anyway).
The code for ConfigureNotify updates the real position by calling
x_real_positions.  So if Emacs gets to the case ConfigureNotify: in
the event switch, the position is correct.

Can we get a ConfigureNotify without hitting the case ConfigureNotify:
code?  Yes, if we are doing a recursive X event loop.  There are two such
instances, one in xmenu.c, popup_get_selection and one in xfns.c,
Fx_file_dialog.  The solution suggested is to take advantage of
the split that the GTK patch does, so the case ConfigureNotify code
is executed even for recursive X event loops.

> So how about writing code to read the current position, compare it
> with the recorded position, and abort if they differ?  That way
> we will find out if it isn't always right.

Abort sounds a bit drastic, how about popping up a dialog instead?

	Jan D.