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: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11939 <at> debbugs.gnu.org
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls	`list-processes'
Date: Thu, 19 Jul 2012 12:41:48 +0200

> How?  What are you doing to not get this error, which I get when I use emacs -Q
> without loading the Cygwin stuff?
>
>  "Spawning child process: invalid argument

No idea.  Maybe this is the Powershell issue described in

http://tb-nguyen.blogspot.co.at/2010/05/how-to-fix-emacs-windows-error-spawning.html

I just checked on a SP3 machine and am sure that just installing SP3 is
not sufficient for the problem to show up.

>> I still don't understand the consequences described in the
>> doc-string of `redirect-frame-focus' as
>>
>>     A frame's focus redirection can be changed by `select-frame'.
>>     If frame FOO is selected, and then a different frame BAR is
>>     selected, any frames redirecting their focus to FOO are shifted
>>     to redirect their focus to BAR.  This allows focus redirection
>>     to work properly when the user switches from one frame to another
>>     using `select-window'.
>
> I think that last part means only that focus switches when you select a frame,
> even if the previously selected frame was not really selected but had the focus
> only via a redirection from the actually selected frame.

It seems to say that when a frame X has focus redirected to the selected
frame A and I now select a frame B then focus for X is redirected to B.

But why is that useful?

>>     This means that a frame whose focus is redirected to itself is
>>     treated differently from a frame whose focus is redirected to
>>     nil; the former is affected by `select-frame', while the latter is not.
>
> It does not say what does affect the latter.  Not too clear to me.

It seems to say that when a selected frame A's focus is redirected to A
itself and I now select frame B, focus from A is redirected to B.  Now
suppose a minibuffer-only frame is selected and had focus directed to
itself. If now a minibuffer-less frame gets selected, focus will be
directed to that frame which hardly makes sense to me.

>> so there might be still some surprises around the corner.
>>
>> IMHO the thing that's crucial is that if you want to peruse a separate
>> minibuffer frame after popping up a new frame, you have to do it from
>> the freshly popped up frame.
>
> Sounds reasonable.  What might (?) be good would be to find a way to simply
> counteract (undo) the auto-focus/selection of the new frame whenever focus was
> in the minibuffer frame (and the minibuffer is active).  IOW, perhaps that can
> be done automatically.  Dunno whether doing that systematically would be a good
> idea or not (or whether it is easy to do).

Someone (maybe Jan) once said that it's hard to override any such
decisions when they are made by the window manager.

>> For example, if you pop up a new frame and
>> then want to ask a `yes-or-no-p' question, you have to select the new
>> frame, issue the `yes-or-no-p' there,
>
> Yes, that would be one way of solving the problem, perhaps, if we could ensure
> that that happened.  But the ordering of such events might be fragile - and it
> might depend on the platform etc.

IIUC creating a WM window (via CreateWindow) returns a handle to a new
WM window independently from whether that window already appears on the
screen and/or obscures other windows.  I don't know whether and how the
window manager informs Emacs that a window has appeared on the screen.
I suppose it doesn't and that information is passed to emacs implicitly
when the user "selects" that window by using the keyboard or the mouse.

>> and hope that read_minibuf correctly redirects the prompt to the minibuffer
> frame.
>
> My guess is that it does, always.

Apparently not always as we know meanwhile.

> Again, my guess is that it did that
> correctly, but the new frame was then created (the creation might have started
> before the read_minibuf, but the new focus took effect after the redirection to
> the minibuffer, in any case).  Just a guess.

From what you said it seems to work as long as no new frames are
created.  When a new frame is created, it may take some time for this
mechanism to adapt itself to the new configuration.

martin

Previous Next

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