Re: Emacs 26: Code that fixes mouse-drag-and-drop-region to work across frames

[Robert Weiner]

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 <address@hidden> wrote:

On Wed, Nov 01, 2017 at 11:24:44AM -0400, Robert Weiner wrot

​​

e:
> ​Maybe it would be best if someone fixed the XSETFRAME mac

​​

ro in
> ​mouse-position so it works properly under the macOS window s

​​

ystem so we
> could avoid any work arounds on this.  -- Bob

​​

>

​​

>

​​

From mouse-position:
>

​​

     ;;    f = SELECTED_FRAME ();
>

​​

     ;;    XSETFRAME (lispy_dummy, f);
>

​​

     ;;  It seems like the XSETFRAME macro is not properly copying the value
>

​​

of f on initial frame selection under the macOS window system.

​​

​​

That’s not the problem. I’ve explained this to you before.

​​

​​Just 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?

​​

​​

ns_mouse_position uses dpyinfo->last_mouse_frame, which is set in

​​

mouseDown. MouseDown is *not called* on macOS for the first click,

​​

instead the frame is selected.

​​

​​

This means, like other macOS applications, the first click in the

​​

window JUST selects that window, it has no other effect.

​So 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?​

​​

​​

​​

The docstring for mouse-position says:

​​

​​

    Return a list (FRAME X . Y) giving the current mouse frame and

​​

    position.

​​

​​

To my way of reading that, ‘current mouse frame’ != ‘current selected

​​

frame’, it will be the last frame that a mouse action of some sort was

​​

registered in.

​I 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.​

So what triggers dpyinfo->last_mouse_frame to change?

Another mouse event?  Why not a select-frame event?

​​

​​

On macOS that doesn’t include the first click in the frame as it’s not

​​

registered as an input by Emacs.

​But 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?

​

​​

​​

Is this behaviour wrong? I don’t know, but it seems to match the

​​

documentation.

​We 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.

​​

 

​​

​​

I’m sure Martin suggested this before, but if you’re trying to

​​

implement cross‐frame/window dragging, would it not be better to try

​​

and use the standard implementation for each platform?

​Most of my interest is in dragging between Emacs frames, with a little

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

​​

​​

​​

​​