all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Robert Weiner <rsw@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 28621@debbugs.gnu.org
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	[thread overview]
Message-ID: <CA+OMD9g+iCKCA1onkLCZ0nDpzDGMcciJXzOaddG5tBo0C2AfEw@mail.gmail.com> (raw)
In-Reply-To: <83k20h5m2x.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4044 bytes --]

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
​

[-- Attachment #2: Type: text/html, Size: 9174 bytes --]

  reply	other threads:[~2017-09-29 20:11 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27 16:01 bug#28621: Proposed patch for doc of posn-window and code of posn-set-point to handle frame arguments Robert Weiner
2017-09-27 21:34 ` John Wiegley
2017-09-29  8:34 ` martin rudalics
2017-09-29 16:48   ` Robert Weiner
2017-09-29 19:42   ` Eli Zaretskii
2017-09-29 19:41 ` Eli Zaretskii
2017-09-29 20:11   ` Robert Weiner [this message]
2017-09-30  8:32     ` martin rudalics
2017-09-30 12:45       ` Robert Weiner
2017-09-30 12:52         ` Robert Weiner
2017-09-30 17:12         ` martin rudalics
2017-09-30 21:56           ` bug#28620: " Robert Weiner
2017-09-30 23:34             ` Robert Weiner
2017-10-16 15:11             ` bug#28620: Emacs bug#28620: (PARTIAL SOLUTION) mouse-position wrong on macOS and Windows 7 after mouse-1 click Bob Weiner
2019-06-24 16:08     ` bug#28621: Proposed patch for doc of posn-window and code of posn-set-point to handle frame arguments Lars Ingebrigtsen
2019-06-27  2:20       ` Robert Weiner
2019-06-27 10:39         ` Lars Ingebrigtsen
2019-06-27 12:27         ` Robert Weiner
2020-08-24 13:28           ` Lars Ingebrigtsen
2020-08-24 13:29           ` Lars Ingebrigtsen
2020-10-11  2:06             ` Lars Ingebrigtsen
  -- strict thread matches above, loose matches on Subject: below --
2017-09-27 15:44 bug#28620: Mouse drag event records wrong window for release when crossing frames Robert Weiner
2017-10-03 20:54 ` bug#28620: (mouse-position_ wrong on macOS after mouse-1 click (Was: Interact directly on Emacs bug#28620: mouse drag event records wrong release window) Robert Weiner
2017-10-16 15:57 ` bug#28620: (PARTIAL SOLUTION) Mouse drag event records wrong window for release when crossing frames Bob Weiner
2019-07-27  9:26 ` bug#36269: bug#28620: " martin rudalics
2019-07-27 10:08   ` Eli Zaretskii
2019-07-28  7:34     ` martin rudalics
2019-07-29 23:21       ` Robert Weiner
2019-07-30  7:00         ` bug#36269: " martin rudalics
2019-08-03 11:25       ` Eli Zaretskii
2019-08-04  7:59         ` martin rudalics
2020-08-18 11:31           ` bug#28620: bug#36269: " Stefan Kangas
2020-08-18 12:15             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+OMD9g+iCKCA1onkLCZ0nDpzDGMcciJXzOaddG5tBo0C2AfEw@mail.gmail.com \
    --to=rsw@gnu.org \
    --cc=28621@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=rswgnu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.