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

Previous Next

Full log

View this message in rfc822 format

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: 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)]

Previous Next

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