From: "Jan D." <jan.h.d@swipnet.se>
Cc: emacs-devel@gnu.org
Subject: Re: x-popup-menu pops up at funny positions
Date: Mon, 6 Jan 2003 19:41:11 +0100 (CET) [thread overview]
Message-ID: <200301061942.h06Jgae0010061@stubby.bodenonline.com> (raw)
In-Reply-To: <E18VaoA-0002Jf-00@fencepost.gnu.org> "from Richard Stallman at Jan 6, 2003 12:13:02 pm"
> > 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.
next prev parent reply other threads:[~2003-01-06 18:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 16:15 x-popup-menu pops up at funny positions Jan D.
2003-01-03 17:14 ` Jan D.
2003-01-04 4:20 ` Richard Stallman
2003-01-04 13:25 ` Jan D.
2003-01-05 18:33 ` Richard Stallman
2003-01-05 22:05 ` Jan D.
2003-01-06 0:13 ` Jan D.
2003-01-06 17:13 ` Richard Stallman
2003-01-06 18:41 ` Jan D. [this message]
2003-01-07 13:40 ` Richard Stallman
2003-01-07 17:47 ` Jan D.
2003-01-08 8:00 ` Richard Stallman
2003-01-08 20:07 ` Jan D.
-- strict thread matches above, loose matches on Subject: below --
2003-01-06 18:46 Jan D.
2003-01-09 7:27 ` Richard Stallman
2003-01-09 21:02 ` Jan D.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200301061942.h06Jgae0010061@stubby.bodenonline.com \
--to=jan.h.d@swipnet.se \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.