From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Sat, 26 May 2012 17:07:46 -0700 Message-ID: <6A40227DCFBF427491B710A473E45744@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1338077347 16512 80.91.229.3 (27 May 2012 00:09:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 27 May 2012 00:09:07 +0000 (UTC) To: 11566@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 27 02:09:06 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 1SYR2b-0007GS-0j for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 May 2012 02:09:01 +0200 Original-Received: from localhost ([::1]:41223 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYR2a-0002Oo-KD for geb-bug-gnu-emacs@m.gmane.org; Sat, 26 May 2012 20:09:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYR2W-0002OF-59 for bug-gnu-emacs@gnu.org; Sat, 26 May 2012 20:08:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYR2U-0006ds-3K for bug-gnu-emacs@gnu.org; Sat, 26 May 2012 20:08:55 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYR2T-0006dk-Vh for bug-gnu-emacs@gnu.org; Sat, 26 May 2012 20:08:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SYR3a-000317-78 for bug-gnu-emacs@gnu.org; Sat, 26 May 2012 20:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 May 2012 00:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 11566 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: Original-Received: via spool by submit@debbugs.gnu.org id=B.133807736411544 (code B ref -1); Sun, 27 May 2012 00:10:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 27 May 2012 00:09:24 +0000 Original-Received: from localhost ([127.0.0.1]:45049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYR2x-000308-IK for submit@debbugs.gnu.org; Sat, 26 May 2012 20:09:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36156) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYR2u-0002zt-C0 for submit@debbugs.gnu.org; Sat, 26 May 2012 20:09:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYR1g-0006aC-6S for submit@debbugs.gnu.org; Sat, 26 May 2012 20:08:06 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:50644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYR1g-0006a8-3O for submit@debbugs.gnu.org; Sat, 26 May 2012 20:08:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYR1e-0002Fa-1u for bug-gnu-emacs@gnu.org; Sat, 26 May 2012 20:08:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYR1b-0006Zc-R3 for bug-gnu-emacs@gnu.org; Sat, 26 May 2012 20:08:01 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:33532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYR1b-0006ZW-Jk for bug-gnu-emacs@gnu.org; Sat, 26 May 2012 20:07:59 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4R07uKA011275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 27 May 2012 00:07:57 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4R07tHH007578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 May 2012 00:07:56 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4R07t4E001880 for ; Sat, 26 May 2012 19:07:55 -0500 Original-Received: from dradamslap1 (/10.159.171.147) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 26 May 2012 17:07:55 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac07nL50doxlNB7uQ7ued1JnNmMZyw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:60381 Archived-At: Not a recipe from emacs -Q - sorry. Please bear with my description. I don't claim to understand things 100%, but this is what I think is going on. I really hope that someone who understands better can help. Normally, if you have a standalone minibuffer frame, then when `read-from-minibuffer' is called the input focus switches to that frame - which it should, so that your typed input goes into the minibuffer. However, it can happen that the focus sometimes does not go to the minibuffer frame (or perhaps it leaves that frame? dunno). And that's the problem I'm looking for a solution to. 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. 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'.] 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. 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? 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. 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. (Stefan? Martin? ...) In GNU Emacs 24.0.97.1 (i386-mingw-nt5.1.2600) of 2012-05-16 on MARVIN Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.6) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include'