* bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
@ 2014-06-08 15:05 Drew Adams
2020-12-04 11:57 ` Lars Ingebrigtsen
0 siblings, 1 reply; 9+ messages in thread
From: Drew Adams @ 2014-06-08 15:05 UTC (permalink / raw)
To: 17736
Put this code in a file:
-------------------------
(defun 1on1-emacs () ""
(interactive)
(setq default-frame-alist (list (cons 'minibuffer nil)))
(setq pop-up-frames t)
(setq minibuffer-frame-alist 1on1-minibuffer-frame-alist)
(make-frame 1on1-minibuffer-frame-alist)
(setq minibuffer-auto-raise t)
(setq w32-grab-focus-on-raise nil))
(global-set-key [C-S-mouse-1]
(lambda () (interactive)
(message "FR: %S" (selected-frame))))
-------------------------
runemacs.exe -Q --debug-init -l "onetest.el" -f "1on1-emacs"
C-x b *Messages*
C-x 5 2
C-x b *scratch*
You now have a frame showing *Messages*, a frame showing *scratch*, and
a standalone minibuffer frame. Make the first two frames small enough
that you can see both of them and the minibuffer frame.
1. Click `mouse-1' in the *scratch* frame, or otherwise select it and
give it focus.
2. Click `C-S-mouse-1' in the *scratch* frame. You see the message
indicating that this is the selected frame. Click `C-S-mouse-1' in
the *Messages* frame. Again, the message indicates that the clicked
frame is the (newly) selected frame.
3. Repeat #1, to select frame *scratch*. `M-x', then click
`C-S-mouse-1' in the *Messages* frame (*not* the selected frame
before you clicked). You again see a message indicating that the
clicked frame (*Messages*) is the (newly) selected frame.
4. With *scratch* still the selected frame, `M-x', then click in frame
*scratch* (the selected frame before you clicked). The message says
that the standalone minibuffer frame is the selected frame.
1-3 are normal. #4 is the bug. A command bound to `C-S-mouse-1' does
not act on the frame that you click. The same behavior occurs if you
use `S-mouse-1', `C-mouse-1', or even `mouse-1' instead of
`C-S-mouse-1' in the recipe (but you may also need to set
`*-down-mouse-1' to nil).
In sum, a mouse click while the minibuffer is active does this:
* Acts on the clicked frame, if it was not the frame selected before
activating the minibuffer (or if is is the minibuffer frame). This
is what I would expect.
* Acts on the minibuffer frame, if the clicked frame was selected before
activating the minibuffer. This is not what I would expect (unless
the frame clicked is the minibuffer frame).
I would expect that the frame clicked always becomes the selected frame.
Is this expectation wrong?
I ask the question about whether the behavior should be exceptional this
way, because it is not new behavior: it is at least as old as Emacs 20.
It's not clear to me why Emacs behaves this way.
In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
of 2014-06-01 on ODIEONE
Bzr revision: 117212 michael.albinus@gmx.de-20140601104945-g88x0mwrxorz302h
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/snapshot/trunk
--enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
-Ic:/Devel/emacs/include''
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
2014-06-08 15:05 bug#17736: 24.4.50; *-mouse-1 acts on wrong frame Drew Adams
@ 2020-12-04 11:57 ` Lars Ingebrigtsen
2020-12-04 17:43 ` Drew Adams
0 siblings, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-04 11:57 UTC (permalink / raw)
To: Drew Adams; +Cc: 17736
Drew Adams <drew.adams@oracle.com> writes:
> Put this code in a file:
>
> -------------------------
> (defun 1on1-emacs () ""
> (interactive)
> (setq default-frame-alist (list (cons 'minibuffer nil)))
> (setq pop-up-frames t)
> (setq minibuffer-frame-alist 1on1-minibuffer-frame-alist)
> (make-frame 1on1-minibuffer-frame-alist)
> (setq minibuffer-auto-raise t)
> (setq w32-grab-focus-on-raise nil))
>
> (global-set-key [C-S-mouse-1]
> (lambda () (interactive)
> (message "FR: %S" (selected-frame))))
> -------------------------
>
> runemacs.exe -Q --debug-init -l "onetest.el" -f "1on1-emacs"
This recipe just gives me an error:
1on1-emacs: Symbol’s value as variable is void: 1on1-minibuffer-frame-alist
Do you have a working recipe that demonstrates this bug?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
2020-12-04 11:57 ` Lars Ingebrigtsen
@ 2020-12-04 17:43 ` Drew Adams
2020-12-04 20:46 ` Eli Zaretskii
2020-12-06 13:02 ` Lars Ingebrigtsen
0 siblings, 2 replies; 9+ messages in thread
From: Drew Adams @ 2020-12-04 17:43 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 17736
> Do you have a working recipe that demonstrates this bug?
Sorry; forgot that. Use this simpler file instead:
------------8<------------------
;; runemacs.exe -Q --debug-init -l "onetest.el" -f "1on1-emacs" "onetest.el"
(defun 1on1-emacs ()
""
(interactive)
(setq default-frame-alist
(list
'(font . "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1")
'(bottom-divider-width . 2)
'(minibuffer)))
(setq pop-up-frames t)
(setq minibuffer-frame-alist (list '(height . 2)
'(minibuffer . only))))
(global-set-key [C-S-mouse-1]
(lambda () (interactive)
(message "FR: %S" (selected-frame))))
------------8<------------------
And I should have said that after step 3 use C-g
or whatever to end that step's M-x. And select the
*scratch* frame. IOW, step 4 is a repeat of step 3,
except that you do C-S-mouse-1 in the same frame,
*scratch*, not in another frame.
I just checked, and the same bug exists from Emacs
24.5 through 27.1. IOW, it's still there.
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
2020-12-04 17:43 ` Drew Adams
@ 2020-12-04 20:46 ` Eli Zaretskii
2020-12-06 13:02 ` Lars Ingebrigtsen
1 sibling, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2020-12-04 20:46 UTC (permalink / raw)
To: Drew Adams; +Cc: larsi, 17736
> Date: Fri, 4 Dec 2020 09:43:47 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 17736@debbugs.gnu.org
>
> ;; runemacs.exe -Q --debug-init -l "onetest.el" -f "1on1-emacs" "onetest.el"
>
> (defun 1on1-emacs ()
> ""
> (interactive)
> (setq default-frame-alist
> (list
> '(font . "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1")
> '(bottom-divider-width . 2)
> '(minibuffer)))
> (setq pop-up-frames t)
> (setq minibuffer-frame-alist (list '(height . 2)
> '(minibuffer . only))))
> (global-set-key [C-S-mouse-1]
> (lambda () (interactive)
> (message "FR: %S" (selected-frame))))
>
> ------------8<------------------
>
> And I should have said that after step 3 use C-g
> or whatever to end that step's M-x. And select the
> *scratch* frame. IOW, step 4 is a repeat of step 3,
> except that you do C-S-mouse-1 in the same frame,
> *scratch*, not in another frame.
>
> I just checked, and the same bug exists from Emacs
> 24.5 through 27.1. IOW, it's still there.
Why is that a bug? Clicking a mouse doesn't necessarily select the
frame where you click; if you want to know which frame you clocked on,
you should look at the click event.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
2020-12-04 17:43 ` Drew Adams
2020-12-04 20:46 ` Eli Zaretskii
@ 2020-12-06 13:02 ` Lars Ingebrigtsen
2020-12-06 17:20 ` Drew Adams
1 sibling, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-06 13:02 UTC (permalink / raw)
To: Drew Adams; +Cc: 17736
Drew Adams <drew.adams@oracle.com> writes:
> Sorry; forgot that. Use this simpler file instead:
>
> ------------8<------------------
>
> ;; runemacs.exe -Q --debug-init -l "onetest.el" -f "1on1-emacs" "onetest.el"
>
> (defun 1on1-emacs ()
> ""
> (interactive)
> (setq default-frame-alist
> (list
> '(font . "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1")
> '(bottom-divider-width . 2)
> '(minibuffer)))
> (setq pop-up-frames t)
> (setq minibuffer-frame-alist (list '(height . 2)
> '(minibuffer . only))))
All that can't be necessary -- I don't have that font, so the example
still didn't work.
I removed the font setting, though, and tried to follow your recipe.
> (global-set-key [C-S-mouse-1]
> (lambda () (interactive)
> (message "FR: %S" (selected-frame))))
>
> ------------8<------------------
>
> And I should have said that after step 3 use C-g
> or whatever to end that step's M-x. And select the
> *scratch* frame. IOW, step 4 is a repeat of step 3,
> except that you do C-S-mouse-1 in the same frame,
> *scratch*, not in another frame.
And I was unable to, either because I don't understand the recipe, or
because the bugs isn't present in Emacs 28.
Could you provide a simpler step by step recipe to demonstrate the bug?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
2020-12-06 13:02 ` Lars Ingebrigtsen
@ 2020-12-06 17:20 ` Drew Adams
2020-12-07 13:45 ` Lars Ingebrigtsen
0 siblings, 1 reply; 9+ messages in thread
From: Drew Adams @ 2020-12-06 17:20 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 17736
> I removed the font setting, though,
Yes.
> and tried to follow your recipe.
> And I was unable to, either because I don't understand
> the recipe, or because the bugs isn't present in Emacs 28.
>
> Could you provide a simpler step by step recipe to
> demonstrate the bug?
Could you say what you don't understand about the recipe?
Or could you explain what "I was unable to" amounts to?
Can you try with either the release for which the bug was
filed or other releases mentioned, which include Emacs 27?
There is no release Emacs 28, so I can't help you with that.
With Emacs 27.1, simply doing what I said shows the
reported behavior immediately, 100% of the time.
Here's the complete recipe again, in one place:
Command to start Emacs:
z:\...\runemacs.exe -Q -l "onetest.el" -f "1on1-emacs"
File onetest.el contains this code:
(defun 1on1-emacs ()
(interactive)
(setq default-frame-alist
(list '(bottom-divider-width . 2)
'(minibuffer)))
(setq pop-up-frames t)
(setq minibuffer-frame-alist (list '(height . 2)
'(minibuffer . only))))
(global-set-key [C-S-mouse-1]
(lambda () (interactive)
(message "FR: %S" (selected-frame))))
1. `C-x 5 o' to select frame *scratch*.
2. `C-x 5 2' to duplicate that frame.
3. `C-x b' to have that frame show *Messages*.
4. Resize the two non-minibuffer frames, so you
can easily see all 3 frames completely.
5. Select the *scratch* frame (e.g. click mouse-1 there).
6. `C-S-mouse-1' in *scratch*. See message in *Messages*
saying that the selected frame is *scratch*.
7. Select *scratch* frame. `C-S-mouse-1' in *Messages*.
See message saying that selected frame is *Messages*.
8. Select *scratch* frame. `M-x', then `C-S-mouse-1' in
*Messages*. See message: selected frame is *Messages*.
`C-g' to cancel `M-x'.
9. Select *scratch* frame. `M-x', then `C-S-mouse-1' in
*scratch*. See message in both *Messages* and echo
area (minibuffer frame): selected frame is
" *Minibuf-1*".
#9 is unexpected.
Can you repro this? If so, we can talk about whether
#9 should be expected or is a bug.
It's possible that the behavior depends on the platform.
I'm using MS Windows (10). It may well handle frame
focusing differently from some other platforms.
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
2020-12-06 17:20 ` Drew Adams
@ 2020-12-07 13:45 ` Lars Ingebrigtsen
2020-12-07 16:27 ` Drew Adams
0 siblings, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-07 13:45 UTC (permalink / raw)
To: Drew Adams; +Cc: 17736
Drew Adams <drew.adams@oracle.com> writes:
> 9. Select *scratch* frame. `M-x', then `C-S-mouse-1' in
> *scratch*. See message in both *Messages* and echo
> area (minibuffer frame): selected frame is
> " *Minibuf-1*".
>
> #9 is unexpected.
>
> Can you repro this?
Thanks for the recipe; I now see the behaviour you're describing.
> If so, we can talk about whether #9 should be expected or is a bug.
The thing is, in your setup, typing `M-x' selects the minibuffer frame
-- the *scratch* frame loses focus. So I agree with what Eli said
earlier: I think this is consistent behaviour, and you have to examine
the event you're getting to see what frame the user clicked in.
So I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
2020-12-07 13:45 ` Lars Ingebrigtsen
@ 2020-12-07 16:27 ` Drew Adams
2020-12-07 17:04 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Drew Adams @ 2020-12-07 16:27 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 17736
> > 9. Select *scratch* frame. `M-x', then `C-S-mouse-1' in
> > *scratch*. See message in both *Messages* and echo
> > area (minibuffer frame): selected frame is
> > " *Minibuf-1*".
> >
> > #9 is unexpected.
> >
> > Can you repro this?
>
> Thanks for the recipe; I now see the behaviour you're describing.
>
> > If so, we can talk about whether #9 should be expected or is a bug.
>
> The thing is, in your setup, typing `M-x' selects the minibuffer frame
> -- the *scratch* frame loses focus. So I agree with what Eli said
> earlier: I think this is consistent behaviour, and you have to examine
> the event you're getting to see what frame the user clicked in.
>
> So I'm closing this bug report.
This is wrong, IMO. I think you're missing the point.
Yes, `M-x' selects the minibuffer frame. It does so
in ALL cases - in the case when the starting frame is
*Messages* as much as when the starting frame is
*scratch*. That's 100% normal.
But THEN, if a user selects another frame, that frame
should be, well, selected - focused. The behavior seen
for *Messages* should also happen for *scratch*.
A user should be able to switch frames whether or not an
`M-x' is in progress. And she should be able to switch
frames, in particular, to do something that might affect
or inform the ongoing behavior of `M-x'.
A user can switch to another frame and then come back to
the minibuffer frame. She can already do this for a
different frame from the one that initiated minibuffer
interaction (`M-x' in this case). There's zero reason
why she can't do this also for that initiating frame (or
please supply a reason!).
There's no reason (or else please supply one!) why the
minibuffer frame should keep, and not relinquish, focus
when the user explicitly selects another frame.
I know that you guys are not used to interacting with a
standalone minibuffer frame. But that should not limit
your ability to understand/imagine how it can be used.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-12-07 17:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-08 15:05 bug#17736: 24.4.50; *-mouse-1 acts on wrong frame Drew Adams
2020-12-04 11:57 ` Lars Ingebrigtsen
2020-12-04 17:43 ` Drew Adams
2020-12-04 20:46 ` Eli Zaretskii
2020-12-06 13:02 ` Lars Ingebrigtsen
2020-12-06 17:20 ` Drew Adams
2020-12-07 13:45 ` Lars Ingebrigtsen
2020-12-07 16:27 ` Drew Adams
2020-12-07 17:04 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).