GNU bug report logs - #11939
24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 11939 <at> debbugs.gnu.org
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls	`list-processes'
Date: Sat, 21 Jul 2012 11:13:52 -0700

>  >> Someone (maybe Jan) once said that it's hard to override any such
>  >> decisions when they are made by the window manager.
>  >
>  > I did not mean override (prevent/nullify).  I meant 
>  > automatically take remedial action after the window manager's
>  > autofocus takes effect.  I.e., automatically
>  > move the focus back where it was.
> 
> I'm not quite sure what "after" means in this context.  IIUC Emacs is
> not informed that the frame has been posted on screen.  It will know
> about it only implicitly when it's passed input directed to 
> that frame.

OK.  I really know nothing about this area.

> Emacs selects a new frame.  But if it's minibufferless, it doesn't
> necesarily redirect input to the minibuffer frame.  IIUC it 
> does so only when it reads input from that frame.

I see.  And if reading from the minibuffer was already started (e.g. before the
new frame was actually created) then the new frame will not have its focus
directed to the minibuffer, even though reading is in progress.

> My speculation is still the same: The window manager focuses the new
> frame and Emacs does not redirect input to the minibuffer frame.

OK.

Previous Next

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