From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: Possible Bug: Mouse drag event records wrong window for release when crossing frames Date: Wed, 27 Sep 2017 09:44:09 -0400 Message-ID: References: <59CB5D45.9070603@gmx.at> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0600bc4c29c8055a2bfe0c" X-Trace: blaine.gmane.org 1506520043 22216 195.159.176.226 (27 Sep 2017 13:47:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Sep 2017 13:47:23 +0000 (UTC) Cc: emacs-devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 27 15:47:15 2017 Return-path: Envelope-to: ged-emacs-devel@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 1dxCg9-000528-34 for ged-emacs-devel@m.gmane.org; Wed, 27 Sep 2017 15:47:09 +0200 Original-Received: from localhost ([::1]:54901 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxCgG-0002ta-Fe for ged-emacs-devel@m.gmane.org; Wed, 27 Sep 2017 09:47:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxCdr-0001d5-6S for emacs-devel@gnu.org; Wed, 27 Sep 2017 09:44:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxCdl-0003Lu-2D for emacs-devel@gnu.org; Wed, 27 Sep 2017 09:44:47 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52658) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxCdk-0003La-Tt for emacs-devel@gnu.org; Wed, 27 Sep 2017 09:44:40 -0400 Original-Received: from mail-qk0-f172.google.com ([209.85.220.172]:47769) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dxCdk-00058f-MW for emacs-devel@gnu.org; Wed, 27 Sep 2017 09:44:40 -0400 Original-Received: by mail-qk0-f172.google.com with SMTP id b82so13303190qkc.4 for ; Wed, 27 Sep 2017 06:44:40 -0700 (PDT) X-Gm-Message-State: AHPjjUjoemqMnJWQmUAmx3+NBpINX3fyQi6W5zBnwLzWIH+A2lVk6tkv 7nOfcwXr2b/mZezT0AGUR9yFzVPOXYg50dN4B4Y= X-Google-Smtp-Source: AOwi7QAgqtOW/dUzedD3mMGf9LTKSXxts4+3IGw+oMDQKmTt+8nFuGTrmYMSVIS8Tw9Vf26RvmDNgapr7D1+y/ghDuE= X-Received: by 10.55.161.85 with SMTP id k82mr2310231qke.156.1506519880050; Wed, 27 Sep 2017 06:44:40 -0700 (PDT) Original-Received: by 10.200.28.3 with HTTP; Wed, 27 Sep 2017 06:44:09 -0700 (PDT) In-Reply-To: <59CB5D45.9070603@gmx.at> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:218824 Archived-At: --94eb2c0600bc4c29c8055a2bfe0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 27, 2017 at 4:11 AM, martin rudalics wrote: > > With Emacs 25.2 under MacOS 10.12, I use a mouse key that has bindings = on > > both its depress and release states. The depress is in a frame with 2 > > windows (one showing *Buffer List* and the other showing hmouse-drv.el)= . > > The depress occurs in the *Buffer List* window. > > > > The release occurs in another frame and the release window is showing > > hui-window.el. > > Are the frames occupying separate areas on your screen or do they > intersect? =E2=80=8BThe behavior is the same either way. It is definitely a bug in Em= acs 25.2 and 25.3 as I have confirmed it on both MacOS and Windows 7 using just default mouse-1 =E2=80=8Bdrags between frames. > > > Here is the drag event generated. Element 2 shows the proper depress > > window but element 3 shows the depress frame rather than the release > > frame. And element 3 has a frame rather than a window as its first > > argument even though the Elisp manual says it should be a window. > > IIRC it's a frame when there's no suitable window at the specified > position. This is largely undocumented and has been sometimes even used > wrongly in the Emacs code base itself. =E2=80=8BYes, I found this documented in the Emacs Lisp manual, i.e. that posn-window can return a frame, but it is not documented in the code nor do all the posn-* and mouse point setting functions handle frame results from posn-window. I have some suggested fixes I will post for this but the bug we are talking about here is generated in the C event-handling code, I believe.=E2=80=8B > > > > (drag-mouse-2 (# 2905 (88 . 467) 4050744642 > nil > > 2905 (12 . 33) nil (4 . 5) (7 . 14)) (# > "/Users/bk/Dropbox/emacs/hyperbole/" 0x102f5bde8> nil (-1373 . 463) > > 4050749802)) > > The start event seems to look OK. As for the end event, an X-coordinate > of -1373 does not look reasonable. =E2=80=8BRight. Is a negative value ever valid in this context? =E2=80=8B > Please post results for dragging from > one to another window on the same frame. > =E2=80=8BThat works fine, so I'd rather not complicate things with that. Eli, could you help us debug this or at least point us to where to set a breakpoint and what internal structures to look at? My claim is that if you put 2 frames on screen (start with non-overlapping) and drag mouse-1 from the text area of one to the second, that the drag event generated upon the release of mouse-1 will contain frame1 rather than frame2 (where the release happened).=E2=80=8B The need for this is in some code that selects a buffer or file name and displays it in the window of the drag release. It works within a single frame but fails across frames due to this issue. Bob --94eb2c0600bc4c29c8055a2bfe0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 27, 2= 017 at 4:11 AM, martin rudalics <rudalics@gmx.at> wrote:
> With Emacs 25.2 = under MacOS 10.12, I use a mouse key that has bindings on
> both its depress and release states.=C2=A0 The depress is in a frame w= ith 2
> windows (one showing *Buffer List* and the other showing hmouse-drv.el= ).
> The depress occurs in the *Buffer List* window.
>
> The release occurs in another frame and the release window is showing<= br> > hui-window.el.

 Are the frames occupying separate areas on your screen or do they
intersect?

=E2=80=8BThe behavior is the same either = way.=C2=A0 It is definitely a bug in Emacs 25.2 and 25.3 as I have confirme= d it on both MacOS and Windows 7 using just default mouse-1 =E2=80=8Bdrags = between frames.

> Here is the drag event generated.=C2=A0 Element 2 shows the proper dep= ress
> window but element 3 shows the depress frame rather than the release > frame.=C2=A0 And element 3 has a frame rather than a window as its fir= st
> argument even though the Elisp manual says it should be a window.

 IIRC it's a frame when there's no suitable window at the specified<= br> position.=C2=A0 This is largely undocumented and has been sometimes even us= ed
wrongly in the Emacs code base itself.

=E2=80=8BYes,= I found this documented in the Emacs Lisp manual, i.e. that posn-window ca= n return a frame, but it is not documented in the code nor do all the posn-= * and mouse point setting functions handle frame results from posn-window.= =C2=A0 I have some suggested fixes I will post for this but the bug we are = talking about here is generated in the C event-handling code, I believe.=E2= =80=8B


> (drag-mouse-2 (#<window 90 on *Buffer List*> 2905 (88 . 467) 405= 0744642 nil
> 2905 (12 . 33) nil (4 . 5) (7 . 14)) (#<frame hmouse-drv.el
> "/Users/bk/Dropbox/emacs/hyperbole/" 0x102f5bde8> ni= l (-1373 . 463)
> 4050749802))

 The start event seems to look OK.=C2=A0 As for the end event, an X-coordina= te
of -1373 does not look reasonable.

=E2=80=8BRight.= =C2=A0 Is a negative value ever valid in this context?
=E2=80=8B
=C2=A0 Please post results for dragging from
one to another window on the same frame.

=E2=80= =8BThat works fine, so I'd rather not complicate things with that.
Eli, could you help us debug this or at least point us to where to set a= breakpoint and what internal structures to look at?

My claim is th= at if you put 2 frames on screen (start with non-overlapping) and drag mous= e-1 from the text area of one to the second, that the drag event generated = upon the release of mouse-1 will contain frame1 rather than frame2 (where t= he release happened).=E2=80=8B

The need for this is in some code tha= t selects a buffer or file name and displays it in the window of the drag r= elease.=C2=A0 It works within a single frame but fails across frames due to= this issue.

Bob

--94eb2c0600bc4c29c8055a2bfe0c--