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: Emacs 26: Code that fixes mouse-drag-and-drop-region to work across frames Date: Wed, 1 Nov 2017 16:18:40 -0400 Message-ID: References: <86d15rjrpe.fsf@misasa.okayama-u.ac.jp> <86tvywotlz.fsf@misasa.okayama-u.ac.jp> <861sli69gj.fsf@misasa.okayama-u.ac.jp> <20171101171658.GB78963@breton.holly.idiocy.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113e2052a69f6f055cf19519" X-Trace: blaine.gmane.org 1509567600 22918 195.159.176.226 (1 Nov 2017 20:20:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Nov 2017 20:20:00 +0000 (UTC) Cc: Tak Kunihiro , emacs-devel To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 01 21:19:53 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 1e9zUK-0004k5-IC for ged-emacs-devel@m.gmane.org; Wed, 01 Nov 2017 21:19:48 +0100 Original-Received: from localhost ([::1]:57567 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9zUP-00012R-TF for ged-emacs-devel@m.gmane.org; Wed, 01 Nov 2017 16:19:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9zTn-00012L-Fn for emacs-devel@gnu.org; Wed, 01 Nov 2017 16:19:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9zTk-0005wu-8Z for emacs-devel@gnu.org; Wed, 01 Nov 2017 16:19:15 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9zTk-0005wk-35 for emacs-devel@gnu.org; Wed, 01 Nov 2017 16:19:12 -0400 Original-Received: from mail-qt0-f172.google.com ([209.85.216.172]:57069) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e9zTj-0006B9-ML for emacs-devel@gnu.org; Wed, 01 Nov 2017 16:19:11 -0400 Original-Received: by mail-qt0-f172.google.com with SMTP id z28so4194805qtz.13 for ; Wed, 01 Nov 2017 13:19:11 -0700 (PDT) X-Gm-Message-State: AMCzsaW534jz/NRhCwfbUC4eIVvJ3KMfyg3ZlMEYqYg2rMcSdc/F5Agk ZsIOBXssgQ0cs7JbrlPByH6ATIBPfxMzW2BgfNU= X-Google-Smtp-Source: ABhQp+SUiycqOE0yt+R8k8T5d25zbuTElAMq0B+pEJqkoKMf5L484Wc+3wTQwzQC2Qz+yf6PmFNB0dUSOrMAqQtNhLg= X-Received: by 10.200.56.52 with SMTP id q49mr1734909qtb.309.1509567551150; Wed, 01 Nov 2017 13:19:11 -0700 (PDT) Original-Received: by 10.200.12.74 with HTTP; Wed, 1 Nov 2017 13:18:40 -0700 (PDT) In-Reply-To: <20171101171658.GB78963@breton.holly.idiocy.org> 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:219856 Archived-At: --001a113e2052a69f6f055cf19519 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alan: I always appreciate your detailed knowledge here but something needs to change with the frame handling code. Through Lisp changes most of which are independent of the window system, I have made cross-frame drags work in a natural and useful manner, similar to how clicking on a window or frame works naturally now. The changes simply rely on which frame is currently selected, so they do not involve or require any changes to whether or not the window system requires a click to select a frame. But the changes are more complex than I'd like and are tied in with the elaborate mouse handling that the Hyperbole package provides. They really should be done at the C-level so that they affect all cross-frame drags and make them operate naturally. This should be part of the discussion here. On Wed, Nov 1, 2017 at 1:16 PM, Alan Third wrote: > On Wed, Nov 01, 2017 at 11:24:44AM -0400, Robert Weiner wrot > =E2=80=8B=E2=80=8B > e: > > =E2=80=8BMaybe it would be best if someone fixed the XSETFRAME mac > =E2=80=8B=E2=80=8B > ro in > > =E2=80=8Bmouse-position so it works properly under the macOS window s > =E2=80=8B=E2=80=8B > ystem so we > > could avoid any work arounds on this. -- Bob > =E2=80=8B=E2=80=8B > > > > =E2=80=8B=E2=80=8B > > > > =E2=80=8B=E2=80=8B > From mouse-position: > > > =E2=80=8B=E2=80=8B > ;; f =3D SELECTED_FRAME (); > > > =E2=80=8B=E2=80=8B > ;; XSETFRAME (lispy_dummy, f); > > > =E2=80=8B=E2=80=8B > ;; It seems like the XSETFRAME macro is not properly copying the > value > > > =E2=80=8B=E2=80=8B > of f on initial frame selection under the macOS window system. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > That=E2=80=99s not the problem. I=E2=80=99ve explained this to you before= . > =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BJust to be clear, you are saying that in the calls above,= you believe that lispy_dummy ends up with the value of f (whatever that is), not the frame prior to the selected frame, correct? =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > ns_mouse_position uses dpyinfo->last_mouse_frame, which is set in > =E2=80=8B=E2=80=8B > mouseDown. MouseDown is *not called* on macOS for the first click, > =E2=80=8B=E2=80=8B > instead the frame is selected. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > This means, like other macOS applications, the first click in the > =E2=80=8B=E2=80=8B > window JUST selects that window, it has no other effect. > =E2=80=8BSo that is what is done now but I don't believe there is any particular use case that requires it stay this way. We could trigger an update to that data structure whenever a new frame is selected, couldn't we?=E2=80=8B =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > The docstring for mouse-position says: > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Return a list (FRAME X . Y) giving the current mouse frame and > =E2=80=8B=E2=80=8B > position. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > To my way of reading that, =E2=80=98current mouse frame=E2=80=99 !=3D =E2= =80=98current selected > =E2=80=8B=E2=80=8B > frame=E2=80=99, it will be the last frame that a mouse action of some sor= t was > =E2=80=8B=E2=80=8B > registered in. > =E2=80=8BI see what you are saying but I don't see a use case. I see many use cases for having those two values be the same.=E2=80=8B So what triggers dpyinfo->last_mouse_frame to change? Another mouse event? Why not a select-frame event? =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > On macOS that doesn=E2=80=99t include the first click in the frame as it= =E2=80=99s not > =E2=80=8B=E2=80=8B > registered as an input by Emacs. > =E2=80=8BBut Emacs does receive a select-frame or a focus-in event, so that could be utilized to trigger any updates necessary. Do you agree with that? =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Is this behaviour wrong? I don=E2=80=99t know, but it seems to match the > =E2=80=8B=E2=80=8B > documentation. > =E2=80=8BWe need Emacs to do useful things. If there is no active use for this behavior and it actually prevents obvious things such as cross-frame drags from working right, then it should be changed independent of any conformance to existing documentation. Take the simple example of using a drag to swap the buffers in two Emacs windows. Presently, you can do this pretty easily in a single frame but not across frames. Why should the behavior be any different? Would users ever prefer two different behaviors; not likely, since they would just think in terms of windows and not really care about any of the mechanics. I have this working across frames and it is pretty effortless in use and quite involved in implementation because the basic functions like mouse-position do not presently allow for cross-frame drags on macOS. =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > I=E2=80=99m sure Martin suggested this before, but if you=E2=80=99re tryi= ng to > =E2=80=8B=E2=80=8B > implement cross=E2=80=90frame/window dragging, would it not be better to = try > =E2=80=8B=E2=80=8B > and use the standard implementation for each platform? > =E2=80=8BMost of my interest is in dragging between Emacs frames, with a li= ttle interest for drags outside of Emacs. I think the mechanics of internal dragging can be dealt with separately from per-platform drag-and-drop across applications. I hope this at least sparks your interest in helping to improve the core Emacs behavior here. Bob =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B --001a113e2052a69f6f055cf19519 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan:

I alway= s appreciate your detailed knowledge here but something needs
<= div class=3D"gmail_default" style=3D"">to change with the frame handling code.=C2=A0 Through Lisp changes = most of
which are independent of the window system, I = have made cross-frame
<= font face=3D"arial, helvetica, sans-serif">drags work in a natural and usef= ul manner, similar to how clicking on a window
or fram= e works naturally now.=C2=A0 The changes simply rely on which frame<= /div>
is currently selected, so they do not involve or require any = changes to
whether or not the window system requires= a click to select a frame.
=C2=A0
But the changes are more complex than I'd like and are tied in with = the
elaborate mouse handling that the Hyperbole packag= e provides.=C2=A0 They really
should be=C2=A0done at t= he C-level so that they affect all cross-frame drags and
make them=C2=A0operate naturally.=C2=A0 This should be part of the discu= ssion here.

On Wed, Nov 1, 2017 at 1:16= PM, Alan Third <alan@idiocy.o= rg> wrote:
On Wed, Nov 01, 2017 at 11:24:44AM -0= 400, Robert Weiner wrot
=E2=80=8B=E2=80=8B
e:
> =E2=80=8BMaybe it would be best if someone fixed the XSETFRAME mac=E2=80=8B=E2=80=8B
ro in
> =E2=80=8Bmouse-position so it works properly under the macOS window s<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displa= y:inline">=E2=80=8B=E2=80=8B
ystem so we
> could avoid any work arounds on this.=C2=A0 -- Bob
=E2=80=8B= =E2=80=8B

>
=E2=80=8B=E2=80=8B

>
=E2=80=8B=E2=80=8B
From mouse-position:
>
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0;;=C2=A0 =C2=A0 = f =3D SELECTED_FRAME ();
>
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0;;=C2=A0 =C2=A0 = XSETFRAME (lispy_dummy, f);
>
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0;;=C2=A0 It seem= s like the XSETFRAME macro is not properly copying the value
>
=E2=80=8B=E2=80=8B
of f on initial frame selection und= er the macOS window system.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
That=E2=80=99s not the problem. I= =E2=80=99ve explained this to you before.
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8BJust to be clear, you are saying that in the calls above= , you believe
that lispy_dummy ends up with the = value of f (whatever that is), not the
frame prior to = the selected frame, correct?

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
ns_mouse_position uses dpyinfo->last_= mouse_frame, which is set in
=E2=80=8B=E2=80=8B
mouseDown. MouseDown is *not called* on = macOS for the first click,
=E2=80=8B=E2=80=8B
instead the frame is selected.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
This means, like other macOS application= s, the first click in the
=E2=80=8B=E2=80=8B
window JUST selects that window, it has = no other effect.

=E2=80=8BSo that is what is don= e now but I don't believe there
is any particular use case that requir= es it stay this
way.=C2=A0 We could trigger an update to that data structu= re
whenever a new frame is selected, couldn't we?=E2=80=8B
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2= =80=8B=E2=80=8B
=E2=80= =8B=E2=80=8B

=E2=80=8B=E2=80=8B
The docstring for mouse-position says:
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 Return a list (FRAME X . Y= ) giving the current mouse frame and
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 position.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
To my way of reading that, =E2=80=98curr= ent mouse frame=E2=80=99 !=3D =E2=80=98current selected
=E2=80=8B=E2=80=8B
frame=E2=80=99, it will be the last fram= e that a mouse action of some sort was
=E2=80=8B=E2=80=8B
registered in.

=
=E2=80=8BI see what you are saying but I don't see a use case.
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">I see= many use cases for having those two values be the
same.=E2=80=8B

S= o what triggers dpyinfo->last_mouse_frame to change?
Another mouse even= t?=C2=A0 Why not a select-frame event?

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
On macOS that doesn=E2=80=99t include th= e first click in the frame as it=E2=80=99s not
=E2=80=8B=E2=80=8B
registered as an input by Emacs.

=E2=80=8BBut Emacs does receive a select-frame or a foc= us-in
event, so that could be utilized to trigger any updates
necessary.= =C2=A0 Do you agree with that?
=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
Is this behaviour wrong? I don=E2=80=99t= know, but it seems to match the
=E2=80=8B=E2=80=8B
documentation.

=
=E2=80=8BWe need Emacs to do useful things.=C2=A0 If there is no
active = use for this behavior and it actually prevents
obvious things such as cros= s-frame drags from working right,
then it should be changed independent = of any conformance
to existing documentation.

Take the simple examp= le of using a drag to swap the buffers
in two Emacs windows.=C2=A0 Present= ly, you can do this pretty easily
in a single frame but not across frame= s.=C2=A0 Why should the behavior
be any different?=C2=A0 Would users ever = prefer two different
behaviors; not likely, since they would just think in= terms of windows
and not really care about any of the mechanics.=C2=A0 I = have this
working across frames and it is pretty effortless in use and
qu= ite involved in implementation because the basic functions
like mouse-pos= ition do not presently allow for cross-frame drags
on macOS.
=E2=80=8B=E2=80=8B
=C2=A0
=
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
I=E2=80=99m sure Martin suggested this b= efore, but if you=E2=80=99re trying to
=E2=80=8B=E2=80=8B
implement cross=E2=80=90frame/window dra= gging, would it not be better to try
=E2=80=8B=E2=80=8B
and use the standard implementation for = each platform?

=E2=80=8BMost of my interest is i= n dragging between Emacs frames, with a little
interest for drags outside = of Emacs.=C2=A0 I think the mechanics of internal
dragging can be dealt wi= th separately from per-platform drag-and-drop
across applications.

I hope this at least sparks your in= terest in helping to improve
the core Emacs behavior here.

Bob
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8B

--001a113e2052a69f6f055cf19519--