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: Tue, 29 May 2012 14:31:39 -0700 Message-ID: <48D5DE31AB1D493F8F54655CEF962C08@us.oracle.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BA_01CD3DA7.C3BF9D80" X-Trace: dough.gmane.org 1338327171 9165 80.91.229.3 (29 May 2012 21:32:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 May 2012 21:32:51 +0000 (UTC) Cc: 11566@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 29 23:32:47 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 1SZU1z-0001hi-BI for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 May 2012 23:32:43 +0200 Original-Received: from localhost ([::1]:55878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZU1z-0003i8-04 for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 May 2012 17:32:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZU1v-0003hs-1z for bug-gnu-emacs@gnu.org; Tue, 29 May 2012 17:32:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SZU1t-0006Km-0p for bug-gnu-emacs@gnu.org; Tue, 29 May 2012 17:32:38 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZU1s-0006Ki-Tz for bug-gnu-emacs@gnu.org; Tue, 29 May 2012 17:32:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SZU3F-0001IK-Kn for bug-gnu-emacs@gnu.org; Tue, 29 May 2012 17:34:01 -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: Tue, 29 May 2012 21:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11566 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11566-submit@debbugs.gnu.org id=B11566.13383272144920 (code B ref 11566); Tue, 29 May 2012 21:34:01 +0000 Original-Received: (at 11566) by debbugs.gnu.org; 29 May 2012 21:33:34 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 Original-Received: from dradamslap1 (/10.159.177.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 May 2012 14:31:57 -0700 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-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:60485 Archived-At: 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--