From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <83k20h5m2x.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1137b054f7bb04055a59a320" X-Trace: blaine.gmane.org 1506715998 16391 195.159.176.226 (29 Sep 2017 20:13:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 29 Sep 2017 20:13:18 +0000 (UTC) Cc: 28621@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 29 22:13:12 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dy1em-0003UP-8B for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Sep 2017 22:13:08 +0200 Original-Received: from localhost ([::1]:36926 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dy1et-0001z0-D1 for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Sep 2017 16:13:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dy1el-0001yp-VH for bug-gnu-emacs@gnu.org; Fri, 29 Sep 2017 16:13:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dy1eg-0003We-Q1 for bug-gnu-emacs@gnu.org; Fri, 29 Sep 2017 16:13:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59230) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dy1eg-0003WX-MT for bug-gnu-emacs@gnu.org; Fri, 29 Sep 2017 16:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dy1eg-0001Yt-Ck for bug-gnu-emacs@gnu.org; Fri, 29 Sep 2017 16:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Sep 2017 20:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28621 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28621-submit@debbugs.gnu.org id=B28621.15067159475951 (code B ref 28621); Fri, 29 Sep 2017 20:13:02 +0000 Original-Received: (at 28621) by debbugs.gnu.org; 29 Sep 2017 20:12:27 +0000 Original-Received: from localhost ([127.0.0.1]:39678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dy1e7-0001Xv-El for submit@debbugs.gnu.org; Fri, 29 Sep 2017 16:12:27 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dy1e5-0001Xh-4Y for 28621@debbugs.gnu.org; Fri, 29 Sep 2017 16:12:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dy1du-0003FR-De for 28621@debbugs.gnu.org; Fri, 29 Sep 2017 16:12:20 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dy1du-0003FA-9B for 28621@debbugs.gnu.org; Fri, 29 Sep 2017 16:12:14 -0400 Original-Received: from mail-qt0-f171.google.com ([209.85.216.171]:46187) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dy1dt-0000Do-IU for 28621@debbugs.gnu.org; Fri, 29 Sep 2017 16:12:13 -0400 Original-Received: by mail-qt0-f171.google.com with SMTP id s18so1024636qta.3 for <28621@debbugs.gnu.org>; Fri, 29 Sep 2017 13:12:13 -0700 (PDT) X-Gm-Message-State: AMCzsaX39ctLyBU73B3gdROVsf4V3ELlhRDPGp76r3bGMHOGaxS6IlsA Cpk2wghgKdA/njrl5BxJqQ+tkphsdyVKIrkBHt4= X-Google-Smtp-Source: AOwi7QAKiCX4u59nVbldilQC5rRNDdaBWUl9raHqSVACLwVTXrCXg/nQ6LTUGCdatjckMkppPPjcEFtlUTevewycxBI= X-Received: by 10.200.54.3 with SMTP id m3mr8359324qtb.197.1506715933062; Fri, 29 Sep 2017 13:12:13 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Fri, 29 Sep 2017 13:11:42 -0700 (PDT) In-Reply-To: <83k20h5m2x.fsf@gnu.org> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:137644 Archived-At: --001a1137b054f7bb04055a59a320 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2017 at 3:41 PM, Eli Zaretskii wrote: > > From: Robert Weiner > > 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. > =E2=80=8BFine. =E2=80=8B > > > (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? > =E2=80=8BBecause when position includes a window, the window is selected (t= he 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=E2=80=8B, so the user must have moved his focus t= here. I am looking for input on whether the logic is right. =E2=80=8B=E2=80=8B > Can you > =E2=80=8B=E2=80=8B > describe a use case where this would be a useful behavior? > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B =E2=80=8BIf you bind commands to both the depress and release events of a m= ouse 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=E2=80=8B. Since d= rag 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? =E2=80=8B=E2=80=8B > > > In any case, the change in posn-set-point's behavior, if we agree on > =E2=80=8B=E2=80=8B > it, should be described in NEWS. The changes also lack a log entry. > =E2=80=8BI 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. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > I'm okay with installing the documentation changes in the release > =E2=80=8B=E2=80=8B > branch, but the change in posn-set-point should be discussed first, as > =E2=80=8B=E2=80=8B > I'm not sure we want that. If we agree on making that change, it > =E2=80=8B=E2=80=8B > should go to master, I think. > =E2=80=8BSure, no problem. Let's figure out a good solution and work towar= ds that. Bob =E2=80=8B --001a1137b054f7bb04055a59a320 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Sep 29, 2= 017 at 3:41 PM, Eli Zaretskii <el= iz@gnu.org> wrot= e:
> From: Robert Weiner <rsw@gnu.org>
> Date: Wed, 27 Sep 2017 12:01:50 -0400
>
> The doc for posn-window is incomplete.=C2=A0 posn-set-point does not h= andle drag
> events whose end point argument is a frame, ra= ther 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.=C2=A0 For example:

=C2=A0`posn-window': The window of the event end, or its frame if event=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 end point belongs t= o no window.

=E2=80=8BFine.
=E2=80=8B

>=C2=A0 =C2=A0(defun posn-set-point (position)
>=C2=A0 =C2=A0 =C2=A0"Move point to POSITION.
>=C2=A0 =C2=A0Select the corresponding window as well."
> !=C2=A0 =C2=A0(if (not (windowp (posn-window position)))
> !=C2=A0 =C2=A0 =C2=A0 =C2=A0(error "Position not in text area of = window"))
> !=C2=A0 =C2=A0(select-window (posn-window position))
>=C2=A0 =C2=A0 =C2=A0(if (numberp (posn-point position))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(goto-char (posn-point position)))) >
> --- 1170,1182 ----
>=C2=A0 =C2=A0(defun posn-set-point (position)
>=C2=A0 =C2=A0 =C2=A0"Move point to POSITION.
>=C2=A0 =C2=A0Select the corresponding window as well."
> !=C2=A0 =C2=A0(if (framep (posn-window position))
> !=C2=A0 =C2=A0 =C2=A0 =C2=A0(progn (if (not (windowp (frame-selected-w= indow (posn-window
> position))))
> ! (error "Position not in text area of window"))
> !=C2=A0 =C2=A0 =C2=A0 (select-window (frame-selected-window (posn-wind= ow position))))

Why should we select the selected-window on that frame in this case?

=E2=80=8BBecause when position includes a window, the = window is selected (the
latter logic in this function).=C2=A0 So if positi= on is in a window in another
frame, shouldn't we select the window the= re?=C2=A0 We are trying to set point here
based on a mouse position=E2=80= =8B, so the user must have moved his focus there.=C2=A0 I am
looking for i= nput on whether the logic is right.

=E2=80=8B=E2=80=8B
Can you
=E2=80=8B=E2=80=8B describe a use case where this would be a useful behavior?
=E2= =80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8BIf you bi= nd 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=E2=80= =8B.=C2=A0 Since drag events
provide only the release frame and not the re= lease window, unless this window
is selected, there is no way to know whic= h window to use.=C2=A0 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 th= e release event contains
a frame, it actually computes the window of the r= elease 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 ju= st had a way to get a window from a set of coordinates within a window,
th= en 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.=C2= =A0 Does such a function
exist in Emacs 26?

=E2=80=8B=E2=80=8B


In any case, the c= hange in posn-set-point's behavior, if we agree on
=E2=80=8B=E2=80=8B
it, should be described in NEWS.=C2=A0 T= he changes also lack a log entry.

=E2=80=8BI am = not an Emacs committer, mainly due to time.=C2=A0 My hope is that you will = take
the ideas and code and augment them as you know best how to do into w= hichever
branches you feel they should go.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
I'm okay with installing the documen= tation changes in the release
=E2=80=8B=E2=80=8B
branch, but the change in posn-set-point= should be discussed first, as
=E2=80=8B=E2=80=8B
I'm not sure we want that.=C2=A0 If = we agree on making that change, it
=E2=80=8B=E2=80=8B
should go to master, I think.

=E2=80=8BSure, no problem.=C2=A0 Let's figure out a go= od solution and work towards that.

Bob
=E2=80=8B

--001a1137b054f7bb04055a59a320--