On Sat, Sep 30, 2017 at 1:12 PM, martin rudalics <rudalics@gmx.at> wrote:

> > This speaks to my 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
> 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.
>

​The 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 ‘mouse-absolute-pixel-position’ - 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
> ‘window-absolute-pixel-edges’ returns for that window.  If you have two
> or more positives, run ‘frame-list-z-order’ and compare the result
> against those windows' frames.  No hands, IMHO.


​frame-list-z-order is Emacs 26 only; I need something that works with
older versions.​

Bob