emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Display-relative coordinates


From: Drew Adams
Subject: RE: Display-relative coordinates
Date: Thu, 28 Jul 2016 13:20:35 -0700 (PDT)

> > ;; 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]