Thanks.  The documentation on posn-object-* provides no guidance that a “string object” would not include a stretched string with specified space.  So it was not at all surprising to me that it worked "as expected" in the GUI.  In further support of this impression (leaving aside specified space), posn-object-x-y works perfectly well on normal width characters in the buffer, providing pixel level information on where *within the character* you clicked.  In fact I cannot think what "pixel-based x and y coordinates relative to the upper left corner” would mean other than this for a "string object".  Surely that is not an accident of the implementation!

But it sounds like internal position X/Y offsets for specified spaces in GUI vs. TTY are not reliable, so maybe I should stop using them.

Is there a reliable way to determine where (in pixels [1]) the mouse was clicked relative to a string displayed with specified space, which works equally in the GUI and TTYs?   Keep in mind that the string may not be at a fixed column, but at an arbitrary pixel offset from the window (due to prior specified space, variable width fonts, etc.).  

[1] Obviously in the TTY 1 pixel = 1 char.

On Nov 24, 2022, at 1:34 PM, Eli Zaretskii <eliz@gnu.org> wrote:

From: JD Smith <jdtsmith@gmail.com>
Date: Thu, 24 Nov 2022 12:22:44 -0500

The mouse-down events delivered by xterm-mouse-mode do not appear to handle clicks on entities with specified space display widths correctly.  Try this in a graphical window, and again in the terminal, with xterm-mouse-mode enabled:

(defun my/report-mouse (ev)
 (interactive "e")
 (let* ((posn (event-start ev))
(rel (posn-object-x-y posn)))
   (message "Got Relative Position %S" rel)))

(insert "\n\n  ----  "
       (propertize " "
                   'extend nil
                   'display '(space :width (48))
                   'keymap '(keymap (down-mouse-1 . my/report-mouse))
                   'font-lock-face 'underline)
       "  ----  ")

Mouse 1 click positions relative to the extended-width space (underlined for visibility) are reported correctly in graphical emacs, in screen pixel units.  With xterm-mouse-mode, however, relative positions are always reported as (0 . 0) for me, no matter where you click.  Is something wrong with my assumption that posn-object-x-y should work similarly in graphical as well as terminal emacs with xterm-mouse-mode (modulo the larger “pixel” size)?

This has nothing to do with xterm-mouse.  You simply expect something that
is not supported: when posn-object-x-y says OBJECT, it refers to what
posn-object can return, which is either a string or an image.  IOW, objects
that are Lisp objects, which Lisp programs can access and manipulate.  By
contrast, stretch glyphs produced by 'display' "space" specs are not objects
exposed to Lisp, and for them the X/Y offsets of mouse events are
meaningless.  That in case of GUI frames you get pixel offsets from the
beginning of the stretch is a side effect of the implementation of stretch
glyphs on GUI frames; the TTY implementation is different, so you always get
zero.  You will see the same in text terminals equipped with a mouse, like
when Emacs runs with -nw switch on a terminal with GPM mouse on GNU/Linux or
the MS-Windows shell window.

So bottom line, you shouldn't expect DX and DY offsets in click position
data to be meaningful in this case.