RE: Display-relative coordinates

RE: Display-relative coordinates

[Drew Adams]

> There is not enough information in the above, and also some surprising
> data.  First, you don't tell how you measure pixels from the screen
> corner.  

MB Ruler: http://www.markus-bader.de/MB-Ruler/index.php

> You don't tell what location of the character cells you take
> as its coordinates.

I did say that I measured to the bottom of the cursor (block).
And I did say that I got the char height as 12 pixels.

> You also say that the height of a character is 12 pixels, but
> the default height of a line in "emacs -Q" is 16, not 12.

I believe I measured it.  Measuring it again now: 12 pixels for
a char.  And in 1/10 pt, face `default' has height 102.  (And no,
char height does not include interline height.)

FWIW, in my emacs -Q:
(font . "-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1")

I mentioned char height only to let you know that I measured to
the bottom of the cursor (as I said).  If you want to instead
use the bottom of the cursor on the previous line (so as to
include the interline height), and you want to use 16, then
420 - 16 = 404, instead of the 420 - 12 = 408 that I reported
using char height.  Still not the same as 354.  Again, perhaps
I'm missing something.

> Maybe you could go line by line starting at the first line of the
> window, show the pixel coordinates of the first (leftmost) character
> on that line, and then tell which part(s) of the results don't look
> correct to you.

Sorry, I'm done with this.

> FWIW, if I move a frame such that point is at one of the 4 corners of
> the screen, and compute its pixel coordinates using posn-at-point and
> frame-geometry, I get a very good approximation (within a couple of
> pixels) of my screen dimensions, so I don't think there's a problem in
> these functions.

"Tout va tres bien, Madame La Marquise."

If you're convinced that `posn-at-point' has no problem, fine by me.

I think Martin answered the question of what to use, to get the
screen-relative pixel coordinates of a buffer position:
`window-absolute-pixel-position'.  (But it is not available before
Emacs 25.)

Re: Display-relative coordinates

[Eli Zaretskii]

> Date: Fri, 29 Jul 2016 08:38:19 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> > You don't tell what location of the character cells you take
> > as its coordinates.
> 
> I did say that I measured to the bottom of the cursor (block).

The y-coordinate of a character cell is for its left-top corner, not
the bottom.  Otherwise, how could the first line have the y-coordinate
of zero?

> > You also say that the height of a character is 12 pixels, but
> > the default height of a line in "emacs -Q" is 16, not 12.
> 
> I believe I measured it.  Measuring it again now: 12 pixels for
> a char.  And in 1/10 pt, face `default' has height 102.  (And no,
> char height does not include interline height.)

There's no "interline height" (a.k.a. "line spacing") in the default
face.  And characters don't have the same height in a font, so "12
pixels for a char" is a meaningless utterance.

> I mentioned char height only to let you know that I measured to
> the bottom of the cursor (as I said).  If you want to instead
> use the bottom of the cursor on the previous line (so as to
> include the interline height), and you want to use 16, then
> 420 - 16 = 404, instead of the 420 - 12 = 408 that I reported
> using char height.  Still not the same as 354.  Again, perhaps
> I'm missing something.

You most definitely are, but we will never know what that is.

> > Maybe you could go line by line starting at the first line of the
> > window, show the pixel coordinates of the first (leftmost) character
> > on that line, and then tell which part(s) of the results don't look
> > correct to you.
> 
> Sorry, I'm done with this.

And I'm done answering your questions, because each time I try, I end
up wasting my time, when you unilaterally decide to stop bothering.

RE: Display-relative coordinates

[Drew Adams]

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

Re: Display-relative coordinates

[Eli Zaretskii]

> Date: Thu, 28 Jul 2016 13:20:35 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> 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...

There is not enough information in the above, and also some surprising
data.  First, you don't tell how you measure pixels from the screen
corner.  You don't tell what location of the character cells you take
as its coordinates.  You also say that the height of a character is 12
pixels, but the default height of a line in "emacs -Q" is 16, not 12.

Maybe you could go line by line starting at the first line of the
window, show the pixel coordinates of the first (leftmost) character
on that line, and then tell which part(s) of the results don't look
correct to you.

FWIW, if I move a frame such that point is at one of the 4 corners of
the screen, and compute its pixel coordinates using posn-at-point and
frame-geometry, I get a very good approximation (within a couple of
pixels) of my screen dimensions, so I don't think there's a problem in
these functions.

Display-relative coordinates

[Eli Zaretskii]

Moved here from bug-gnu-emacs.

> I've been fiddling a bit with test code like this, but haven't
> really found anything reasonable yet:

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

Re: Display-relative coordinates

[martin rudalics]

 >> I've been fiddling a bit with test code like this, but haven't
 >> really found anything reasonable yet:
 >
 >> ;; 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?).

FWIW ‘window-inside-absolute-pixel-edges’ didn't work on Windows before
Emacs 25.  On Emacs 25 ‘window-absolute-pixel-position’ is all that's
needed.

martin

RE: Display-relative coordinates

[Drew Adams]

>  > 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?).
> 
> FWIW ‘window-inside-absolute-pixel-edges’ didn't work on Windows before
> Emacs 25.  On Emacs 25 ‘window-absolute-pixel-position’ is all that's
> needed.

I see.  See my reply to Eli too, however.  In the example I gave using
an Emacs 25 build (not very recent) it returned good results, but
`posn-at-point' seemed to be off.

Anyway, I'm glad to see `window-absolute-pixel-position' and `frame-geometry'.

It would still be useful, I think, to have a function that returns
directly the screen-relative pixel coordinates (i.e., even though
that can be got using `window-absolute-pixel-position' and
`frame-geometry'.)

Re: Display-relative coordinates

[martin rudalics]

 > It would still be useful, I think, to have a function that returns
 > directly the screen-relative pixel coordinates (i.e., even though
 > that can be got using `window-absolute-pixel-position' and
 > `frame-geometry'.)

‘window-absolute-pixel-position’ does that already.  Quoting the Elisp
manual:


  -- Function: window-absolute-pixel-position &optional position window
      If the buffer position POSITION is visible in window WINDOW, this
      function returns the display coordinates of the upper/left corner
      of the glyph at POSITION.  The return value is a cons of the X-
      and Y-coordinates of that corner, relative to an origin at (0, 0)
      of WINDOW's display.  It returns `nil' if POSITION is not visible
      in WINDOW.

      WINDOW must be a live window and defaults to the selected window.
      POSITION defaults to the value of `window-point' of WINDOW.

      This means that in order to move the mouse pointer to the position
      of point in the selected window, it's sufficient to write:

           (let ((position (window-absolute-pixel-position)))
             (set-mouse-absolute-pixel-position
              (car position) (cdr position)))


Note the example given at the end.  ‘set-mouse-absolute-pixel-position’
warps the mouse pointer on your screen without any knowledge of the
existence or position of frames/windows on that screen.  You can use
that function as an acid test for your own favorite function's ability
to retrieve precise screen coordiantes.

martin

RE: Display-relative coordinates

[Drew Adams]

>  > It would still be useful, I think, to have a function that returns
>  > directly the screen-relative pixel coordinates
> 
> ‘window-absolute-pixel-position’ does that already.

I see.  Sounds good to me.  As I said, in the Emacs 25 build I have,
which is not recent, for a measured value of 354 pixels it returned
335 pixels.  And that difference corresponds, I guess, to the fact
that I measured to the cursor bottom, whereas `w-a-p-p' returns
the distance (height) to the "upper/left corner of the glyph at
POSITION."  The height of a line in emacs -Q, as Eli says, is 16,
and 354 - 16 = 338, which is ~335.  I only measured visually, and
my eye was probably off by 3 pixels for this.