bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

[Drew Adams]

> > 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).

throw-chmod-vs-chmod-rec.el
Description: Binary data