GNU bug report logs - #17736
24.4.50; *-mouse-1 acts on wrong frame

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sun, 8 Jun 2014 15:07:02 UTC

Severity: normal

Tags: moreinfo, notabug

Found in version 24.4.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 17736 <at> 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)
> > 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.




This bug report was last modified 4 years and 162 days ago.

Previous Next


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