bug#28621: Proposed patch for doc of posn-window and code of posn-set-point to handle frame arguments

[Robert Weiner]

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

​