GNU bug report logs - #11566
24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

Previous Next

Package: emacs;

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

Date: Sun, 27 May 2012 00:10:01 UTC

Severity: normal

Found in version 24.0.97

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 11566 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11566 <at> debbugs.gnu.org
Subject: Re: bug#11566: 24.0.97;	`read-from-minibuffer': focus to standalone
	minibuffer frame?
Date: Tue, 29 May 2012 11:43:00 +0200
>> IIUC `read-from-minibuffer' uses `redirect-frame-focus' to send the
>> keystrokes to the minibuffer window.  If that function works
>> for you in general, we likely have a race condition in this special case.
>
> If so, what could a solution/fix be for it?

You didn't tell us whether it works for you "in general".  If you work
with two frames for "some time" does `redirect-frame-focus' what it is
supposed to do?  If it doesn't we have a strange situation where, citing
from Ito's comment in bug#11513,

> > When I run lower-frame function in Emacs frame interactively, Emacs
> > frame is brought behind of other application window(s) but has focus.
> > Key inputs are passed to lowered frame.  I tested 4 Windows PC, and
> > all PCs show the same behavior.

so Windows OT1H handles key input passed to a frame that is not in the
foreground and OTOH doesn't pass key input to another frame even if
explicitly asked to do so.

>>  > Shouldn't [`read-from-minibuffer'] have the responsibility
>>  > here to give the minibuffer frame the focus?
>>
>> Yes.  But the window manager must not intercept it.
>
> But that's what seems to be happening (intercept or interrupt or some such).

That's what we have to find out.

>> Try the sit-for approach.  Try to make a standalone example like
>> (let ((old-frame ... some existing frame))
>>    (make-frame)
>>    (redirect-frame-focus old-frame))
>> and see whether it fails giving focus to `old-frame'.
>
> Still not sure what you mean by using `sit-for' (how/where?).  But I tried that
> simple example, and yes, it systematically fails to give focus to `old-frame'.
> The newly created frame keeps the focus - every time.

I suppose my example was just silly.  Maybe you should try again with

(let ((old-frame (selected-frame))
      (new-frame (make-frame)))
  (redirect-frame-focus new-frame old-frame))

I don't know anything about `redirect-frame-focus' and can't test it
reliably here because I'm using special autoraise-frame settings which
likely interfere with any such focus redirection.

martin




This bug report was last modified 12 years and 233 days ago.

Previous Next


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