From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 17736@debbugs.gnu.org
Subject: bug#17736: 24.4.50; *-mouse-1 acts on wrong frame
Date: Mon, 7 Dec 2020 08:27:31 -0800 (PST) [thread overview]
Message-ID: <75675a0c-1026-4ff2-94f5-d1eb2bb53ed4@default> (raw)
In-Reply-To: <87blf5k9uw.fsf@gnus.org>
> > 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.
next prev parent reply other threads:[~2020-12-07 16:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2020-12-07 17:04 ` 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=75675a0c-1026-4ff2-94f5-d1eb2bb53ed4@default \
--to=drew.adams@oracle.com \
--cc=17736@debbugs.gnu.org \
--cc=larsi@gnus.org \
/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.