bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28621: Proposed patch for doc of posn-window and code of posn-set-po


From: Robert Weiner
Subject: bug#28621: Proposed patch for doc of posn-window and code of posn-set-point to handle frame arguments
Date: Fri, 29 Sep 2017 16:11:42 -0400

On Fri, Sep 29, 2017 at 3:41 PM, Eli Zaretskii <address@hidden> wrote:
> From: Robert Weiner <address@hidden>
> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]