From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: 11566@debbugs.gnu.org
Subject: bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?
Date: Tue, 29 May 2012 14:31:39 -0700 [thread overview]
Message-ID: <48D5DE31AB1D493F8F54655CEF962C08@us.oracle.com> (raw)
In-Reply-To: <83wr3u20zs.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3756 bytes --]
> > 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).
[-- Attachment #2: throw-chmod-vs-chmod-rec.el --]
[-- Type: application/octet-stream, Size: 2955 bytes --]
;; Vanilla Emacs `dired-do-chmod':
(defun dired-do-chmod (&optional arg)
"Change the mode of the marked (or next ARG) files.
Symbolic modes like `g+w' are allowed."
(interactive "P")
(let* ((files (dired-get-marked-files t arg))
(modestr (and (stringp (car files))
(nth 8 (file-attributes (car files)))))
(default
(and (stringp modestr)
(string-match "^.\\(...\\)\\(...\\)\\(...\\)$" modestr)
(replace-regexp-in-string
"-" ""
(format "u=%s,g=%s,o=%s"
(match-string 1 modestr)
(match-string 2 modestr)
(match-string 3 modestr)))))
(modes (dired-mark-read-string
"Change mode of %s to: "
nil 'chmod arg files default))
num-modes)
(cond ((equal modes "")
;; We used to treat empty input as DEFAULT, but that is not
;; such a good idea (Bug#9361).
(error "No file mode specified"))
((string-match "^[0-7]+" modes)
(setq num-modes (string-to-number modes 8))))
(dolist (file files)
(set-file-modes
file
(if num-modes num-modes
(file-modes-symbolic-to-number modes (file-modes file)))))
(dired-do-redisplay arg)))
;; `diredp-do-chmod-recursive':
(defun diredp-do-chmod-recursive (&optional ignore-marks-p) ; Bound to `M-+ M'
"Change the mode of the marked files, including those in marked subdirs.
Symbolic modes like `g+w' are allowed.
Note that marked subdirs are not changed. Their markings are used
only to indicate that some of their files are to be changed."
(interactive (progn (diredp-get-confirmation-recursive)
(list current-prefix-arg)))
(let* ((files (diredp-get-files ignore-marks-p))
(modestr (and (stringp (car files))
(nth 8 (file-attributes (car files)))))
(default (and (stringp modestr)
(string-match "^.\\(...\\)\\(...\\)\\(...\\)$" modestr)
(replace-regexp-in-string "-" "" (format "u=%s,g=%s,o=%s"
(match-string 1 modestr)
(match-string 2 modestr)
(match-string 3 modestr)))))
(modes (dired-mark-read-string "Change mode of marked files here and below to: "
nil 'chmod nil files default)))
(when (equal modes "") (error "No file mode specified"))
(dolist (file files)
(set-file-modes file (or (and (string-match "^[0-7]+" modes)
(string-to-number modes 8))
(file-modes-symbolic-to-number modes (file-modes file)))))
(diredp-do-redisplay-recursive 'MSGP)))
;; For the code for `diredp-get-confirmation-recursive' and `diredp-get-files', see here:
;; http://www.emacswiki.org/emacs/download/dired%2b.el
next prev parent reply other threads:[~2012-05-29 21:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-27 0:07 bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame? Drew Adams
2012-05-27 13:22 ` martin rudalics
2012-05-27 15:01 ` Drew Adams
2012-05-29 9:43 ` martin rudalics
2012-05-29 14:12 ` Drew Adams
2012-05-29 15:44 ` Eli Zaretskii
2012-05-29 16:10 ` Drew Adams
2012-05-29 16:44 ` Eli Zaretskii
2012-05-29 19:15 ` Drew Adams
2012-05-29 19:47 ` Eli Zaretskii
2012-05-29 20:28 ` Drew Adams
2012-05-29 15:40 ` Eli Zaretskii
2012-05-29 16:10 ` Drew Adams
2012-05-29 16:46 ` Eli Zaretskii
2012-05-29 19:15 ` Drew Adams
2012-05-29 20:20 ` Eli Zaretskii
2012-05-29 21:31 ` Drew Adams [this message]
2012-05-30 18:43 ` Eli Zaretskii
2012-05-30 20:10 ` Drew Adams
2012-05-28 18:02 ` Drew Adams
2012-10-03 9:13 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48D5DE31AB1D493F8F54655CEF962C08@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=11566@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.