From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: RE: Display-relative coordinates
Date: Thu, 28 Jul 2016 13:20:35 -0700 (PDT) [thread overview]
Message-ID: <bd748cdc-2ab2-4576-9e85-1040706ffcc8@default> (raw)
In-Reply-To: <<831t2dsu3y.fsf@gnu.org>>
> > ;; 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))))
> > ...)
>
> > (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))
>
> 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)) = (350 . 220)
frame title bar + menu-bar + tool bar, using `frame-geometry' = 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 = 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 = 354
window-absolute-pixel-position = 335
calculated using frame-geometry,
posn-at-point, and
window-inside-absolute-pixel-edges = 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.
next parent reply other threads:[~2016-07-28 20:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<831t2dsu3y.fsf@gnu.org>
2016-07-28 20:20 ` Drew Adams [this message]
2016-07-29 13:39 ` Display-relative coordinates Eli Zaretskii
[not found] <<<831t2dsu3y.fsf@gnu.org>
[not found] ` <<bd748cdc-2ab2-4576-9e85-1040706ffcc8@default>
[not found] ` <<83d1lwr2at.fsf@gnu.org>
2016-07-29 15:38 ` Drew Adams
2016-07-29 17:42 ` Eli Zaretskii
2016-07-28 14:41 Eli Zaretskii
2016-07-28 19:07 ` martin rudalics
2016-07-28 20:20 ` Drew Adams
2016-07-29 5:54 ` martin rudalics
2016-07-29 15:38 ` Drew Adams
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd748cdc-2ab2-4576-9e85-1040706ffcc8@default \
--to=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).