From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Display-relative coordinates Date: Thu, 28 Jul 2016 13:20:35 -0700 (PDT) Message-ID: References: <<831t2dsu3y.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1469737300 21309 80.91.229.3 (28 Jul 2016 20:21:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Jul 2016 20:21:40 +0000 (UTC) To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 28 22:21:28 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bSro5-0002eA-KF for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2016 22:21:25 +0200 Original-Received: from localhost ([::1]:55493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSrnz-0002Ha-20 for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2016 16:21:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSrnQ-0002HU-VV for emacs-devel@gnu.org; Thu, 28 Jul 2016 16:20:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSrnP-0001TT-Q4 for emacs-devel@gnu.org; Thu, 28 Jul 2016 16:20:44 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:47429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSrnL-0001SX-98; Thu, 28 Jul 2016 16:20:39 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6SKKbFH028413 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2016 20:20:38 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u6SKKbCw022619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2016 20:20:37 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u6SKKaTC023064; Thu, 28 Jul 2016 20:20:36 GMT In-Reply-To: <<831t2dsu3y.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206214 Archived-At: > > ;; Try to get screen-relative X, Y (pixels) for current point > > (let* ((posn-at-pt (posn-at-point)) > > (x-y (and posn-at-pt (posn-x-y posn-at-pt))) > > (win-edges (and x-y (window-inside-absolute-pixel-edges))) > > (x (and x-y (+ (car x-y) (car win-edges)))) > > (y (and x-y (+ (cdr x-y) (cadr win-edges)))) > > (y (and y (top-fudge-pixels y)))) > > ...) >=20 > > (defun top-fudge-pixels (y) > > (let ((y2 y)) > > (when tool-bar-mode (setq y2 (+ 40 tp))) > > (when menu-bar-mode (setq y2 (+ 25 tp))) > > (setq y2 (+ y2 28)) ; Frame title bar > > y2)) >=20 > What are the problems you see with the above (except that 'tp' is a > void variable)? It looks OK to me, modulo the kludges in > top-fudge-pixels (why not use frame-geometry, which exists for that > purpose?). (`tp' should have been `y2'. I simplified and renamed some stuff that I copied from some test code, and I missed renaming those two occurrences of `tp' to `y2'.) `frame-geometry': (1) I didn't know about it. (2) It does not exist before Emacs 25, and I cannot currently use Emacs 25, as you know (crashes). But thanks for pointing me to `frame-geometry' - looks very useful. I've been hoping for something like that for quite a while. I will use it in future code I write for others, who can use Emacs 25. `frame-geometry' is definitely the thing to use here, rather than fudging. The code I quoted was just test code - so I used a literal 40 pixels etc. But in other code I've provided user options for such fudge factors, so users can at least adjust things to their setups. But doing that was just a workaround, for lack of any way of getting the correct values dynamically. Now there is a way: `frame-geometry'. As for how well the above code works: It works fairly well, but actually measuring pixels suggests that (posn-x-y (posn-at-point)) is at least sometimes off a bit. For example, with emacs -Q, I measure a top-left window position of, say, (15, 115) pixels from the top-left screen corner, for a single-window frame. And that corresponds correctly with what I get for `(window-inside-absolute-pixel-edges)': (15 115 784 722). At a given point (buffer position) in the window I measure a vertical distance from the screen top edge as 354 pixels. But if I try to calculate that then I get 420 instead: (posn-x-y (posn-at-point)) =3D (350 . 220) frame title bar + menu-bar + tool bar, using `frame-geometry' =3D 85 (and this corresponds to measuring this distance: ~88) (My original code, which you quoted, guessed at about 93 pixels for title bar + menu-bar + tool bar.) 220 + 115 (from w-i-a-p-e) + 85 =3D 420, not 354. Since the 85 and the 115 correspond to what I measure, it seems that the 220 value of y from (posn-x-y (posn-at-point)) is wrong. I measured to the bottom of the cursor, not the top. If I account for the height of a character (12 pixels) then I get 408, but that's still quite different from 354. And FWIW, `window-absolute-pixel-position' (for a not-too-recent Emacs 25 build) returned 335 for the same distance. So: measured =3D 354 window-absolute-pixel-position =3D 335 calculated using frame-geometry, posn-at-point, and window-inside-absolute-pixel-edges =3D 408 or 420 (char top/bottom) Perhaps I'm overlooking something... In any case, even if it is possible to calculate the absolute x and y pixel screen coordinates, I think it would be good to have a function that gives that directly.