From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Sun, 27 May 2012 15:22:21 +0200 Message-ID: <4FC22A8D.6040801@gmx.at> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1338124981 27217 80.91.229.3 (27 May 2012 13:23:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 27 May 2012 13:23:01 +0000 (UTC) Cc: 11566@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 27 15:23:00 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SYdQu-0006ZV-9h for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 May 2012 15:22:56 +0200 Original-Received: from localhost ([::1]:43584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYdQt-0004S5-TH for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 May 2012 09:22:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYdQq-0004S0-UT for bug-gnu-emacs@gnu.org; Sun, 27 May 2012 09:22:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYdQo-0000ul-SL for bug-gnu-emacs@gnu.org; Sun, 27 May 2012 09:22:52 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYdQo-0000uY-On for bug-gnu-emacs@gnu.org; Sun, 27 May 2012 09:22:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SYdRy-0005ce-7g for bug-gnu-emacs@gnu.org; Sun, 27 May 2012 09:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 May 2012 13:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11566 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11566-submit@debbugs.gnu.org id=B11566.133812503221597 (code B ref 11566); Sun, 27 May 2012 13:24:02 +0000 Original-Received: (at 11566) by debbugs.gnu.org; 27 May 2012 13:23:52 +0000 Original-Received: from localhost ([127.0.0.1]:45354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYdRn-0005cH-Uq for submit@debbugs.gnu.org; Sun, 27 May 2012 09:23:52 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:35905) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SYdRT-0005bj-Np for 11566@debbugs.gnu.org; Sun, 27 May 2012 09:23:51 -0400 Original-Received: (qmail invoked by alias); 27 May 2012 13:22:13 -0000 Original-Received: from 62-47-61-97.adsl.highway.telekom.at (EHLO [62.47.61.97]) [62.47.61.97] by mail.gmx.net (mp035) with SMTP; 27 May 2012 15:22:13 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1929ehn6ON25XqX06J9EDL49lD3Wm6I0cPJxf9CG6 hT6vMVQROoClJS In-Reply-To: <6A40227DCFBF427491B710A473E45744@us.oracle.com> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:60398 Archived-At: > On MS Windows at least, when a new frame is created it grabs the input > focus. The problem where the minibuffer frame does not get the focus it > needs seems to arise in a situation where a new frame is popped up and > then `read-from-minibuffer' is called immediately afterward. Maybe > there is some kind of contention or delay/race problem here (?) - I have > no idea. You should be able to check this by inserting a (sit-for 1) somewhere in between popping up the frame and calling `read-from-minibuffer'. > For example, `dired-mark-read-string' calls `dired-mark-pop-up' to read > a string using `read-from-minibuffer' (`r-f-m' is the FUNCTION arg > passed to `d-m-p-u' in this case). > > Inside a `save-window-excursion', `dired-mark-pop-up' then calls > `dired-pop-to-buffer', which pops up a new buffer, which (let's say, > because of `special-display-regexp' or whatever) is shown in a new > frame. MS Windows gives this frame the input focus. > > Then, still inside the `save-window-excursion', `dired-mark-pop-up' > immediately calls the FUNCTION arg, which in this case is > `read-from-minibuffer'. (It does this using (apply FUNCTION args), but > that should not make any difference.) > > [I don't think it matters for correctness whether the (apply FUNCTION > args) is inside the `save-window-excursion'. I've tried moving it > outside, but that did not change anything. I would think that it should > be outside logically (why perform the action from that buffer?), but I'm > not knowledgeable about all use cases of `dired-mark-pop-up'.] IIRC _you_ don't need the `save-window-excursion'. So replace it with a `progn' and I'm sure you won't notice any difference. > OK, so what happens is this: When `read-from-minibuffer' does its thing, > the standalone minibuffer does not receive the user input. Instead, the > input goes to the popped-up frame (which has a list of *Marked Files*). > > That seems to be an exception to the general rule that > `read-from-minibuffer' correctly moves the focus to the minibuffer - and > to its frame. 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. > I don't know why there is a difference in this case, but > that seems to be what happens. The problem is not specific to this > example - it can occur at other times. But I think that this is a good > case to follow what's happening. > > I've tried various workarounds, with more or less success. But I'm > thinking now that the problem is not in any such functions that pop up a > frame etc. but rather with `read-from-minibuffer' itself. Shouldn't it > have the responsibility here to give the minibuffer frame the focus? Yes. But the window manager must not intercept it. > Here is a workaround I've come up with when trying to "fix" `r-f-m' > itself: > > (defadvice read-from-minibuffer (around focus-standalone-minibuf activate) > "..." > (let ((selframe (selected-frame)) > result) > (unwind-protect > (progn (when (and (boundp '1on1-minibuffer-frame) > (frame-live-p 1on1-minibuffer-frame)) > (select-frame-set-input-focus 1on1-minibuffer-frame)) > (setq result ad-do-it)) > (ignore-errors (select-frame-set-input-focus selframe)) > result))) > > (In my case I know that the standalone minibuffer, if it exists, is the > value of `1on1-minibuffer-frame'. Not sure how the use of a standalone > minibuffer would be detected in general - presumably by checking for a > frame that has a `minibuffer' parameter with value `only'...) > > But that defadvice does not always make `r-f-m' DTRT, in any case. For > example, if the originally selected frame is deleted during `ad-do-it', > then it punts and leaves the input focus in the minibuffer frame. What > I would probably expect (want) in that case is for the previously > selected frame to get the focus. I'm afraid that in this special case the current code will fail as well. > For example, if I tweak `dired-mark-pop-up' so that it deletes the > popped up frame at the end, then - since that frame was selected (by the > window manager) when `read-from-minibuffer' was called - the minibuffer > frame ends up with the focus. > > (And I do tweak `d-m-p-u' that way, because of another problem with such > a popped up frame - see bug #7533.) > > Any help is appreciated. Hope I've made the problem clear enough, > though you would probably have to be on Windows to see it manifested. > I really hope that someone with better understanding than I can help. 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'. martin