[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28620: Emacs bug#28620: (PARTIAL SOLUTION) mouse-position wrong on m
From: |
Bob Weiner |
Subject: |
bug#28620: Emacs bug#28620: (PARTIAL SOLUTION) mouse-position wrong on macOS and Windows 7 after mouse-1 click |
Date: |
Mon, 16 Oct 2017 11:11:33 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) 27.0.50, InfoDock 4.0.8 |
Robert Weiner <rsw@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.
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))
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#28620: Emacs bug#28620: (PARTIAL SOLUTION) mouse-position wrong on macOS and Windows 7 after mouse-1 click,
Bob Weiner <=