On Fri, Sep 29, 2017 at 3:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Weiner <rsw@gnu.org>
> > Date: Wed, 27 Sep 2017 12:01:50 -0400
> >
> > The doc for posn-window is incomplete.  posn-set-point does not handle
> drag
> > events whose end point argument is a frame, rather than a window.
> > This patch fixes both of these.


> > ! `posn-window': The window or frame of the event end.
>
> I think we should say a bit more about this.  For example:
>
>  `posn-window': The window of the event end, or its frame if event
>                 end point belongs to no window.
>

​Fine.
​

>
> >   (defun posn-set-point (position)
> >     "Move point to POSITION.
> >   Select the corresponding window as well."
> > !   (if (not (windowp (posn-window position)))
> > !       (error "Position not in text area of window"))
> > !   (select-window (posn-window position))
> >     (if (numberp (posn-point position))
> >         (goto-char (posn-point position))))
> >
> > --- 1170,1182 ----
> >   (defun posn-set-point (position)
> >     "Move point to POSITION.
> >   Select the corresponding window as well."
> > !   (if (framep (posn-window position))
> > !       (progn (if (not (windowp (frame-selected-window (posn-window
> > position))))
> > ! (error "Position not in text area of window"))
> > !      (select-window (frame-selected-window (posn-window position))))
>
> Why should we select the selected-window on that frame in this case?
>

​Because when position includes a window, the window is selected (the
latter logic in this function).  So if position is in a window in another
frame, shouldn't we select the window there?  We are trying to set point
here
based on a mouse position​, so the user must have moved his focus there.  I
am
looking for input on whether the logic is right.

​​
> Can you
> ​​
> describe a use case where this would be a useful behavior?
> ​​
>
​​
​If you bind commands to both the depress and release events of a mouse
button
and then drag between windows on two separate frames, you'll often want to
do
something in the buffer at the point of the drag release​.  Since drag
events
provide only the release frame and not the release window, unless this
window
is selected, there is no way to know which window to use.  I want to use
this
to display a buffer menu item in a window of my choosing; I have this
working
already for windows within a single frame.

Maybe posn-window should be rewritten such that if the release event
contains
a frame, it actually computes the window of the release event based on the
position
(rather than just returning the frame, as it does now and leading to a
cascade
of potential conditionals).

Presently, mouse-select-window assumes that posn-window always returns a
window,
so it doesn't handle cross-frame drags either.

If we just had a way to get a window from a set of coordinates within a
window,
then I think this would help solve a lot of this (then drag events could
end with
a window rather than a frame) and the caller could determine whether the
depress
and release events are in the same frame or not, as needed.  Does such a
function
exist in Emacs 26?

​​
>
>
> In any case, the change in posn-set-point's behavior, if we agree on
> ​​
> it, should be described in NEWS.  The changes also lack a log entry.
>

​I am not an Emacs committer, mainly due to time.  My hope is that you will
take
the ideas and code and augment them as you know best how to do into
whichever
branches you feel they should go.

​​
>
> ​​
> I'm okay with installing the documentation changes in the release
> ​​
> branch, but the change in posn-set-point should be discussed first, as
> ​​
> I'm not sure we want that.  If we agree on making that change, it
> ​​
> should go to master, I think.
>

​Sure, no problem.  Let's figure out a good solution and work towards that.

Bob
​