Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space

[Eli Zaretskii <eliz@gnu.org>]

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