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

Previous Next

Package: emacs;

Reported by: rswgnu <at> gmail.com

Date: Wed, 27 Sep 2017 16:03:02 UTC

Severity: minor

Tags: fixed, patch

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28621 in the body.
You can then email your comments to 28621 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Wed, 27 Sep 2017 16:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to rswgnu <at> gmail.com:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 27 Sep 2017 16:03:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Robert Weiner <rsw <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Proposed patch for doc of posn-window and code of posn-set-point to
 handle frame arguments
Date: Wed, 27 Sep 2017 12:01:50 -0400
[Message part 1 (text/plain, inline)]
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.  Read the code of posn-set-point to ensure
the logic is right in terms of using frame-selected-window.

This diff is against subr.el in Emacs 25.3 but I see none of this has yet
changed in Emacs 26 either, so it is still applicable.

*** subr.el.gz 2017-09-27 11:50:06.000000000 -0400
--- subr-new.el.gz 2017-09-27 11:50:06.000000000 -0400
***************
*** 1090,1096 ****
  The following accessor functions are used to access the elements
  of the position:

! `posn-window': The window the event is in.
  `posn-area': A symbol identifying the area the event occurred in,
  or nil if the event occurred in the text area.
  `posn-point': The buffer position of the event.
--- 1090,1096 ----
  The following accessor functions are used to access the elements
  of the position:

! `posn-window': The window or frame of the event end.
  `posn-area': A symbol identifying the area the event occurred in,
  or nil if the event occurred in the text area.
  `posn-point': The buffer position of the event.
***************
*** 1141,1148 ****

  (defsubst posn-window (position)
    "Return the window in POSITION.
! POSITION should be a list of the form returned by the `event-start'
! and `event-end' functions."
    (nth 0 position))

  (defsubst posn-area (position)
--- 1141,1149 ----

  (defsubst posn-window (position)
    "Return the window in POSITION.
! If POSITION is outside the frame where the event was initiated, return
! that frame instead.  POSITION should be a list of the form returned by
! the `event-start' and `event-end' functions."
    (nth 0 position))

  (defsubst posn-area (position)
***************
*** 1169,1177 ****
  (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))))
!     (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))))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Wed, 27 Sep 2017 21:35:01 GMT) Full text and rfc822 format available.

Message #8 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <jwiegley <at> gmail.com>
To: Robert Weiner <rsw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, rswgnu <at> gmail.com, 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Wed, 27 Sep 2017 14:34:21 -0700
>>>>> "RW" == Robert Weiner <rsw <at> gnu.org> writes:

RW> The doc for posn-window is incomplete. posn-set-point does not handle drag
RW> events whose end point argument is a frame, rather than a window. This
RW> patch fixes both of these. Read the code of posn-set-point to ensure the
RW> logic is right in terms of using frame-selected-window.

I'm happy to see this applied, just want confirmation from someone who
understands this code better that this is the correct clarification...

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Fri, 29 Sep 2017 08:35:01 GMT) Full text and rfc822 format available.

Message #11 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: rswgnu <at> gmail.com, 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Fri, 29 Sep 2017 10:34:44 +0200
> ! `posn-window': The window or frame of the event end.

If we start talking about "event ends" here we should export that
concept to the remaining ‘posn-*’ functions as well.

> ! If POSITION is outside the frame where the event was initiated, return
> ! that frame instead.  POSITION should be a list of the form returned by

I suppose this is not sufficient: We get a frame also when the mouse is
on its tool or menu bar, some of ist borders ...

But note that I've never been able to understand the purpose of these
‘posn-*’ functions and they usually confuse the hell out of me.  IMHO it
would make much more sense to declare them obsolete and concentrate on
describing event structures better.

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Fri, 29 Sep 2017 16:50:02 GMT) Full text and rfc822 format available.

Message #14 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Robert Weiner <rsw <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Fri, 29 Sep 2017 12:48:22 -0400
[Message part 1 (text/plain, inline)]
On Fri, Sep 29, 2017 at 4:34 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> > ! `posn-window': The window or frame of the event end.
>
> If we start talking about "event ends" here we should export that
> ​​
> concept to the remaining ‘posn-*’ functions as well.
> ​​
>

​Yes.

> ​​
> ​​
>
> ​​
> > ! If POSITION is outside the frame where the event was initiated, return
> ​​
> > ! that frame instead.  POSITION should be a list of the form returned by
> ​​
>
> ​​
> I suppose this is not sufficient: We get a frame also when the mouse is
> ​​
> on its tool or menu bar, some of ist borders ...
>

​posn-area reports whether the event was in the text area or not.​

​​
>
> ​​
> But note that I've never been able to understand the purpose of these
> ​​
> ‘posn-*’ functions and they usually confuse the hell out of me.  IMHO it
> ​​
> would make much more sense to declare them obsolete and concentrate on
> ​​
> describing event structures better.


​It does seem like some additional work is needed to simplify event
handling and handle a multi-frame world better.

Bob

​​
​​
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Fri, 29 Sep 2017 19:43:02 GMT) Full text and rfc822 format available.

Message #17 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rswgnu <at> gmail.com
Cc: 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Fri, 29 Sep 2017 22:41:42 +0300
> From: Robert Weiner <rsw <at> 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.  Read the code of posn-set-point to ensure
> the logic is right in terms of using frame-selected-window.
> 
> This diff is against subr.el in Emacs 25.3 but I see none of this has yet
> changed in Emacs 26 either, so it is still applicable.

Thanks.  Some comments below.

> ! `posn-window': The window the event is in.
>   `posn-area': A symbol identifying the area the event occurred in,
>   or nil if the event occurred in the text area.
>   `posn-point': The buffer position of the event.
> --- 1090,1096 ----
>   The following accessor functions are used to access the elements
>   of the position:
> 
> ! `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.

>   (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?
Can you describe a use case where this would be a useful behavior?

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'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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Fri, 29 Sep 2017 19:44:02 GMT) Full text and rfc822 format available.

Message #20 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: rswgnu <at> gmail.com, 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Fri, 29 Sep 2017 22:42:46 +0300
> Date: Fri, 29 Sep 2017 10:34:44 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > ! `posn-window': The window or frame of the event end.
> 
> If we start talking about "event ends" here we should export that
> concept to the remaining ‘posn-*’ functions as well.

Agreed.

>  > ! If POSITION is outside the frame where the event was initiated, return
>  > ! that frame instead.  POSITION should be a list of the form returned by
> 
> I suppose this is not sufficient: We get a frame also when the mouse is
> on its tool or menu bar, some of ist borders ...

Right.  Btw, the manual has this problem as well.

> But note that I've never been able to understand the purpose of these
> ‘posn-*’ functions and they usually confuse the hell out of me.  IMHO it
> would make much more sense to declare them obsolete and concentrate on
> describing event structures better.

We should do both, IMO.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Fri, 29 Sep 2017 20:13:02 GMT) Full text and rfc822 format available.

Message #23 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Robert Weiner <rsw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28621 <at> debbugs.gnu.org
Subject: Re: 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
[Message part 1 (text/plain, inline)]
On Fri, Sep 29, 2017 at 3:41 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Robert Weiner <rsw <at> 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
​
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Sat, 30 Sep 2017 08:33:02 GMT) Full text and rfc822 format available.

Message #26 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: rswgnu <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Cc: 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Sat, 30 Sep 2017 10:32:47 +0200
>>> !      (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.

(frame-selected-window (posn-window position)) might not be the window
under the mouse cursor.

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Sat, 30 Sep 2017 12:47:01 GMT) Full text and rfc822 format available.

Message #29 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Robert Weiner <rsw <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Sat, 30 Sep 2017 08:45:53 -0400
[Message part 1 (text/plain, inline)]
On Sat, Sep 30, 2017 at 4:32 AM, martin rudalics <rudalics <at> gmx.at> wrot

>
> (frame-selected-window (posn-window position)) might not be the window
> under the mouse cursor.


​You are correct.  Though in testing 5 different mouse key bindings it was
correct 4 out of 5 times because the depress part of the cross-frame drag
event selected the window of the depress which is probably more accurate
than existing results.  I agree though that there may be uses of drag
events where one does not want to select the window of the depress.

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.

Bob
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Sat, 30 Sep 2017 12:53:02 GMT) Full text and rfc822 format available.

Message #32 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Robert Weiner <rsw <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Sat, 30 Sep 2017 08:52:05 -0400
[Message part 1 (text/plain, inline)]
On Sat, Sep 30, 2017 at 8:45 AM, Robert Weiner <rsw <at> gnu.org> wrote:

> On Sat, Sep 30, 2017 at 4:32 AM, martin rudalics <rudalics <at> gmx.at> wrot
>
>>
>> (frame-selected-window (posn-window position)) might not be the window
>> under the mouse cursor.
>
>
> ​You are correct.  Though in testing 5 different mouse key bindings it was
> correct 4 out of 5 times because the depress part of the cross-frame drag
> event selected the window of the depress which is probably more accurate
> than existing results.  I agree though that there may be uses of drag
> events where one does not want to select the window of the depress.
>

​Please ignore the above paragraph as I wasn't thinking about the end part
of the drag.
​

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

​Just read the above paragragph.

Bob
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Sat, 30 Sep 2017 17:13:01 GMT) Full text and rfc822 format available.

Message #35 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: rswgnu <at> gmail.com
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Sat, 30 Sep 2017 19:12:35 +0200
> 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.

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.

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Mon, 24 Jun 2019 16:09:05 GMT) Full text and rfc822 format available.

Message #38 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Weiner <rsw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, rswgnu <at> gmail.com, 28621 <at> debbugs.gnu.org
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Mon, 24 Jun 2019 18:08:11 +0200
Robert Weiner <rsw <at> gnu.org> writes:

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

As far as I can tell, none of the posn-* doc strings were changed, even
though everybody seemed to agree that they should be.  Robert, did you
continue working on this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Thu, 27 Jun 2019 02:22:01 GMT) Full text and rfc822 format available.

Message #41 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Robert Weiner <rswgnu <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org,
 Robert Weiner <rsw <at> gnu.org>
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Wed, 26 Jun 2019 22:20:59 -0400
I think all my changes are in the first message here.  Lars, can you see about integrating from there?  Thanks.

-- Bob

> On Jun 24, 2019, at 12:08 PM, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> 
> Robert Weiner <rsw <at> gnu.org> writes:
> 
>> ​​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.
> 
> As far as I can tell, none of the posn-* doc strings were changed, even
> though everybody seemed to agree that they should be.  Robert, did you
> continue working on this?
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Thu, 27 Jun 2019 10:40:02 GMT) Full text and rfc822 format available.

Message #44 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Weiner <rswgnu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org,
 Robert Weiner <rsw <at> gnu.org>
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Thu, 27 Jun 2019 12:39:40 +0200
Robert Weiner <rswgnu <at> gmail.com> writes:

> I think all my changes are in the first message here.  Lars, can you
> see about integrating from there?  Thanks.

If I understood the thread correctly, there was some worry that the
changes weren't completely correct in the presence of various frame
configurations?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Thu, 27 Jun 2019 12:28:01 GMT) Full text and rfc822 format available.

Message #47 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Robert Weiner <rswgnu <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org,
 Robert Weiner <rsw <at> gnu.org>
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Thu, 27 Jun 2019 08:27:49 -0400
[Message part 1 (text/plain, inline)]
> On Jun 26, 2019, at 10:20 PM, Robert Weiner <rswgnu <at> gmail.com> wrote:
> 
> I think all my changes are in the first message here.  Lars, can you see about integrating from there?  Thanks.
> 

Plus, this message now that I have re-read the thread.  I think the main issue was just documenting the changes in NEWS, Changes, the manuals, etc.  I have been using these patches for all this time now with Hyperbole’s cross-frame drags on multiple platforms under Emacs 26 without incident.  It would be great to see this moved forward.  — Bob

Robert Weiner <rsw <at> gnu.org> writes:

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

Show Quoted Content
> 
> ​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 following is a temporary fix for the mouse-position and
mouse-pixel-position part of the problem.  Something needs to be fixed
in the original functions in the C code, though.  -- 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.
;;  The problem occurs on other systems as well, e.g. Emacs 25.2 under Windows 7.
;;  The function below is a temporary fix for this.
(setq mouse-position-function
     (lambda (frame-x-dot-y)
   "Under macOS, mouse-position and mouse-pixel-position sometimes fail to return the selected-frame (returning the prior frame instead); fix that here."
   (setcar frame-x-dot-y (selected-frame))
   frame-x-dot-y))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Mon, 24 Aug 2020 13:29:01 GMT) Full text and rfc822 format available.

Message #50 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Weiner <rswgnu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org,
 Robert Weiner <rsw <at> gnu.org>
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Mon, 24 Aug 2020 15:28:07 +0200
Robert Weiner <rswgnu <at> gmail.com> writes:

> On Jun 26, 2019, at 10:20 PM, Robert Weiner <rswgnu <at> gmail.com> wrote:
>
>  I think all my changes are in the first message here.  Lars, can you see about
>  integrating from there?  Thanks.
>
> Plus, this message now that I have re-read the thread.  I think the
> main issue was just documenting the changes in NEWS, Changes, the
> manuals, etc.  I have been using these patches for all this time now
> with Hyperbole’s cross-frame drags on multiple platforms under Emacs
> 26 without incident.  It would be great to see this moved forward.  —
> Bob

Can you respin the patch, including the changes to the manuals etc?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Mon, 24 Aug 2020 13:30:02 GMT) Full text and rfc822 format available.

Message #53 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Weiner <rswgnu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org,
 Robert Weiner <rsw <at> gnu.org>
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Mon, 24 Aug 2020 15:29:13 +0200
(This is the patch itself -- it didn't apply because it was posted as
HTML.)

diff --git a/lisp/subr.el b/lisp/subr.el
index a58a873a33..12d7383600 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -1364,7 +1364,7 @@ event-start
 The following accessor functions are used to access the elements
 of the position:
 
-`posn-window': The window the event is in.
+`posn-window': The window or frame of the event end.
 `posn-area': A symbol identifying the area the event occurred in,
 or nil if the event occurred in the text area.
 `posn-point': The buffer position of the event.
@@ -1420,8 +1420,9 @@ posnp
 
 (defsubst posn-window (position)
   "Return the window in POSITION.
-POSITION should be a list of the form returned by the `event-start'
-and `event-end' functions."
+If POSITION is outside the frame where the event was initiated,
+return that frame instead.  POSITION should be a list of the form
+returned by the `event-start' and `event-end' functions."
   (nth 0 position))
 
 (defsubst posn-area (position)
@@ -1448,9 +1449,14 @@ posn-point
 (defun posn-set-point (position)
   "Move point to POSITION.
 Select the corresponding window as well."
-  (if (not (windowp (posn-window position)))
+  (if (framep (posn-window position))
+      (progn
+        (unless (windowp (frame-selected-window (posn-window position)))
+          (error "Position not in text area of window"))
+        (select-window (frame-selected-window (posn-window position))))
+    (unless (windowp (posn-window position))
       (error "Position not in text area of window"))
-  (select-window (posn-window position))
+    (select-window (posn-window position)))
   (if (numberp (posn-point position))
       (goto-char (posn-point position))))
 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





Added tag(s) patch. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 24 Aug 2020 13:30:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28621; Package emacs. (Sun, 11 Oct 2020 02:07:02 GMT) Full text and rfc822 format available.

Message #58 received at 28621 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Weiner <rswgnu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 28621 <at> debbugs.gnu.org,
 Robert Weiner <rsw <at> gnu.org>
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
Date: Sun, 11 Oct 2020 04:06:07 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> (This is the patch itself -- it didn't apply because it was posted as
> HTML.)

I've now applied this with the changes suggested by Eli, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 11 Oct 2020 02:07:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.1, send any further explanations to 28621 <at> debbugs.gnu.org and rswgnu <at> gmail.com Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 11 Oct 2020 02:07:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 08 Nov 2020 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 141 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.