From unknown Fri Jun 20 07:23:28 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#11566 <11566@debbugs.gnu.org> To: bug#11566 <11566@debbugs.gnu.org> Subject: Status: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Reply-To: bug#11566 <11566@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:23:28 +0000 retitle 11566 24.0.97; `read-from-minibuffer': focus to standalone minibuff= er frame? reassign 11566 emacs submitter 11566 "Drew Adams" severity 11566 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat May 26 20:09:24 2012 Received: (at submit) by debbugs.gnu.org; 27 May 2012 00:09:24 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 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 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 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 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 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 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 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 Received: from dradamslap1 (/10.159.171.147) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 26 May 2012 17:07:55 -0700 From: "Drew Adams" To: Subject: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) 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' From debbugs-submit-bounces@debbugs.gnu.org Sun May 27 09:23:52 2012 Received: (at 11566) by debbugs.gnu.org; 27 May 2012 13:23:52 +0000 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 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 Received: (qmail invoked by alias); 27 May 2012 13:22:13 -0000 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 Message-ID: <4FC22A8D.6040801@gmx.at> Date: Sun, 27 May 2012 15:22:21 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> In-Reply-To: <6A40227DCFBF427491B710A473E45744@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11566 Cc: 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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 From debbugs-submit-bounces@debbugs.gnu.org Sun May 27 11:03:31 2012 Received: (at 11566) by debbugs.gnu.org; 27 May 2012 15:03:31 +0000 Received: from localhost ([127.0.0.1]:45618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYf0E-0007sV-T1 for submit@debbugs.gnu.org; Sun, 27 May 2012 11:03:31 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:43015) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SYf0C-0007sJ-IC for 11566@debbugs.gnu.org; Sun, 27 May 2012 11:03:29 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4RF29LA024529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 27 May 2012 15:02:10 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4RF29eJ011669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 May 2012 15:02:09 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4RF28aP001656; Sun, 27 May 2012 10:02:08 -0500 Received: from dradamslap1 (/10.159.190.91) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 27 May 2012 08:02:08 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Sun, 27 May 2012 08:01:58 -0700 Message-ID: <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac08C7v/FACUIl/XTjaNFKSLJNjfbQACrN1g In-Reply-To: <4FC22A8D.6040801@gmx.at> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > 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'. Not too sure what you mean, but the test you proposed at the end of your post seems to replace this - and it was telling. > 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? > > 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). > > Here is a workaround I've come up with when trying to > > "fix" `r-f-m' itself:... > > > > 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. > > I'm afraid that in this special case the current code will > fail as well. So - at least wrt that particular failing - it shouldn't hurt to add code similar in effect to my defadvice to the C code for `read-from-minibuffer'? It's just a question, as I'm not confident that the cure would be benign in all cases. In any case, it is not a real fix for the problem. I hope you might have some ideas for that. > 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. That it does this systematically makes me think it is not a race condition but some other problem. Placing a (sit-for 20) between the `make-frame' and the `redirect...' made no difference. Likewise, with `sleep-for'. The new frame is created, but no text is visibly displayed in it for the `sleep-for' period, then the text appears (and the focus is still in the new frame). The new frame is selected as soon as it is created (as told by its title bar being highlighted), and it apparently remains so throughout. So it would appear that that is the bug/problem. How to fix it so that `redirect-frame-focus' can actually redirect the focus in this case? I also tried some other things, like calling `force-mode-line-update' at the end, thinking it might be an Emacs display problem. And I tried calling `redirect...' more than once. But no luck. I even tried explicitly redirecting to the new frame and then back to the old frame (and vice versa): (let ((old-frame (selected-frame)) (new-frame (make-frame))) ;; (sleep-for 20) (redirect-frame-focus new-frame) (redirect-frame-focus old-frame)) So far, no luck getting Windows's attention and actually changing the frame focus. Hope you can see some light at the end of the tunnel. It would really be good (for me at least) to get this fixed. I have a hunch that this might be at the origin of other frame-related problems that I have dealt with more or less successfully using various workarounds (e.g. calls to `select-frame-set-input-focus'). From debbugs-submit-bounces@debbugs.gnu.org Mon May 28 14:04:27 2012 Received: (at 11566) by debbugs.gnu.org; 28 May 2012 18:04:27 +0000 Received: from localhost ([127.0.0.1]:46930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZ4It-0003v8-1A for submit@debbugs.gnu.org; Mon, 28 May 2012 14:04:27 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:45308) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZ4Ir-0003uv-4G for 11566@debbugs.gnu.org; Mon, 28 May 2012 14:04:25 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4SI2wHw004813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <11566@debbugs.gnu.org>; Mon, 28 May 2012 18:02:59 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4SI2wun010648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <11566@debbugs.gnu.org>; Mon, 28 May 2012 18:02:58 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4SI2vDc014195 for <11566@debbugs.gnu.org>; Mon, 28 May 2012 13:02:57 -0500 Received: from dradamslap1 (/10.159.220.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 May 2012 11:02:57 -0700 From: "Drew Adams" To: <11566@debbugs.gnu.org> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Mon, 28 May 2012 11:02:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6A40227DCFBF427491B710A473E45744@us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac07nL50doxlNB7uQ7ued1JnNmMZywBXxK7A X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > 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))) FYI - Not sure why (haven't looked), but that defadvice makes it impossible to see any messages in the minibuffer. I need to open *Messages* to see any messages. So such an approach is definitely not sufficient. From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 05:44:33 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 09:44:33 +0000 Received: from localhost ([127.0.0.1]:47555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZIye-0002wM-VF for submit@debbugs.gnu.org; Tue, 29 May 2012 05:44:33 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:33189) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SZIyc-0002w9-DO for 11566@debbugs.gnu.org; Tue, 29 May 2012 05:44:31 -0400 Received: (qmail invoked by alias); 29 May 2012 09:43:02 -0000 Received: from 62-47-42-71.adsl.highway.telekom.at (EHLO [62.47.42.71]) [62.47.42.71] by mail.gmx.net (mp040) with SMTP; 29 May 2012 11:43:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/HGhFRvQzHsrzhmqnG5YvZlwXG2AWDddLEC46m7V bRlwxtHt8fWTEn Message-ID: <4FC49A24.7000403@gmx.at> Date: Tue, 29 May 2012 11:43:00 +0200 From: martin rudalics MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> In-Reply-To: <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11566 Cc: 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 10:14:19 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 14:14:19 +0000 Received: from localhost ([127.0.0.1]:48411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZNBi-0005eT-75 for submit@debbugs.gnu.org; Tue, 29 May 2012 10:14:19 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:22887) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZNBf-0005eF-MC for 11566@debbugs.gnu.org; Tue, 29 May 2012 10:14:16 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4TECivE012398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 14:12:45 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4TECh2M025750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 14:12:44 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4TEChvP007390; Tue, 29 May 2012 09:12:43 -0500 Received: from dradamslap1 (/10.159.177.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 07:12:43 -0700 From: "Drew Adams" To: "'martin rudalics'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Tue, 29 May 2012 07:12:26 -0700 Message-ID: <96A3CCDD100E49C6ACF2739484C9239A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4FC49A24.7000403@gmx.at> Thread-Index: Ac09f3I3qqJcnmrkQAe6WfnNW02C0QAI1M0w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > 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, Sorry, I don't know what you mean. I have been using multiple frames for a long time, yes. But I do not directly call `redirect-frame-focus'. I do call `select-frame-set-input-focus' in various places. Does that mean that `r-f-f' works for me in general? I really have no idea. > > > 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. Yes, I was the first to confirm what was reported in bug #11513. > 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. Apparently so. (That a window manager can accept input passed to a frame that is not on top in the stacking order is not exceptional. That is (was, at least) true for many w. mgrs on UNIX, where you could even change the input focus without changing the stacking order ("foreground") just by moving the mouse over a lower frame.) > >> 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)) That puts (keeps) the input focus in old-frame. So it seems to work as it should. (But new-frame has its title and border highlighted as if it had the focus. Somehow there is a disconnect between the two. But maybe such highlighting is intended only to indicate the topmost frame? Dunno.) > 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. I know less that you, but I can perhaps test it if you suggest what to test. From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 11:41:59 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 15:41:59 +0000 Received: from localhost ([127.0.0.1]:48557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZOYY-0007hB-N5 for submit@debbugs.gnu.org; Tue, 29 May 2012 11:41:59 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:57779) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZOYW-0007gx-1A for 11566@debbugs.gnu.org; Tue, 29 May 2012 11:41:57 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4S00200JHXJP00@a-mtaout20.012.net.il> for 11566@debbugs.gnu.org; Tue, 29 May 2012 18:40:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4S001T2JJ5LBC0@a-mtaout20.012.net.il>; Tue, 29 May 2012 18:40:18 +0300 (IDT) Date: Tue, 29 May 2012 18:40:15 +0300 From: Eli Zaretskii Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? In-reply-to: <4FC49A24.7000403@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83aa0r2dy8.fsf@gnu.org> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11566 Cc: 11566@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 29 May 2012 11:43:00 +0200 > From: martin rudalics > Cc: 11566@debbugs.gnu.org > > > > 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 Careful with your terminology: at least on MS-Windows, a "foreground" frame is the frame that has focus and receives input. So what you say cannot happen by definition. In the scenario you cited above, the frame is lowered (i.e. brought behind, or "below" in Z-order, the other frames/windows), but it is still the foreground frame and therefore it still has focus and receives keyboard input. So it's unclear to me what exactly is the problem in the OT1H scenario. > and OTOH doesn't pass key input to another frame even if > explicitly asked to do so. I have just fixed a similar problem in bug #11513. I suggest that Drew wait until the corresponding binaries are available, and see whether this problem is solved as well. The problem in bug #11513 was that a frame that was already a foreground frame was not raised. Maybe something similar happens here. > >> > 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. I don't think this is what happens here. To raise a frame, Emacs sends a message with a private code to itself, so I doubt that the window manager could intercept or interrupt it, even if it wanted to. > 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. According to my reading, it just highlights the frame that had focus redirected to it. From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 11:46:00 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 15:46:00 +0000 Received: from localhost ([127.0.0.1]:48561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZOcS-0007mz-G6 for submit@debbugs.gnu.org; Tue, 29 May 2012 11:46:00 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:54457) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZOcQ-0007mm-7E for 11566@debbugs.gnu.org; Tue, 29 May 2012 11:45:59 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M4S00600JNGKY00@a-mtaout21.012.net.il> for 11566@debbugs.gnu.org; Tue, 29 May 2012 18:44:28 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4S006FVJQ352B0@a-mtaout21.012.net.il>; Tue, 29 May 2012 18:44:28 +0300 (IDT) Date: Tue, 29 May 2012 18:44:34 +0300 From: Eli Zaretskii Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? In-reply-to: <96A3CCDD100E49C6ACF2739484C9239A@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <838vgb2dr1.fsf@gnu.org> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <96A3CCDD100E49C6ACF2739484C9239A@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Date: Tue, 29 May 2012 07:12:26 -0700 > Cc: 11566@debbugs.gnu.org > > (That a window manager can accept input passed to a frame that is not on top in > the stacking order is not exceptional. That is (was, at least) true for many w. > mgrs on UNIX, where you could even change the input focus without changing the > stacking order ("foreground") just by moving the mouse over a lower frame.) "Stacking order" and "foreground" are 2 different things. As I wrote earlier, a "foreground" window/frame is the window that has focus and gets the keyboard input. It doesn't have to be on the top of the Z-order. > > (let ((old-frame (selected-frame)) > > (new-frame (make-frame))) > > (redirect-frame-focus new-frame old-frame)) > > That puts (keeps) the input focus in old-frame. So it seems to work as it > should. No, it keeps focus in new-frame, but makes it so the input you type at new-frame gets sent to old-frame. Thus, this: > (But new-frame has its title and border highlighted as if it had the focus. > Somehow there is a disconnect between the two. is normal and expected behavior (AFAIU). From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 12:12:04 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 16:12:04 +0000 Received: from localhost ([127.0.0.1]:48597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZP1f-0008Oi-Vu for submit@debbugs.gnu.org; Tue, 29 May 2012 12:12:04 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:21430) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZP1e-0008OA-2y for 11566@debbugs.gnu.org; Tue, 29 May 2012 12:12:02 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4TGAUom032058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 16:10:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4TGAUKR013394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 16:10:30 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4TGATvp011228; Tue, 29 May 2012 11:10:29 -0500 Received: from dradamslap1 (/10.159.177.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 09:10:29 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , "'martin rudalics'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <83aa0r2dy8.fsf@gnu.org> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Tue, 29 May 2012 09:10:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83aa0r2dy8.fsf@gnu.org> Thread-Index: Ac09sV89P4Zg8aKgSA6+xmzBT7FtfQAAx6pA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > Careful with your terminology: at least on MS-Windows, a "foreground" > frame is the frame that has focus and receives input. So what you say > cannot happen by definition. Got it. I too was using "foreground" to mean the topmost (highest in the stacking order), and not the frame that receives keyboard input. > I have just fixed a similar problem in bug #11513. I suggest that > Drew wait until the corresponding binaries are available, and see > whether this problem is solved as well. Got it. > The problem in bug #11513 was that a frame that was already a > foreground frame was not raised. Maybe something similar happens > here. Dunno. I don't have a lot of hope that it's related. But who knows? From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 12:12:07 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 16:12:07 +0000 Received: from localhost ([127.0.0.1]:48599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZP1i-0008Or-9x for submit@debbugs.gnu.org; Tue, 29 May 2012 12:12:06 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:21433) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZP1e-0008OB-3r for 11566@debbugs.gnu.org; Tue, 29 May 2012 12:12:03 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4TGAVda032068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 16:10:31 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4TGAUnP013415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 16:10:31 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4TGAUZ4012582; Tue, 29 May 2012 11:10:30 -0500 Received: from dradamslap1 (/10.159.177.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 09:10:30 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <96A3CCDD100E49C6ACF2739484C9239A@us.oracle.com> <838vgb2dr1.fsf@gnu.org> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Tue, 29 May 2012 09:10:15 -0700 Message-ID: <9A9A32EAE9D64B438EDA74E1F3F488FE@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <838vgb2dr1.fsf@gnu.org> Thread-Index: Ac09sfAUC3TMTAAORImbMwLH1PBGxgAAvQlw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > "Stacking order" and "foreground" are 2 different things. As I wrote > earlier, a "foreground" window/frame is the window that has focus and > gets the keyboard input. It doesn't have to be on the top of the > Z-order. Got it. > > > (let ((old-frame (selected-frame)) > > > (new-frame (make-frame))) > > > (redirect-frame-focus new-frame old-frame)) > > > > That puts (keeps) the input focus in old-frame. So it > > seems to work as it should. > > No, it keeps focus in new-frame, but makes it so the input you type at > new-frame gets sent to old-frame. Hm. Maybe I'm unclear about "focus". To me, "focus" was about input focus: the focused frame is the one that accepts/receives keyboard input. In something like `select-frame-set-input-focus', my interpretation was that frame selection was related to the border highlighting and setting input focus was related to receiving keyboard input. AFAIK, `select-frame' does the former, but `select-frame-set-input-focus' is needed to get the latter. > Thus, this: > > > (But new-frame has its title and border highlighted as if > > it had the focus. Somehow there is a disconnect between the two. > > is normal and expected behavior (AFAIU). Expected from `redirect-frame-focus', I guess you mean. So IIUC, `select-frame-set-input-focus' does `select-frame' plus `redirect-frame-focus'? From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 12:45:49 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 16:45:49 +0000 Received: from localhost ([127.0.0.1]:48652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZPYK-0000me-Pi for submit@debbugs.gnu.org; Tue, 29 May 2012 12:45:49 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:44212) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZPYH-0000mQ-Qj for 11566@debbugs.gnu.org; Tue, 29 May 2012 12:45:46 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4S00300M0D4300@a-mtaout20.012.net.il> for 11566@debbugs.gnu.org; Tue, 29 May 2012 19:44:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4S0021PMHPUD80@a-mtaout20.012.net.il>; Tue, 29 May 2012 19:44:13 +0300 (IDT) Date: Tue, 29 May 2012 19:44:19 +0300 From: Eli Zaretskii Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? In-reply-to: <9A9A32EAE9D64B438EDA74E1F3F488FE@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <831um32azg.fsf@gnu.org> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <96A3CCDD100E49C6ACF2739484C9239A@us.oracle.com> <838vgb2dr1.fsf@gnu.org> <9A9A32EAE9D64B438EDA74E1F3F488FE@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <11566@debbugs.gnu.org> > Date: Tue, 29 May 2012 09:10:15 -0700 > > > > > (let ((old-frame (selected-frame)) > > > > (new-frame (make-frame))) > > > > (redirect-frame-focus new-frame old-frame)) > > > > > > That puts (keeps) the input focus in old-frame. So it > > > seems to work as it should. > > > > No, it keeps focus in new-frame, but makes it so the input you type at > > new-frame gets sent to old-frame. > > Hm. Maybe I'm unclear about "focus". To me, "focus" was about input focus: the > focused frame is the one that accepts/receives keyboard input. Well, yes, but redirect-frame-focus explicitly parts them, AFAIU. > In something like `select-frame-set-input-focus', my interpretation was that > frame selection was related to the border highlighting and setting input focus > was related to receiving keyboard input. AFAIK, `select-frame' does the former, > but `select-frame-set-input-focus' is needed to get the latter. On Windows, at least with the default setup, selecting a frame also grabs focus. So these two functions do the same. > > Thus, this: > > > > > (But new-frame has its title and border highlighted as if > > > it had the focus. Somehow there is a disconnect between the two. > > > > is normal and expected behavior (AFAIU). > > Expected from `redirect-frame-focus', I guess you mean. Yes, of course. > So IIUC, `select-frame-set-input-focus' does `select-frame' plus > `redirect-frame-focus'? No, it just raises the frame after selecting it and makes sure it has focus (which in most situations it will have by virtue of being raised). From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 12:48:21 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 16:48:21 +0000 Received: from localhost ([127.0.0.1]:48664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZPan-0000r0-28 for submit@debbugs.gnu.org; Tue, 29 May 2012 12:48:21 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:44914) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZPal-0000qn-1d for 11566@debbugs.gnu.org; Tue, 29 May 2012 12:48:19 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4S00300MJ76C00@a-mtaout20.012.net.il> for 11566@debbugs.gnu.org; Tue, 29 May 2012 19:46:49 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4S0032EMM12O40@a-mtaout20.012.net.il>; Tue, 29 May 2012 19:46:49 +0300 (IDT) Date: Tue, 29 May 2012 19:46:56 +0300 From: Eli Zaretskii Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83zk8r0wan.fsf@gnu.org> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <83aa0r2dy8.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: <11566@debbugs.gnu.org> > Date: Tue, 29 May 2012 09:10:12 -0700 > > > Careful with your terminology: at least on MS-Windows, a "foreground" > > frame is the frame that has focus and receives input. So what you say > > cannot happen by definition. > > Got it. I too was using "foreground" to mean the topmost (highest in the > stacking order), and not the frame that receives keyboard input. Well, it's tricky terminology to be sure. > > The problem in bug #11513 was that a frame that was already a > > foreground frame was not raised. Maybe something similar happens > > here. > > Dunno. I don't have a lot of hope that it's related. But who knows? One can hope. However, in the interests of clarity, could you please describe the bug again, in terms of which frame has focus (i.e. is the "foreground" window), which is at the top of Z-order, and which has its border highlighted, after read-from-minibuffer is called, as you described in your original report? From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 15:17:17 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 19:17:18 +0000 Received: from localhost ([127.0.0.1]:48741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZRuv-0006cZ-LM for submit@debbugs.gnu.org; Tue, 29 May 2012 15:17:17 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:47602) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZRut-0006cN-GG for 11566@debbugs.gnu.org; Tue, 29 May 2012 15:17:16 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4TJFiZN020766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 19:15:45 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4TJFhuW019650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 19:15:44 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4TJFhiD014213; Tue, 29 May 2012 14:15:43 -0500 Received: from dradamslap1 (/10.159.177.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 12:15:42 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <83aa0r2dy8.fsf@gnu.org> <83zk8r0wan.fsf@gnu.org> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Tue, 29 May 2012 12:15:26 -0700 Message-ID: <47A37270DECE4F1090B3C600AD3EA768@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83zk8r0wan.fsf@gnu.org> Thread-Index: Ac09uqVLvZx0WTpJQaS45oUq6Im7SgAD6KXg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > However, in the interests of clarity, could you please describe the > bug again, in terms of which frame has focus (i.e. is the "foreground" > window), which is at the top of Z-order, and which has its border > highlighted, after read-from-minibuffer is called, as you described in > your original report? When `dired-mark-pop-up' calls `dired-pop-to-buffer' (inside a `save-window-excursion', a new frame is created (to show the *Marked Files*). The new frame gets the input focus, and its border is highlighted. Can't tell about the stacking order, since my standalone minibuffer frame does not overlap it. Then when `dired-mark-pop-up' calls `read-from-minibuffer' immediately thereafter, the input focus remains where it was, and likewise the border highlighting. `read-from-minibuffer' usually gives the minibuffer frame the input focus (and border highlighting - but I really don't care about that). But in this case, i.e., immediately following the new-frame creation, it does not. HTH. From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 15:17:42 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 19:17:42 +0000 Received: from localhost ([127.0.0.1]:48744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZRvK-0006dF-1c for submit@debbugs.gnu.org; Tue, 29 May 2012 15:17:42 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:47814) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZRvH-0006d2-B4 for 11566@debbugs.gnu.org; Tue, 29 May 2012 15:17:40 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4TJG8dZ021282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 19:16:09 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4TJG8le003219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 19:16:08 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4TJG7LR014491; Tue, 29 May 2012 14:16:07 -0500 Received: from dradamslap1 (/10.159.177.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 12:16:07 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <96A3CCDD100E49C6ACF2739484C9239A@us.oracle.com> <838vgb2dr1.fsf@gnu.org> <9A9A32EAE9D64B438EDA74E1F3F488FE@us.oracle.com> <831um32azg.fsf@gnu.org> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Tue, 29 May 2012 12:15:51 -0700 Message-ID: <4AFBBDB704B34BB18E08E02CE02AD58B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <831um32azg.fsf@gnu.org> Thread-Index: Ac09ukoZUI3p0qApR9awpBxE4W8yQAADx1sw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > In something like `select-frame-set-input-focus', my > > interpretation was that frame selection was related to the > > border highlighting and setting input focus > > was related to receiving keyboard input. AFAIK, > > `select-frame' does the former, but `select-frame-set-input-focus' > > is needed to get the latter. > > On Windows, at least with the default setup, selecting a frame also > grabs focus. So these two functions do the same. No, definitely not with my (non-default) setup. Selecting a frame does not give it the input focus. Hence my need to call `select-frame-set-input-focus' in a few places. And, I would guess, hence the existence of two different functions: `select-frame' and `s-f-s-i-f'. I'm no expert on any of this, obviously. I added `s-f-s-i-f' long ago where I found I needed it - `select-frame' was not sufficient. > > So IIUC, `select-frame-set-input-focus' does `select-frame' plus > > `redirect-frame-focus'? > > No, it just raises the frame after selecting it and makes sure it has > focus (which in most situations it will have by virtue of being > raised). But see above. From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 15:49:08 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 19:49:08 +0000 Received: from localhost ([127.0.0.1]:48769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZSPk-0007Kx-BO for submit@debbugs.gnu.org; Tue, 29 May 2012 15:49:08 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:61957) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZSPO-0007Jk-3V for 11566@debbugs.gnu.org; Tue, 29 May 2012 15:49:05 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4S00400URHXW00@a-mtaout20.012.net.il> for 11566@debbugs.gnu.org; Tue, 29 May 2012 22:47:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4S004H2UYQQV50@a-mtaout20.012.net.il>; Tue, 29 May 2012 22:47:14 +0300 (IDT) Date: Tue, 29 May 2012 22:47:21 +0300 From: Eli Zaretskii Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? In-reply-to: <4AFBBDB704B34BB18E08E02CE02AD58B@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83y5oa22ie.fsf@gnu.org> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <96A3CCDD100E49C6ACF2739484C9239A@us.oracle.com> <838vgb2dr1.fsf@gnu.org> <9A9A32EAE9D64B438EDA74E1F3F488FE@us.oracle.com> <831um32azg.fsf@gnu.org> <4AFBBDB704B34BB18E08E02CE02AD58B@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <11566@debbugs.gnu.org> > Date: Tue, 29 May 2012 12:15:51 -0700 > > > > In something like `select-frame-set-input-focus', my > > > interpretation was that frame selection was related to the > > > border highlighting and setting input focus > > > was related to receiving keyboard input. AFAIK, > > > `select-frame' does the former, but `select-frame-set-input-focus' > > > is needed to get the latter. > > > > On Windows, at least with the default setup, selecting a frame also > > grabs focus. So these two functions do the same. > > No, definitely not with my (non-default) setup. Selecting a frame does not give > it the input focus. Not even in "emacs -Q"? IOW, is this an Emacs setup issue, or a Windows setup issue? > Hence my need to call `select-frame-set-input-focus' in a few places. And, I > would guess, hence the existence of two different functions: `select-frame' and > `s-f-s-i-f'. My guess is that they exist because on X the situation is quite different: X defaults (or at least used to) to "pointer to focus", not "click to focus". > I'm no expert on any of this, obviously. Unfortunately, neither am I. I just read a bit about this for the last few days, because apparently no one else wanted to work on bug #11513. From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 16:21:37 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 20:21:37 +0000 Received: from localhost ([127.0.0.1]:48806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZSvA-00083r-Jh for submit@debbugs.gnu.org; Tue, 29 May 2012 16:21:36 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:38185) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZSv7-00083d-At for 11566@debbugs.gnu.org; Tue, 29 May 2012 16:21:34 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M4S00500W797400@a-mtaout20.012.net.il> for 11566@debbugs.gnu.org; Tue, 29 May 2012 23:20:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4S004TJWHCQVB0@a-mtaout20.012.net.il>; Tue, 29 May 2012 23:20:00 +0300 (IDT) Date: Tue, 29 May 2012 23:20:07 +0300 From: Eli Zaretskii Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? In-reply-to: <47A37270DECE4F1090B3C600AD3EA768@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83wr3u20zs.fsf@gnu.org> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <83aa0r2dy8.fsf@gnu.org> <83zk8r0wan.fsf@gnu.org> <47A37270DECE4F1090B3C600AD3EA768@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <11566@debbugs.gnu.org> > Date: Tue, 29 May 2012 12:15:26 -0700 > > When `dired-mark-pop-up' calls `dired-pop-to-buffer' (inside a > `save-window-excursion', a new frame is created (to show the *Marked Files*). > > The new frame gets the input focus, and its border is highlighted. Can't tell > about the stacking order, since my standalone minibuffer frame does not overlap > it. This part is clear, but would it be possible for you to arrange the windows so that the stacking order is also apparent? > Then when `dired-mark-pop-up' calls `read-from-minibuffer' immediately > thereafter, the input focus remains where it was, and likewise the border > highlighting. I understand that read-from-minibuffer pops up a minibuffer frame, or at least it should. Does that frame become the topmost in the stacking order after read-from-minibuffer is called, or does it stay below other windows, like it was before the call to read-from-minibuffer? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 16:30:19 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 20:30:19 +0000 Received: from localhost ([127.0.0.1]:48842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZT3Y-0008Hj-UX for submit@debbugs.gnu.org; Tue, 29 May 2012 16:30:19 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:21105) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZT3W-0008HV-5U for 11566@debbugs.gnu.org; Tue, 29 May 2012 16:30:15 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4TKSgvR026856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 20:28:43 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4TKSfXl017722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 20:28:41 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4TKSeCq030503; Tue, 29 May 2012 15:28:40 -0500 Received: from dradamslap1 (/10.159.177.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 13:28:40 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <96A3CCDD100E49C6ACF2739484C9239A@us.oracle.com> <838vgb2dr1.fsf@gnu.org> <9A9A32EAE9D64B438EDA74E1F3F488FE@us.oracle.com> <831um32azg.fsf@gnu.org> <4AFBBDB704B34BB18E08E02CE02AD58B@us.oracle.com> <83y5oa22ie.fsf@gnu.org> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Tue, 29 May 2012 13:28:24 -0700 Message-ID: <311006E0722F4F798C1F973A211FD1CB@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83y5oa22ie.fsf@gnu.org> Thread-Index: Ac0909qwl0PDSdo/SQC41YG8QFisoAABP5ew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > > On Windows, at least with the default setup, selecting a > > > frame also grabs focus. So these two functions do the same. > > > > No, definitely not with my (non-default) setup. Selecting > > a frame does not give it the input focus. > > Not even in "emacs -Q"? IOW, is this an Emacs setup issue, or a > Windows setup issue? I don't know what the test recipe would be. I don't know what it is for my setup either. All I know is that I have had to add calls to `select-frame-set-input-focus', and that `select-frame' did not do the trick. And I don't say that `select-frame' _never_ gives focus to the frame it selects. I'm saying only that in some situations I have had to use `s-f-s-i-p'. Typically, IIRC, this has been necessary when using the minibuffer, and, e.g. a key in the minibuffer map caused a new frame to be created or (correctly) caused some action to take place in another frame. In such situations I need to call `s-f-s-i-f' to the standalone minibuffer frame in order to continue with minibuffer input (e.g. completion). `select-frame' does not cut the mustard here. > > Hence my need to call `select-frame-set-input-focus' in a > > few places. And, I would guess, hence the existence of two > > different functions: `select-frame' and `s-f-s-i-f'. > > My guess is that they exist because on X the situation is quite > different: X defaults (or at least used to) to "pointer to focus", not > "click to focus". Could be. But as I say, `select-frame' did not seem to do the job, which is why I moved on to `s-f-s-i-f', which did. > > I'm no expert on any of this, obviously. > > Unfortunately, neither am I. I just read a bit about this for the > last few days, because apparently no one else wanted to work on bug > #11513. Thank you for your efforts. From debbugs-submit-bounces@debbugs.gnu.org Tue May 29 17:33:34 2012 Received: (at 11566) by debbugs.gnu.org; 29 May 2012 21:33:34 +0000 Received: from localhost ([127.0.0.1]:48879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZU2o-0001HE-66 for submit@debbugs.gnu.org; Tue, 29 May 2012 17:33:34 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:27913) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZU2l-0001H0-JO for 11566@debbugs.gnu.org; Tue, 29 May 2012 17:33:33 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4TLVxuP003604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 21:31:59 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4TLVwjJ016855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2012 21:31:58 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4TLVwLV002020; Tue, 29 May 2012 16:31:58 -0500 Received: from dradamslap1 (/10.159.177.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 14:31:57 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <83aa0r2dy8.fsf@gnu.org> <83zk8r0wan.fsf@gnu.org> <47A37270DECE4F1090B3C600AD3EA768@us.oracle.com> <83wr3u20zs.fsf@gnu.org> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Tue, 29 May 2012 14:31:39 -0700 Message-ID: <48D5DE31AB1D493F8F54655CEF962C08@us.oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BA_01CD3DA7.C3BF9D80" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83wr3u20zs.fsf@gnu.org> Thread-Index: Ac092G8cgrxjekJDTWGsiasu4RKK+wAAUHKg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) This is a multi-part message in MIME format. ------=_NextPart_000_00BA_01CD3DA7.C3BF9D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > The new frame gets the input focus, and its border is > > highlighted. Can't tell about the stacking order, > > since my standalone minibuffer frame does not overlap it. > > This part is clear, but would it be possible for you to arrange the > windows so that the stacking order is also apparent? OK, I've done that. A couple of things to say, but I'm not sure this will make things clearer. In some cases, the new frame does not take the input focus. In the case I was reporting, it does. Unfortunately, the code to reproduce this would be too much to ask others to load etc. What I can say about the stacking order is this: Regardless of which frame gets the input focus, the minibuffer frame is on top (foremost, most raised). And any echoing to the echo area also moves it to the top (regardless of where the input focus is). Being on top, having the input focus, and having the borders highlighted all seem to be independent (not necessarily coupled). > > Then when `dired-mark-pop-up' calls `read-from-minibuffer' > > immediately thereafter, the input focus remains where it > > was, and likewise the border highlighting. > > I understand that read-from-minibuffer pops up a minibuffer frame, or > at least it should. Not quite. With a standalone minibuffer frame, the frame is not popped up - it is always there. But yes, the minibuffer becomes active/inactive (there just is no "popping up"). > Does that frame become the topmost in the > stacking order after read-from-minibuffer is called, or does it stay > below other windows, like it was before the call to > read-from-minibuffer? I believe now that any activation of the minibuffer, and even any use of the echo area, raises the minibuffer frame to the front. HTH. Sorry it would be so difficult to enable you to reproduce the problem - you would need to load a few libraries etc. What I can say about it is this: If I mark some files in Dired and do `M' (`dired-do-chmod') to change their mode, then the *Marked Files* frame is popped up, but the minibuffer frame retains the focus when the chmod value is read (and is on top). But if I mark some files and a subdir, and I use my command `diredp-do-chmod-recursive', then things are different. This is like `dired-do-chmod' but it acts on all of the files that are marked, plus all of the files that are marked in any Dired buffers for marked subdirs, recursively. Then it does what `M' does on that list of files. But before popping up `*Marked Files*' etc. it (1) asks you for confirmation of the recursive operation and then, (2) if there are such Dired buffers for marked subdirs (recursively), asks you whether to use them. (The alternative here is to act on all files of the marked subdirs, determined recursively.) After you answer these questions, `*Marked Files*' is popped up and you are asked for the chmod value (e.g. `go+w'). It is for that last input reading that the problem arises: the input focus is in the *Marked Files* frame. This is the call to `read-from-minibuffer' that comes from `dired-mark-pop-up' just after it called `dired-pop-to-buffer' to pop up `*Marked Files*'. But this is the same code sequence that occurs for `M' - AFAICT the only difference is the existence of the two preliminary questions. So it's not clear to me where the problem comes from. This is the calling sequence: dired-do-chmod OR diredp-do-chmod-recursive > dired-mark-read-string > dired-mark-pop-up > dired-pop-to-buffer > make-frame, then read-from-minibuffer (via FUNCTION arg) The code for `dired-do-chmod' and `diredp-do-chmod-recursive' is nearly identical - see attachment. The only difference is the gathering of the list of files (which includes the preliminary confirmation questions). ------=_NextPart_000_00BA_01CD3DA7.C3BF9D80 Content-Type: application/octet-stream; name="throw-chmod-vs-chmod-rec.el" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="throw-chmod-vs-chmod-rec.el" ;; Vanilla Emacs `dired-do-chmod':=0A= =0A= (defun dired-do-chmod (&optional arg)=0A= "Change the mode of the marked (or next ARG) files.=0A= Symbolic modes like `g+w' are allowed."=0A= (interactive "P")=0A= (let* ((files (dired-get-marked-files t arg))=0A= (modestr (and (stringp (car files))=0A= (nth 8 (file-attributes (car files)))))=0A= (default=0A= (and (stringp modestr)=0A= (string-match "^.\\(...\\)\\(...\\)\\(...\\)$" modestr)=0A= (replace-regexp-in-string=0A= "-" ""=0A= (format "u=3D%s,g=3D%s,o=3D%s"=0A= (match-string 1 modestr)=0A= (match-string 2 modestr)=0A= (match-string 3 modestr)))))=0A= (modes (dired-mark-read-string=0A= "Change mode of %s to: "=0A= nil 'chmod arg files default))=0A= num-modes)=0A= (cond ((equal modes "")=0A= ;; We used to treat empty input as DEFAULT, but that is not=0A= ;; such a good idea (Bug#9361).=0A= (error "No file mode specified"))=0A= ((string-match "^[0-7]+" modes)=0A= (setq num-modes (string-to-number modes 8))))=0A= =0A= (dolist (file files)=0A= (set-file-modes=0A= file=0A= (if num-modes num-modes=0A= (file-modes-symbolic-to-number modes (file-modes file)))))=0A= (dired-do-redisplay arg)))=0A= =0A= =0A= ;; `diredp-do-chmod-recursive':=0A= (defun diredp-do-chmod-recursive (&optional ignore-marks-p) ; Bound to = `M-+ M'=0A= "Change the mode of the marked files, including those in marked = subdirs.=0A= Symbolic modes like `g+w' are allowed.=0A= Note that marked subdirs are not changed. Their markings are used=0A= only to indicate that some of their files are to be changed."=0A= (interactive (progn (diredp-get-confirmation-recursive)=0A= (list current-prefix-arg)))=0A= (let* ((files (diredp-get-files ignore-marks-p))=0A= (modestr (and (stringp (car files))=0A= (nth 8 (file-attributes (car files)))))=0A= (default (and (stringp modestr)=0A= (string-match "^.\\(...\\)\\(...\\)\\(...\\)$" = modestr)=0A= (replace-regexp-in-string "-" "" (format = "u=3D%s,g=3D%s,o=3D%s"=0A= = (match-string 1 modestr)=0A= = (match-string 2 modestr)=0A= = (match-string 3 modestr)))))=0A= (modes (dired-mark-read-string "Change mode of marked files = here and below to: "=0A= nil 'chmod nil files = default)))=0A= (when (equal modes "") (error "No file mode specified"))=0A= (dolist (file files)=0A= (set-file-modes file (or (and (string-match "^[0-7]+" modes)=0A= (string-to-number modes 8))=0A= (file-modes-symbolic-to-number modes = (file-modes file)))))=0A= (diredp-do-redisplay-recursive 'MSGP)))=0A= =0A= ;; For the code for `diredp-get-confirmation-recursive' and = `diredp-get-files', see here:=0A= ;; http://www.emacswiki.org/emacs/download/dired%2b.el=0A= ------=_NextPart_000_00BA_01CD3DA7.C3BF9D80-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 30 14:44:39 2012 Received: (at 11566) by debbugs.gnu.org; 30 May 2012 18:44:39 +0000 Received: from localhost ([127.0.0.1]:50724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZnss-0000WR-IT for submit@debbugs.gnu.org; Wed, 30 May 2012 14:44:38 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:33418) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZnsq-0000WC-4g for 11566@debbugs.gnu.org; Wed, 30 May 2012 14:44:37 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M4U00K00MGPPT00@a-mtaout22.012.net.il> for 11566@debbugs.gnu.org; Wed, 30 May 2012 21:42:58 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4U00KVGMNL70B0@a-mtaout22.012.net.il>; Wed, 30 May 2012 21:42:58 +0300 (IDT) Date: Wed, 30 May 2012 21:43:07 +0300 From: Eli Zaretskii Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? In-reply-to: <48D5DE31AB1D493F8F54655CEF962C08@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83lik91pdw.fsf@gnu.org> References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <83aa0r2dy8.fsf@gnu.org> <83zk8r0wan.fsf@gnu.org> <47A37270DECE4F1090B3C600AD3EA768@us.oracle.com> <83wr3u20zs.fsf@gnu.org> <48D5DE31AB1D493F8F54655CEF962C08@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , <11566@debbugs.gnu.org> > Date: Tue, 29 May 2012 14:31:39 -0700 > > Being on top, having the input focus, and having the borders highlighted all > seem to be independent (not necessarily coupled). Yes, that's true. > After you answer these questions, `*Marked Files*' is popped up and you are > asked for the chmod value (e.g. `go+w'). It is for that last input reading that > the problem arises: the input focus is in the *Marked Files* frame. Is the input focus there, or does the input you type arrive at that frame (instead of the minibuffer frame)? As we established, the frame that has focus and the frame that gets the input can be different frames, thanks to redirect-frame-focus. I see in the code that read-from-minibuffer (or, rather, one of its subroutines) does the equivalent of the following: (if minibuffer-auto-raise (raise-frame minibuffer-frame)) ... (or (eq (selected-frame) minibuffer-frame) (redirect-frame-focus minibuffer-frame)) Does your setup have minibuffer-auto-raise set to a non-nil value? If not, can you see if setting it non-nil fixes the problem? (I'm not saying that this should be the fix, I'm just trying to figure out which part(s) of read-from-minibuffer fail to do their job.) From debbugs-submit-bounces@debbugs.gnu.org Wed May 30 16:12:23 2012 Received: (at 11566) by debbugs.gnu.org; 30 May 2012 20:12:23 +0000 Received: from localhost ([127.0.0.1]:50767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZpFn-00041q-8L for submit@debbugs.gnu.org; Wed, 30 May 2012 16:12:23 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:24891) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SZpFT-000411-H7 for 11566@debbugs.gnu.org; Wed, 30 May 2012 16:12:22 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4UKAQe9020486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 May 2012 20:10:27 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q4UKAPL1020870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2012 20:10:26 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4UKAPV2006059; Wed, 30 May 2012 15:10:25 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 May 2012 13:10:25 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> <4FC22A8D.6040801@gmx.at> <8D43F91B0096402A9BCA59FE13513358@us.oracle.com> <4FC49A24.7000403@gmx.at> <83aa0r2dy8.fsf@gnu.org> <83zk8r0wan.fsf@gnu.org> <47A37270DECE4F1090B3C600AD3EA768@us.oracle.com> <83wr3u20zs.fsf@gnu.org> <48D5DE31AB1D493F8F54655CEF962C08@us.oracle.com> <83lik91pdw.fsf@gnu.org> Subject: RE: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Date: Wed, 30 May 2012 13:10:23 -0700 Message-ID: <2119F94EE39441F2B4284D4CA2F836C1@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83lik91pdw.fsf@gnu.org> Thread-Index: Ac0+lAq/asn6mH4aS6SgUStzxk9EagACydgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11566 Cc: rudalics@gmx.at, 11566@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > After you answer these questions, `*Marked Files*' is > > popped up and you are asked for the chmod value (e.g. `go+w'). > > It is for that last input reading that the problem arises: > > the input focus is in the *Marked Files* frame. > > Is the input focus there, or does the input you type arrive at that > frame (instead of the minibuffer frame)? As we established, the frame > that has focus and the frame that gets the input can be different > frames, thanks to redirect-frame-focus. Guess I'm still not clear on the difference. I thought that they were the same. What I see is that the minibuffer receives no input - that's the problem. The input you type goes to the other frame. How to know which frame has the input focus if it is not the frame that receives the input you type? > Does your setup have minibuffer-auto-raise set to a non-nil value? It is t. I think that is probably typical for someone who uses a standalone minibuffer frame, but I don't know. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 03 05:14:30 2012 Received: (at 11566-done) by debbugs.gnu.org; 3 Oct 2012 09:14:30 +0000 Received: from localhost ([127.0.0.1]:38620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL2E-0001qs-CM for submit@debbugs.gnu.org; Wed, 03 Oct 2012 05:14:30 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:51761) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TJL2C-0001ql-2r for 11566-done@debbugs.gnu.org; Wed, 03 Oct 2012 05:14:28 -0400 Received: (qmail invoked by alias); 03 Oct 2012 09:13:50 -0000 Received: from 62-47-56-28.adsl.highway.telekom.at (EHLO [62.47.56.28]) [62.47.56.28] by mail.gmx.net (mp020) with SMTP; 03 Oct 2012 11:13:50 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19KatYdhbZKtvu7BjcLtZDOlA5klnDn/pLaTYAEzF 5DpvPWgnuxOOzd Message-ID: <506C01D7.8040002@gmx.at> Date: Wed, 03 Oct 2012 11:13:59 +0200 From: martin rudalics MIME-Version: 1.0 To: 11566-done@debbugs.gnu.org Subject: Re: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? References: <6A40227DCFBF427491B710A473E45744@us.oracle.com> In-Reply-To: <6A40227DCFBF427491B710A473E45744@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 11566-done Cc: Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > 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*). Closing the bug since the behavior should have changed with the latest changes in `dired-mark-pop-up'. Feel free to reopen this if it's not fixed yet. martin From unknown Fri Jun 20 07:23:28 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 31 Oct 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator