From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space Date: Thu, 24 Nov 2022 16:42:29 -0500 Message-ID: <5BBC7E49-41C3-4693-95F6-26E8EAC7F7A4@gmail.com> References: <835yf4w6a7.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_70D52D62-0F72-4824-805B-A8F808409111" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18029"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 24 22:45:32 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oyK2G-0004U6-J8 for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Nov 2022 22:45:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oyJzT-0000Yb-LH; Thu, 24 Nov 2022 16:42:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyJzT-0000YS-2S for emacs-devel@gnu.org; Thu, 24 Nov 2022 16:42:39 -0500 Original-Received: from mail-io1-xd30.google.com ([2607:f8b0:4864:20::d30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oyJzQ-0007KX-T9; Thu, 24 Nov 2022 16:42:38 -0500 Original-Received: by mail-io1-xd30.google.com with SMTP id e189so1939575iof.1; Thu, 24 Nov 2022 13:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=mcGQTzoslraEumhXFcqZi9CNmeFIB1HAPwK+nuYWq6s=; b=PWt/9C4S6OYUVnpwAEnQd6wqONTSqaMfrtNxEOuR8/QRLFANGkH4B1JBMm0CMuwdKX 29eGZ4p1UyVf3utP7WVn+EPNQxnRPCsMM1w+t15TtrBBSFVfgEO72GO06apWf2qfyYHS eOtuf2TJgeG5PHn8Xvj8/te7QgfORZlTZkLyPXWvzOdU5114gOIbw66H4c81XnKJbCNf lC0PfJQtqjIr9OcPuibfy3QpxLZcAS2mAzIdRHlfg63en1LhyM3q12BOwd6Ha9nSlBiU /lQ5LgUBRtC1fu5YsRD2haEcTM2rYlUYeSKRzZSBB+LyDuyX4myhDNZtEPexyGb6YNW8 3s3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mcGQTzoslraEumhXFcqZi9CNmeFIB1HAPwK+nuYWq6s=; b=WgjLO2JN94HuIJWTHeVRcUAajTMGKRnhFeBmia0N35n//+6W6h8AP4js8ikRsUHsp5 TIrKgFIEtyCw5ZJ/DkZQb1C08MXC7mxUZdK4IECucn51r4ECwP87uj5yDwNFqfTqUSOi vpFJMHA0FJD2nkvHjS//e2SqNpN4kLzKgTwDVgxMzy8MEjHMIhZxjo9Mcbt8CU2K7Pxd KQwQ35JSxfUSq42I3PZq0qhd8i/9I0PlmooZDo+o8MUCA3AHatWPUZ8v017rL9Qdg4eO 8ETHmJMxe+lGXOo88qbf070FC9TFCC4m9HRmJ/Ahv1ad5k53RcnSLxhR7uIK6gs8sr8H xIbA== X-Gm-Message-State: ANoB5pl/Uze45JoI/G8+EnXXv+YGURj3DNZSVDVPDD6G4VMdjKK06ZkO WIZcGla4P2kcA8Cv8geXYbZZml03EfQ= X-Google-Smtp-Source: AA0mqf7OirZjXiVpxOfNx1BXtb2Gv66+R5SZnkMpA5bIiJ0+guDqR6H5acrqiFfRU/xtFS+sBG4m9A== X-Received: by 2002:a5d:8046:0:b0:6de:754e:4427 with SMTP id b6-20020a5d8046000000b006de754e4427mr7339716ior.17.1669326154851; Thu, 24 Nov 2022 13:42:34 -0800 (PST) Original-Received: from smtpclient.apple (cm-24-53-184-207.buckeyecom.net. [24.53.184.207]) by smtp.gmail.com with ESMTPSA id u6-20020a056e02080600b00300b9b7d594sm741424ilm.20.2022.11.24.13.42.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2022 13:42:33 -0800 (PST) In-Reply-To: <835yf4w6a7.fsf@gnu.org> X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::d30; envelope-from=jdtsmith@gmail.com; helo=mail-io1-xd30.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300445 Archived-At: --Apple-Mail=_70D52D62-0F72-4824-805B-A8F808409111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks. The documentation on posn-object-* provides no guidance that a = =E2=80=9Cstring object=E2=80=9D 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=E2=80=9D 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.). =20 [1] Obviously in the TTY 1 pixel =3D 1 char. > On Nov 24, 2022, at 1:34 PM, Eli Zaretskii wrote: >=20 >> From: JD Smith >> Date: Thu, 24 Nov 2022 12:22:44 -0500 >>=20 >> 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: >>=20 >> (defun my/report-mouse (ev) >> (interactive "e") >> (let* ((posn (event-start ev)) >> (rel (posn-object-x-y posn))) >> (message "Got Relative Position %S" rel))) >>=20 >> (insert "\n\n ---- " >> (propertize " " >> 'extend nil >> 'display '(space :width (48)) >> 'keymap '(keymap (down-mouse-1 . my/report-mouse)) >> 'font-lock-face 'underline) >> " ---- ") >>=20 >> 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 =E2=80=9Cpixel=E2=80=9D size)? >=20 > 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. >=20 > So bottom line, you shouldn't expect DX and DY offsets in click = position > data to be meaningful in this case. --Apple-Mail=_70D52D62-0F72-4824-805B-A8F808409111 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks.  The documentation on = posn-object-* provides no guidance that a =E2=80=9Cstring object=E2=80=9D = 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=E2=80=9D 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 =3D 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 " "
=             &n= bsp;      'extend nil
=             &n= bsp;      'display '(space :width (48))
=             &n= bsp;      'keymap '(keymap (down-mouse-1 . = my/report-mouse))
=             &n= bsp;      '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 = =E2=80=9Cpixel=E2=80=9D 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.

= --Apple-Mail=_70D52D62-0F72-4824-805B-A8F808409111--