From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Politz Newsgroups: gmane.emacs.bugs Subject: bug#5721: Feature request: Function that returns absolute coordinates Date: Sun, 29 Sep 2013 19:21:29 +0200 Message-ID: <87eh87tug6.fsf@hochschule-trier.de> References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <4A35A160-E728-4617-A65E-D79EC75B88D2@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1380475332 17457 80.91.229.3 (29 Sep 2013 17:22:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Sep 2013 17:22:12 +0000 (UTC) Cc: 5721@debbugs.gnu.org To: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 29 19:22:16 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VQKhD-0001Xg-KK for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Sep 2013 19:22:15 +0200 Original-Received: from localhost ([::1]:45481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQKhD-0001u8-6p for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Sep 2013 13:22:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQKh5-0001u0-T0 for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2013 13:22:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VQKh1-0005tP-8C for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2013 13:22:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQKh1-0005tJ-3m for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2013 13:22:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VQKh0-0003jy-Gs for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2013 13:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas Politz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Sep 2013 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5721 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5721-submit@debbugs.gnu.org id=B5721.138047531214363 (code B ref 5721); Sun, 29 Sep 2013 17:22:02 +0000 Original-Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 17:21:52 +0000 Original-Received: from localhost ([127.0.0.1]:45008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQKgp-0003jZ-D2 for submit@debbugs.gnu.org; Sun, 29 Sep 2013 13:21:51 -0400 Original-Received: from gateway-a.fh-trier.de ([143.93.54.181]:37021) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQKgk-0003jO-JV for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 13:21:47 -0400 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier] Original-Received: from luca (dslb-084-059-253-081.pools.arcor-ip.net [84.59.253.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 5B24517608DD; Sun, 29 Sep 2013 19:21:30 +0200 (CEST) Original-Received: from politza by luca with local (Exim 4.72) (envelope-from ) id 1VQKgT-0003Dq-Mo; Sun, 29 Sep 2013 19:21:29 +0200 In-Reply-To: <4A35A160-E728-4617-A65E-D79EC75B88D2@swipnet.se> ("Jan =?UTF-8?Q?Dj=C3=A4rv?="'s message of "Sun, 29 Sep 2013 18:05:43 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:78806 Archived-At: Jan Dj=C3=A4rv writes: >> This is known to be wrong. For example, if some Gtk+ version does >> create separate X windows [...] So, it depends on the toolkit and in some cases the tool-kit's version. > Forgot to mention that the window manager window that the title bar is > drawn in does not need to be a parent of any Emacs X window. In that > case you can not get the size of the decorations at all. > ,,does not need'' does not mean that any window manager does this. Care to give an example ?=20=20 Also the size of the decoration doesn't really matter, as long as we can figure out the difference between the absolute frame position and the start of the edit window. Or could it also be possible, that the frame's absolute position (left, top) does point to the coordinates of a window of which the inner Emacs window is not a child ? >>> [...] Anyway the only problem I sometimes ran into is a race >>> condition, resulting in y_pixels_diff being to small. But this is only >>> temporarily [...] >> Race conditions are common when a window manager is involved. >> Another reason to keep pixels private and not export them to Elisp. Just something that has to be dealt with. Either way the function exists and we can try to fix it or remove it. I don't see what purpose it serves in it's current state. The request came from the author of auto-complete, a package which displays completion candidates and their documentation with overlays and tool-tips at point. I'd like to see this move forward and, in the end, use undecorated frames instead. Without this function, this is impossible without external programs. BTW any other recent editor does this (e.g. http://cdn3.cybernetnews.com/wp-content/uploads/2008/06/notepad-5.png= ), so I doubt that it's 'impossible'. -ap P.S.: I tried the patch on a bare --with-x-toolkit=3Dno build and it seems to give the correct values.