From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space Date: Fri, 25 Nov 2022 09:21:27 +0200 Message-ID: <83tu2nv6rs.fsf@gnu.org> References: <835yf4w6a7.fsf@gnu.org> <5BBC7E49-41C3-4693-95F6-26E8EAC7F7A4@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25141"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: JD Smith Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 25 08:21:46 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 1oyT1t-0006LY-7g for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Nov 2022 08:21:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oyT1L-0007Xa-Lj; Fri, 25 Nov 2022 02:21:11 -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 1oyT1I-0007Wd-7V for emacs-devel@gnu.org; Fri, 25 Nov 2022 02:21:08 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyT1H-0005Ik-UA; Fri, 25 Nov 2022 02:21:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=xNII0HmO5FYo9zaWblJLGbzpxroLoGYDXRA0u4aC8bc=; b=CEx19M+M1WWlSwyCg563 lh5SswSbiIGKnrFtbyfe/cHFNSEzGHnFDsTwnd5KBarKixztumaM8Nz426lWWKCc5ll3yNbxvxF3J 3AG0366X/oeKIbTKJr2GozlZ7HiImcOoS7gw0gv5Wa+2LUj9dZCDFh56hrb1x8kujbrO35wvfBiHC tA8RHt3FbId7kkFsektGMf/IhtmhgqHZmNjDQ3rSopMJZ+DedtGhYiH+RWBIvCn0O35N8oI5jqaPD pCN/FdLl9IeSqMlyOepVFsKnLphUJjUJ60ubym4cf64vOiUfQOAXliv4LITAUwYgT0vW0Pbo+4xcW A+E6cQC0tJzrzQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyT1F-0002Fa-Qx; Fri, 25 Nov 2022 02:21:06 -0500 In-Reply-To: <5BBC7E49-41C3-4693-95F6-26E8EAC7F7A4@gmail.com> (message from JD Smith on Thu, 24 Nov 2022 16:42:29 -0500) 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:300465 Archived-At: > From: JD Smith > Date: Thu, 24 Nov 2022 16:42:29 -0500 > Cc: emacs-devel@gnu.org > > 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! Yes, but on TTY frames the DX/DY _within_ the character glyph are always zero, because each character is considered to be exactly one "pixel". And if I tell you that stretches of whitespace produced by 'space' display specs are implemented on TTY as sequences of SPC characters (of course, what else?), then I think you will understand why the DX/DY values, defined in the ELisp manual as "the coordinates relative to the top left corner of the character glyph clicked on", on a TTY are always zero: wherever the click is, it is always on a glyph of some SPC character from those that represent the stretch of whitespace. > 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. On TTY, you will always get zero DX/DY, so if this is deemed "unreliable", then yes, you should not use that for your needs, whatever those are. > 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.). Please tell more about your use case. I don't think I understand what you mean by "string displayed with specified space"; AFAIU there were no display or overlay strings in the recipe you posted, and no description of what you are trying to do with the 'space' spec that the DX/DY offsets are so important. If I have to guess what you want, then my suggestion would be to use something like this: (let* ((event-posn (posn-point (event-start ev))) (click-x-y (posn-x-y (event-start ev))) (obj-x-y (posn-x-y (posn-at-point event-posn)))) (cons (- (car click-x-y) (car obj-x-y)) (- (cdr click-x-y) (cdr obj-x-y)))) IOW, don't trust DX/DY, but calculate the offsets "by hand". But that's a guess.