From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs Subject: bug#28620: bug#28621: Proposed patch for doc of posn-window and code of posn-set-point to handle frame arguments Date: Sat, 30 Sep 2017 17:56:47 -0400 Message-ID: References: <83k20h5m2x.fsf@gnu.org> <59CF56AF.3090008@gmx.at> <59CFD083.40407@gmx.at> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045ee8569d99d7055a6f3978" X-Trace: blaine.gmane.org 1506808692 1920 195.159.176.226 (30 Sep 2017 21:58:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Sep 2017 21:58:12 +0000 (UTC) Cc: 28620@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 30 23:58:06 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyPlt-0008Lx-9H for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Sep 2017 23:58:05 +0200 Original-Received: from localhost ([::1]:40478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyPm0-0002HP-MT for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Sep 2017 17:58:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyPlu-0002HJ-10 for bug-gnu-emacs@gnu.org; Sat, 30 Sep 2017 17:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dyPlq-0002Nx-TN for bug-gnu-emacs@gnu.org; Sat, 30 Sep 2017 17:58:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:32868) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dyPlq-0002Nn-Po for bug-gnu-emacs@gnu.org; Sat, 30 Sep 2017 17:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dyPlq-0001c6-HQ for bug-gnu-emacs@gnu.org; Sat, 30 Sep 2017 17:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Sep 2017 21:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28620-submit@debbugs.gnu.org id=B28620.15068086506150 (code B ref 28620); Sat, 30 Sep 2017 21:58:02 +0000 Original-Received: (at 28620) by debbugs.gnu.org; 30 Sep 2017 21:57:30 +0000 Original-Received: from localhost ([127.0.0.1]:41549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyPlJ-0001b7-Ln for submit@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyPlH-0001as-HC for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dyPl9-0001jO-5s for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyPl9-0001iy-14 for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:19 -0400 Original-Received: from mail-qt0-f176.google.com ([209.85.216.176]:50383) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dyPl8-0001UG-L5 for 28620@debbugs.gnu.org; Sat, 30 Sep 2017 17:57:18 -0400 Original-Received: by mail-qt0-f176.google.com with SMTP id f15so3450242qtf.7 for <28620@debbugs.gnu.org>; Sat, 30 Sep 2017 14:57:18 -0700 (PDT) X-Gm-Message-State: AMCzsaVkHyq6K6wkJHLjynTgyhwOGWKZSnsGnoXPiPO2MHe+RY1DBs/e G+ZIa0ccKe4FY0mFAXGOkOavfykjb4lbb7DH1iA= X-Google-Smtp-Source: AOwi7QDjUnSXQV+VZY527/oCnNiYlxjyGtUrjzbhEeD+x7U+h/fqdsHAX0IOYeUoCJn7ozuc8z/RlLWSlbhqpZFsXv4= X-Received: by 10.237.39.219 with SMTP id m27mr12532296qtg.34.1506808638051; Sat, 30 Sep 2017 14:57:18 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Sat, 30 Sep 2017 14:56:47 -0700 (PDT) In-Reply-To: <59CFD083.40407@gmx.at> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:137715 Archived-At: --f403045ee8569d99d7055a6f3978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 30, 2017 at 1:12 PM, martin rudalics wrote: > > This speaks to my point in my most recent prior message, "If we just ha= d > a > > way to get a window from a set of coordinates within a frame, then I > think > > this would help solve a lot of this." If the event-end of Emacs mouse > drag > > events included a window, rather than a frame, when the endpoint of the > > drag is at a position unique to a window (considering Z-frame order), I > > think that would solve all these issues and simplify parts of the posn > code. > =E2=80=8BThe issue, to recap, is that I can't find a function that will report the window that a mouse release button event occurs in if the depress and release are in different frames (for Emacs 25). In fact, the release event (drag event) contains the wrong frame (that of the depress rather than the release). The wrong frame is also reported by mouse-position and mouse-pixel-position, so window-at can't be used either. The problem seems to be documented in the Emacs event design. Frame selection events are deferred when they occur while a button is depressed to prevent some kind of state inconsistency. But as a result, the drag release event records the wrong frame and there is no way for the release binding to determine and record the right one. > Take the position of the event-end (if it's a frame) and translate it > into absolute screen coordinates (the Elisp manual should give you > enough clues to do that). Or, try =E2=80=98mouse-absolute-pixel-position= =E2=80=99 - it > should give you the screen position of the mouse at that time so you can > ignore the event completely. > > Then walk all your windows and compare that position with whatever > =E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window. I= f you have two > or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare t= he result > against those windows' frames. No hands, IMHO. =E2=80=8Bframe-list-z-order is Emacs 26 only; I need something that works w= ith older versions.=E2=80=8B Bob --f403045ee8569d99d7055a6f3978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Sep 30, 2= 017 at 1:12 PM, martin rudalics <rudalics@gmx.at> wrote:
> This speaks to m= y point in my most recent prior message, "If we just had a
> way to get a window from a set of coordinates within a frame, then I t= hink
> this would help solve a lot of this."=C2=A0 If the event-end of E= macs mouse drag
> events included a window, rather than a frame, when the endpoint of th= e
> drag is at a position unique to a window (considering Z-frame order), = I
> think that would solve all these issues and simplify parts of the posn= code.

=E2=80=8BThe issue, to recap, is t= hat I can't find a function that
will report the window that a mouse r= elease button event
occurs in if the depress and release are in different = frames
(for Emacs 25).

In fact, the release event (drag event) cont= ains the wrong
frame (that of the depress rather than the release).=C2=A0 = The wrong=C2=A0
frame is also reported by mouse-position and mouse-pixel-p= osition,
so window-at can't be used either.

The problem seems t= o be documented in the Emacs event design.
Frame selection events are defe= rred when they occur while a button
is depressed to prevent some kind of s= tate inconsistency.=C2=A0 But as
a result, the drag release event records = the wrong frame and there
is no way for the release binding to determine a= nd record the right
one.


 Take the position of the event-end (if it's a frame) and translate it into absolute screen coordinates (the Elisp manual should give you
enough clues to do that).=C2=A0 Or, try =E2=80=98mouse-absolute-pixel-posit= ion=E2=80=99 - it
should give you the screen position of the mouse at that time so you can ignore the event completely.

Then walk all your windows and compare that position with whatever
=E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window.=C2= =A0 If you have two
or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare the= result
against those windows' frames.=C2=A0 No hands, IMHO.
<= br>
=E2=80=8Bframe-list-z-order is Emacs 26 only; I need something that wo= rks with older versions.=E2=80=8B

Bob


<= /div> --f403045ee8569d99d7055a6f3978--