From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akib Azmain Turja Newsgroups: gmane.emacs.devel Subject: Re: xterm-mouse-mode gives incorrect posn-object-x-y with display space Date: Sun, 27 Nov 2022 00:56:06 +0600 Message-ID: <87fse5pmt5.fsf@disroot.org> References: <835yf4w6a7.fsf@gnu.org> <5BBC7E49-41C3-4693-95F6-26E8EAC7F7A4@gmail.com> <837czhudev.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3980"; mail-complaints-to="usenet@ciao.gmane.io" Cc: JD Smith , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 26 19:59:48 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 1oz0Ov-0000if-08 for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Nov 2022 19:59:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oz0Oj-0004aV-Ck; Sat, 26 Nov 2022 13:59:33 -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 1oz0Of-0004ZS-VP for emacs-devel@gnu.org; Sat, 26 Nov 2022 13:59:31 -0500 Original-Received: from knopi.disroot.org ([178.21.23.139]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oz0Oe-0001N6-0H; Sat, 26 Nov 2022 13:59:29 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id A14BB4112B; Sat, 26 Nov 2022 19:59:26 +0100 (CET) X-Virus-Scanned: SPAM Filter at disroot.org Original-Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdz_-hOscFU9; Sat, 26 Nov 2022 19:59:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1669489163; bh=mpMPIK+MclozzdMBDBhu92yg7MB5LUA0pUxGj3Fqie0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cskSlnDrEtMtdT68Bkmpal1fjG1CLx+7JC7YE94Zd3jOZqs6sA+a79isx0eibQqA5 gSHG05fMbpHeeP1hyNcBTxs5BkoOPece7Od9vAVfq4z6WwdO/WonhS4IwJDfvSvamV NM+cjL1ZwFnCtFdEkO11+hr6HJvwnss8R9ixwdIbFKwynhLz4tWLPtwsR/4kavwS4z AHCdOi6RC7BM0mp+Gs/18uUVxrm4/6/aIyJGUz+VJTZgt9t2mRqY5MRaU67tf0XhER 50zlLJFAceX5QaCSP1Mur/KqUD80QVjz3C5ffVWN6J35TaGV2Ac/OR9BfZ0P+pJ0xn kfu3ibMIfzzeQ== In-Reply-To: <837czhudev.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Nov 2022 14:07:52 +0200") Received-SPF: pass client-ip=178.21.23.139; envelope-from=akib@disroot.org; helo=knopi.disroot.org 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, 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:300581 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: JD Smith >> Date: Thu, 24 Nov 2022 16:42:29 -0500 >> Cc: emacs-devel@gnu.org >>=20 >> 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 spa= ce), posn-object-x-y works perfectly >> well on normal width characters in the buffer, providing pixel level inf= ormation 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". Surel= y that is not an accident of the >> implementation! > > posn-object-x-y for a display/overlay string measure from the nearest gly= ph > of the string character, not from the beginning of the string. > >> > Yes, but on TTY frames the DX/DY _within_ the character glyph are alwa= ys >> > 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 o= f the >> > character glyph clicked on", on a TTY are always zero: wherever the cl= ick >> > is, it is always on a glyph of some SPC character from those that repr= esent >> > the stretch of whitespace. >>=20 >> Thanks for these details. This I had indeed understood; with char >> units, you can=E2=80=99t and won't get any pixel offsets within a single >> char glyph. Since for the TTY, Emacs implements a specified space >> under the hood as a =E2=80=9Cseries of spaces=E2=80=9D, the natural thin= g for >> consistency with the GUI would be for posn-object-x-y to report >> click position offsets (in integer character units, naturally) >> within that stretched space. It sounds like this may be challenging >> to implement internally, but it would be the most consistent. It >> must be possible, since Emacs 1) knows it drew a specified space as >> a series of space chars in the TTY, and 2) knows (or could know) >> where the click occurred within that group of space chars it drew. > > The problem is that the "knowledge" about stretch implementation is on a > much lower level than the one on which posn-object-x-y operates. On the > level of posn-object-x-y there's no stretch, just the position and the > metrics of the glyphs it produced. > >> To summarize, the fact that in the TTY a stretched space is >> implemented as a collection of space chars, and on GUI, some other >> type of pixel-precise graphical element is IMO just an >> implementation detail. What if TTY=E2=80=99s of the future allow drawing >> small graphical elements at pixel precision? How is the user of >> posn-object-* to know which of the two different and incompatible >> result flavors they will get? > > If that ever happens, "Someone" will have a lot of work on their hands. > >> This is how I implement mlscroll, a mode line scroll bar we=E2=80=99ve >> discussed here before. The basic design is 3 specified spaces in a >> row , usually right-aligned in the mode line. Together these 3 >> (varying width) spaces indicate the number of lines: i) above ii) >> showing, and iii) after the window. Just like a =E2=80=9Creal=E2=80=9D = scrollbar, >> the user can interact with it by clicking/dragging/etc. When >> clicking on the bar, the precise relative click position determines >> what lines are scrolled into view (again, just like a real >> scrollbar). Surprisingly it looks pretty good on TTY without any >> special casing, though obviously with char- instead of >> pixel-granularity. But this happy consistency breaks down with >> xterm-mouse-mode, since clicks on the modeline scrollbar are not >> reportable as positions w.r.t. the clicked element, i.e. since >> posn-object-x-y always reports 0 on TTY. > > I don't understand what you mean by "surprisingly it looks pretty good on > TTY without any special casing", if mouse clicks on TTY frames give you t= his > problem. Are you saying that you only see this with xterm-mouse-mode, but > not with some other mouse which works with Emacs TTY frames? > >> > (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)))) >> >=20 >> > IOW, don't trust DX/DY, but calculate the offsets "by hand". >>=20 >>=20 >> Thanks for your good suggestion; this would indeed work as desired >> in the buffer, since posn-at-point does seem to =E2=80=9Cknow=E2=80=9D i= t=E2=80=99s in a >> specified space in both GUI and TTY (which makes me think >> posn-object-x-y should also be able to know this). >>=20 >> Unfortunately posn-point returns nil for posn-area =3D mode-line, so >> this does not solve the problem. Is there any other way you know to >> determine the starting char position of the _group of spaces_ that >> TTY Emacs translates a specified space into, in the mode line? >> Calculating the char-start of the scrollbar myself will be >> challenging given dynamic modeline elements and the possibility for >> the user to place the scrollbar anywhere they want (i.e. not just >> right-aligned). > > Why challenging? On TTY frames, align-to always aligns to some character > position, and the mouse clicks are reported in terms of character positio= ns > as well. Why do you even need the fine details of the POSITION part of t= he > mouse-click events on TTY frames? > They (probably a grammatical mistake) are the maintainer of the mlscroll package, that implement scroll bar in mode line, but using specified space. That's why they need the click position *precisely*. =2D-=20 Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyVTKmrtL6kNBe3FRVTX89U2IYWsFAmOCYUYACgkQVTX89U2I YWu9nBAAgFtORBY8oQihUjMfWknJBWCj7ZPhAMhrfnbGhWu/lYrzNMB6jZL+VEhg xKIk5ORf5e6YkmUiyQ9tLafzwEy2AvVSKn8TsHH3Ibcvut3yIzdpHsulmiqijq8T rXpQ69l9YNZJUIg/EdjLTIejwk3x72x1J682/AxQrQxwervNTn/XpZrMn0NoaZUL JNRtuAIiG7PDsD+9bGdgtemSaizAofYYiKqPf9ZlaWqsBDVztDQwEbPm8ZDSOO7I +9phZ3aJtBkxjkoE2D5Od/a6YqBnqeHcrfduoYCtw4HV29aKCq6vKW17GMU+DErh 3EFdYPI+PnJoWAUthbFXLVc0orVluKwv76vv0haSWL4sRbW4Ejyd2PJCOk2wh68e 5AfUW0wCwdxMJCuF1/ftsRNmB3S0k6rF4vnDkl8nwzMFw3B37ENCMjz6fTw1H7cI +Zxosu8l64T3qpQmPlNzGf9VLM7CGuvcdh9cneqq0j4RApSX2kJUHpsDnYHN5L5k +3Eekub7wEqSYa6A0PLzBU+UoYcl03WinPNnB67pIUz9VBZnHo5JDzK590A4rMvF 18BOCiDVhIvSgPzuPBnKuz/m9zMgdSmBpw8yVH5scLHITBETCtYHe/etPZfRWT1w Noi/rcOU0Th90811zVUWtZf/FertyNPDYu4oDwRI62EULyy1EBQ= =MsKs -----END PGP SIGNATURE----- --=-=-=--