bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

This is part of the ongoing saga of trying to get Emacs to DTRT with
buffers popped up only to serve as info while Emacs asks a question
requiring a response.
 
IF you use a standalone minibuffer frame, AND the popped up buffer is
special-display (e.g. because of `special-display-regexps'), AND you are
on MS Windows (which automatically shifts the focus to a new frame that
it creates), THEN:
 
1. When you try to exit Emacs with active processes, Emacs pops up a new
frame for buffer `*Process List*' and asks you about killing them.
 
2. But the minibuffer frame no longer has the focus!  So when you type
your answer (e.g. "yes") Emacs tries to insert it as text in buffer
`*Process List*'.  Poor Emacs.
 
Please do something to fix this.  For inspiration, perhaps look to
`dired-mark-pop-up' which does something similar but gets it right.  See
perhaps `dired-pop-to-buffer'.
 
Better would be to fix this ask-for-input-after-popping-up-some-info
problem generally, obviously.  But a fix for just this particular
query will be better than nothing.

At least Dired DTRT now wrt focus - that's already something.

Of course, for Dired I still have to modify `dired-mark-pop-up' anyway, to have
it delete the window or frame popped up, afterward, and bury its buffer.  See
bug #7533 - a patch was provided for this but AFAIK Emacs Dev has never applied
it.

In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --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'
 

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

 > IF you use a standalone minibuffer frame, AND the popped up buffer is
 > special-display (e.g. because of `special-display-regexps'), AND you are
 > on MS Windows (which automatically shifts the focus to a new frame that
 > it creates), THEN:
 >
 > 1. When you try to exit Emacs with active processes, Emacs pops up a new
 > frame for buffer `*Process List*' and asks you about killing them.
 >
 > 2. But the minibuffer frame no longer has the focus!  So when you type
 > your answer (e.g. "yes") Emacs tries to insert it as text in buffer
 > `*Process List*'.  Poor Emacs.

What is your value of `minibuffer-auto-raise'?  Maybe `yes-or-no-p'
should do `select-frame-set-input-focus' in your case.  What happens
usually when you ask a `yes-or-no-p' question in a non-minibuffer frame?

 > Please do something to fix this.

I'm afraid, most people here can't reproduce your problem.  We probably
have to invent some new option to handle it.  In any case, we'd have to
investigate the underlying problem.

 > For inspiration, perhaps look to
 > `dired-mark-pop-up' which does something similar but gets it right.  See
 > perhaps `dired-pop-to-buffer'.
 >
 > Better would be to fix this ask-for-input-after-popping-up-some-info
 > problem generally, obviously.  But a fix for just this particular
 > query will be better than nothing.
 >
 > At least Dired DTRT now wrt focus - that's already something.
 >
 > Of course, for Dired I still have to modify `dired-mark-pop-up' anyway, to have
 > it delete the window or frame popped up, afterward, and bury its buffer.  See
 > bug #7533 - a patch was provided for this but AFAIK Emacs Dev has never applied
 > it.

Try to load the attached file and tell me which problems you see.

Thanks, martin

[-- Attachment #2: with-temp-buffer-window.el --]
[-- Type: application/emacs-lisp, Size: 21143 bytes --]

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

Thanks for looking at this, Martin.

> What is your value of `minibuffer-auto-raise'?

It is `t'.

> Maybe `yes-or-no-p'
> should do `select-frame-set-input-focus' in your case.  What happens
> usually when you ask a `yes-or-no-p' question in a 
> non-minibuffer frame?

No problem.  The typed answer (yes/no) is inserted in the minibuffer, as
expected.  E.g., I type this in a buffer/frame foo.el, and then use C-x C-e to
evaluate it:

(yes-or-no-p "Really? ")

I type "yes" and it appears in the minibuffer frame.  All is fine.

In the problematic contexts, a new frame is popped up and given the focus (by MS
Windows).  That is apparently somehow different from starting from a frame that
already has the focus.

If I had to guess blindly, I'd guess that it has to do with the
timing/sequencing of things: Maybe in the problematic case the question is FIRST
posed in the minibuffer/echo area (giving the minibuffer frame focus) and THEN
the new frame is popped up and it gets the focus.

Whereas maybe in the case I just tested the focus never comes back to the frame
that originally had it - once the focus goes to the minibuffer frame, there is
nothing that puts it back in the original frame.  Just a hunch.

If that is the case, maybe a fix (ugly hack) would be to do this: Whenever the
minibuffer frame has focus and some other frame is created, immediately return
focus to the minibuffer frame.  (Dunno _how_ that might be done.)

>  > Please do something to fix this.
> 
> I'm afraid, most people here can't reproduce your problem.  
> We probably have to invent some new option to handle it.
> In any case, we'd have to investigate the underlying problem.

Or perhaps look to what Dired does...

>  > For inspiration, perhaps look to `dired-mark-pop-up' which
>  > does something similar but gets it right.  See perhaps
>  > `dired-pop-to-buffer'.
>  >
>  > Better would be to fix this ask-for-input-after-popping-up-some-info
>  > problem generally, obviously.  But a fix for just this particular
>  > query will be better than nothing.
>  >
>  > At least Dired DTRT now wrt focus - that's already something.
>  >
>  > Of course, for Dired I still have to modify `dired-mark-pop-up'
>  > anyway, to have it delete the window or frame popped up, afterward,
>  > and bury its buffer.  See bug #7533 - a patch was provided for
>  > this but AFAIK Emacs Dev has never applied it.
> 
> Try to load the attached file and tell me which problems you see.

OK, thanks for trying seriously to solve this.  I know that you look into things
carefully.

1. FYI - I can test only with 24.1, not something later, since other bugs still
prevent my using the later Windows builds.  I'm still waiting for a build more
recent than 2012-07-02.  Dunno whether this matters here.

2. I tried to quit Emacs (C-x C-c) after creating a shell buffer (which is in a
dedicated window in a separate frame).

The informative buffer that lists the active processes was popped up correctly
in a separate frame as the yes-or-no question was asked.  But when I tried to
type yes or no, that typed input appeared nowhere.

I would guess, from the fact that Windows gives the new frame the input focus,
that that new frame had the focus and the input was trying to go there.  But
that buffer is created read-only and I saw no error message indicating that
Emacs was trying to insert the input (yes/no) into a read-only buffer.  No
feedback at all - it's as if my typed input was silently sent to /dev/null.
(That in itself is not good.)

In any case, what's important is that the typed input did not go to the
minibuffer frame.

C-g did not then exit the question, but C-] did.  But then, instead of the
process-list informative buffer and frame simply disappearing, that buffer was
replaced in its frame (which should have been temporary) by the buffer that was
current when I hit C-x C-c.

3. I marked 3 files in Dired and hit `C'.  When I tried to type the destination
directory I got an error saying that buffer *Marked Files* is read-only.  IOW,
the typed input was sent to that information buffer (in its popped up frame) and
not to the minibuffer frame.

Worse: just as above for the active processes popup, after canceling the copy
operation the *Marked Files* frame did not disappear.  Instead, the *Marked
Files* buffer was replaced in its frame by the Dired buffer.  So now I had two
frames with the Dired buffer, one of which was a special-display frame (which
has different frame parameters, e.g. colors).

I thought that the focus problem was already fixed for this in vanilla Emacs,
and that the patch I sent was needed only to take care of removing the frame and
burying the buffer.  But with the code you sent both problems are there.

In any case, if I then use the definition of `dired-mark-pop-up' that I provided
then the problems (both focus and removal) go away.  IOW, even after loading the
code you sent, all I need to do is evaluate this and the Dired dialog works
perfectly again:

;; REPLACE ORIGINAL in `dired.el':
;;
;; Delete the window or frame popped up, afterward, and bury its buffer.
;; Fixes Emacs bug #7533.
;;
(defun dired-mark-pop-up (bufname op-symbol files function &rest args)
  "Return FUNCTION's result on ARGS after showing which files are marked.
Displays the file names in a buffer named BUFNAME;
 nil gives \" *Marked Files*\".
This uses function `dired-pop-to-buffer' to do that.

FUNCTION should not manipulate files, just read input
 (an argument or confirmation).
The window is not shown if there is just one file or
 OP-SYMBOL is a member of the list in `dired-no-confirm'.
FILES is the list of marked files.  It can also be (t FILENAME)
in the case of one marked file, to distinguish that from using
just the current file."
  (or bufname (setq bufname  " *Marked Files*"))
  (let (result)
    (if (or (eq dired-no-confirm t)
            (memq op-symbol dired-no-confirm)
            ;; If FILES defaulted to the current line's file.
            (= (length files) 1))
        (setq result  (apply function args))
      (with-current-buffer (get-buffer-create bufname)
        (erase-buffer)
        ;; Handle (t FILE) just like (FILE), here.
        ;; That value is used (only in some cases), to mean
        ;; just one file that was marked, rather than the current line file.
        (dired-format-columns-of-files (if (eq (car files) t) (cdr files)
files))
        (remove-text-properties (point-min) (point-max)
                                '(mouse-face nil help-echo nil)))
      (unwind-protect
           (save-window-excursion
             (dired-pop-to-buffer bufname)
             (setq result  (apply function args)))
        (save-excursion
          (condition-case nil           ; Ignore error if user already deleted
window.
              (progn
                (select-window (get-buffer-window bufname 0))
                (if (one-window-p) (delete-frame) (delete-window)))
            (error nil)))
        (bury-buffer bufname)))
    result))

I thought that the patch I sent for this was going to be applied to Emacs - but
it never was.  I use this code everyday, with no problem.  But the dialog is
still broken in vanilla Emacs.


Thanks for working on this, Martin.  It would be great if this problem could be
fixed in general (i.e., beyond just Dired).

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > In the problematic contexts, a new frame is popped up and given the focus (by MS
 > Windows).  That is apparently somehow different from starting from a frame that
 > already has the focus.

OK.  What happens if in in `yes-or-no-p' you use

                     (when minibuffer-auto-raise
                       (select-frame-set-input-focus
		       (window-frame (minibuffer-window))))

instead of `raise-frame'?

 > If I had to guess blindly, I'd guess that it has to do with the
 > timing/sequencing of things: Maybe in the problematic case the question is FIRST
 > posed in the minibuffer/echo area (giving the minibuffer frame focus) and THEN
 > the new frame is popped up and it gets the focus.

I suppose `handle-switch-frame' is called after the `yes-or-no-p'.  Then
even the `select-frame-set-input-focus' would not help.

 > Whereas maybe in the case I just tested the focus never comes back to the frame
 > that originally had it - once the focus goes to the minibuffer frame, there is
 > nothing that puts it back in the original frame.  Just a hunch.
 >
 > If that is the case, maybe a fix (ugly hack) would be to do this: Whenever the
 > minibuffer frame has focus and some other frame is created, immediately return
 > focus to the minibuffer frame.  (Dunno _how_ that might be done.)

What happens if in `with-temp-buffer-window' you add a
`save-selected-window' around

        (with-current-buffer ,buffer
	 (setq ,value (progn ,@body))
	 (setq ,window (temp-buffer-window-show ,buffer)))

 > Or perhaps look to what Dired does...

Dired uses a `save-window-excursion' which doesn't deal with the frame
but restores the selected window - maybe that's the reason.

 > 1. FYI - I can test only with 24.1, not something later, since other bugs still
 > prevent my using the later Windows builds.  I'm still waiting for a build more
 > recent than 2012-07-02.  Dunno whether this matters here.

What I sent should work with 24.1.

 > 2. I tried to quit Emacs (C-x C-c) after creating a shell buffer (which is in a
 > dedicated window in a separate frame).
 >
 > The informative buffer that lists the active processes was popped up correctly
 > in a separate frame as the yes-or-no question was asked.  But when I tried to
 > type yes or no, that typed input appeared nowhere.
 >
 > I would guess, from the fact that Windows gives the new frame the input focus,
 > that that new frame had the focus and the input was trying to go there.  But
 > that buffer is created read-only and I saw no error message indicating that
 > Emacs was trying to insert the input (yes/no) into a read-only buffer.  No
 > feedback at all - it's as if my typed input was silently sent to /dev/null.
 > (That in itself is not good.)
 >
 > In any case, what's important is that the typed input did not go to the
 > minibuffer frame.

Can you try with just `pop-up-frames' t, that is, disabling special
display buffers?

 > [...]
 > I thought that the patch I sent for this was going to be applied to Emacs - but
 > it never was.  I use this code everyday, with no problem.  But the dialog is
 > still broken in vanilla Emacs.

I understand your concerns.  But we have to first find out why your
system behaves differently and then try to find a general solution.

BTW, has bug#11566 been resolved meanwhile?

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> OK.  What happens if in in `yes-or-no-p' you use
>                      (when minibuffer-auto-raise
>                        (select-frame-set-input-focus
> 		       (window-frame (minibuffer-window))))
> instead of `raise-frame'?

Sorry, I don't understand.  `yes-or-no-p' is coded in C.  Where should I change
a call to raise-frame to instead use the above code?

> I suppose `handle-switch-frame' is called after the `yes-or-no-p'.
> Then even the `select-frame-set-input-focus' would not help.
> 
> What happens if in `with-temp-buffer-window' you add a
> `save-selected-window' around
>         (with-current-buffer ,buffer
> 	 (setq ,value (progn ,@body))
> 	 (setq ,window (temp-buffer-window-show ,buffer)))

I tried just that (nothing from above about modifying yes-or-no-p, since I don't
understand what you mean there).  It did not change anything:

C-x C-c still did nothing when I typed an answer to the prompt about active
processes.  And again, when I hit C-] the buffer that was current before C-x C-c
replaced the buffer that lists the active processes in its frame.

>  > Or perhaps look to what Dired does...
> 
> Dired uses a `save-window-excursion' which doesn't deal with the frame
> but restores the selected window - maybe that's the reason.
> 
> Can you try with just `pop-up-frames' t, that is, disabling special
> display buffers?

OK, I tried that: still using my setup, I set `special-display-regexps' to nil
then tried C-x C-c etc.

That changed nothing (except that the popped up buffer appeared in a regular
frame, not a special-display frame).  The symptoms were identical AFAICT: input
did not go to minibuffer, and quitting (C-]) left the frame but put the
originally current buffer in it, replacing the processes-list buffer there.

Oh, it also changed this: Now when I hit `q' in *Help*, instead of the frame
being removed I get another buffer in it, substituted for *Help*.  This in spite
of the fact that `special-display-buffer-names' has this entry, which should
make *Help* be dedicated:

("*Help*" 1on1-display-*Help*-frame
  ((background-color . "Thistle")
   (mouse-color . "Blue Violet")
   (cursor-color . "Blue Violet")
   (height . 40)))

Buffer *Help* is still popped up in a new frame that has those colors, but now
when I hit `q' in it the frame does not disappear and its buffer is changed.
That's not what I would call "dedicated" anymore.  Dunno if there is another bug
here.  HTH.

> I understand your concerns.  But we have to first find out why your
> system behaves differently and then try to find a general solution.

Agreed.

If someone on MS Windows were willing to try oneonone.el (and set
`special-display-regexps' to ("[ ]?[*][^*]+[*]")) then they would likely be able
to see the behavior for themselves.

(Dunno for sure whether other things in my setup are involved.  If someone is
really interested then we can pursue it.)

> BTW, has bug#11566 been resolved meanwhile?

Not at all (not that I know of/can tell).  The last message in that thread is
from me, and its questions were never answered.

My guess is that these bugs are related, if not the same underneath.

[BTW/FWIW, in #11566, there was some discussion of `select-frame' vs
`select-frame-set-input-focus.  I can confirm again that these definitely are
not the same, and the former is not sufficient in some cases, which is why I end
up calling the latter in some contexts.  I noted this mentally a while ago when
I encountered it again, since I recalled then that it had been suggested in that
thread that `select-frame' should be sufficient.]

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 >> OK.  What happens if in in `yes-or-no-p' you use
 >>                      (when minibuffer-auto-raise
 >>                        (select-frame-set-input-focus
 >> 		       (window-frame (minibuffer-window))))
 >> instead of `raise-frame'?
 >
 > Sorry, I don't understand.  `yes-or-no-p' is coded in C.  Where should I change
 > a call to raise-frame to instead use the above code?

Sorry.  Do

(defalias 'yes-or-no-p 'y-or-n-p)

and then try.

 > C-x C-c still did nothing when I typed an answer to the prompt about active
 > processes.  And again, when I hit C-]

... what command is C-] bound to?  I can't type it on my keyboard ...

 > the buffer that was current before C-x C-c
 > replaced the buffer that lists the active processes in its frame.
 >
 >>  > Or perhaps look to what Dired does...
 >>
 >> Dired uses a `save-window-excursion' which doesn't deal with the frame
 >> but restores the selected window - maybe that's the reason.
 >>
 >> Can you try with just `pop-up-frames' t, that is, disabling special
 >> display buffers?
 >
 > OK, I tried that: still using my setup, I set `special-display-regexps' to nil
 > then tried C-x C-c etc.
 >
 > That changed nothing (except that the popped up buffer appeared in a regular
 > frame, not a special-display frame).  The symptoms were identical AFAICT: input
 > did not go to minibuffer, and quitting (C-]) left the frame but put the
 > originally current buffer in it, replacing the processes-list buffer there.

But it does work with emacs -Q on your system, I suppose?  So the
problem seems that input doesn't get redirected to your minibuffer frame
when popping up a new minibuffer-less frame.

 > Oh, it also changed this: Now when I hit `q' in *Help*, instead of the frame
 > being removed I get another buffer in it, substituted for *Help*.  This in spite
 > of the fact that `special-display-buffer-names' has this entry, which should
 > make *Help* be dedicated:
 >
 > ("*Help*" 1on1-display-*Help*-frame
 >   ((background-color . "Thistle")
 >    (mouse-color . "Blue Violet")
 >    (cursor-color . "Blue Violet")
 >    (height . 40)))
 >
 > Buffer *Help* is still popped up in a new frame that has those colors, but now
 > when I hit `q' in it the frame does not disappear and its buffer is changed.
 > That's not what I would call "dedicated" anymore.  Dunno if there is another bug
 > here.  HTH.

That's hardly surprising: With `pop-up-frames' t you shouldn't get a
dedicated window, I suppose.

 > If someone on MS Windows were willing to try oneonone.el (and set
 > `special-display-regexps' to ("[ ]?[*][^*]+[*]")) then they would likely be able
 > to see the behavior for themselves.
 >
 > (Dunno for sure whether other things in my setup are involved.  If someone is
 > really interested then we can pursue it.)

Things would get simpler if you were able to supply a reasonably small
file to test this so we wouldn't always have to get through your entire
setup and completely lose our testing environments.  For me, debugging
and testing things with emacs -Q is already hard enough.

 >> BTW, has bug#11566 been resolved meanwhile?
 >
 > Not at all (not that I know of/can tell).  The last message in that thread is
 > from me, and its questions were never answered.

Then why do you suggest at the beginning of the current thread to

 >> "look to `dired-mark-pop-up' which does something similar but gets it right"

if it apparently doesn't get it right anyway?

 > My guess is that these bugs are related, if not the same underneath.
 >
 > [BTW/FWIW, in #11566, there was some discussion of `select-frame' vs
 > `select-frame-set-input-focus.  I can confirm again that these definitely are
 > not the same, and the former is not sufficient in some cases, which is why I end
 > up calling the latter in some contexts.  I noted this mentally a while ago when
 > I encountered it again, since I recalled then that it had been suggested in that
 > thread that `select-frame' should be sufficient.]

It would be fine if we were able to sketch the problem as follows: If a
user has a

(1) minibuffer-only frame and all other frames use that minibuffer and

(2) a `yes-or-no-p' or `read-from-minibuffer' prompt pops up in a
     separate frame

then `select-frame-set-input-focus' is needed to redirect input to that
minibuffer-only frame inorder to answer the question.  Can't you try to
provide a test example on this basis?  The Elisp manual doesn't help me
at all when I try doing that.  For example, if I want to know how to use
`set-minibuffer-window' for setting up the minibuffer-window to use for
a minibuffer-less frame, I'm completely lost.  If with emacs -Q I do

(let ((frame-1 (make-frame '((minibuffer . only))))
       (frame-2 (make-frame '((minibuffer . nil)))))
   (set-minibuffer-window (frame-root-window frame-1)))

then I still can't delete the initial frame because the
minibuffer-window for frame-2 is that of the initial frame.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

Hi Martin,

>  >> OK.  What happens if in in `yes-or-no-p' you use
>  >>                      (when minibuffer-auto-raise
>  >>                        (select-frame-set-input-focus
>  >> 		       (window-frame (minibuffer-window))))
>  >> instead of `raise-frame'?
>  >
>  > Sorry, I don't understand.  `yes-or-no-p' is coded in C.  
>  > Where should I change a call to raise-frame to instead use the above code?
> 
> Sorry.  Do (defalias 'yes-or-no-p 'y-or-n-p) and then try.

Are you sure you mean that?  AFAIK, `y-or-n-p' is not at all representative - it
does not even use the minibuffer, I think: it just reads events directly.  I
will try to do as you instruct, if you confirm, but I do not understand how
using `y-or-n-p' here can possibly help.

> ... what command is C-] bound to?  I can't type it on my keyboard ...

`abort-recursive-edit'.  `C-]' is the (only) default global binding (emacs -Q)
for `abort-recursive-edit'.

>  > OK, I tried that: still using my setup, I set 
>  > `special-display-regexps' to nil then tried C-x C-c etc.
>  >
>  > That changed nothing (except that the popped up buffer 
>  > appeared in a regular frame, not a special-display frame).
>  > The symptoms were identical AFAICT: input
>  > did not go to minibuffer, and quitting (C-]) left the 
>  > frame but put the originally current buffer in it, replacing the 
>  > processes-list buffer there.
> 
> But it does work with emacs -Q on your system, I suppose?

I'm not sure just what the test was to be here.  But I tried with emacs -Q (plus
loading cygwin-mount.el & setup-cygwin.el, so that I have a bash shell on
Windows).

I tried first with nil `pop-up-frames' - that behaved normally, i.e., as it
should.  I tried then with non-nil `pop-up-frames' - and that manifested the
same problem that I reported!  Good news!

So even *without* a standalone minibuffer and the rest of my setup, this bug is
reproducible.  Thanks for helping find that.  (Perhaps there are additional
problems, but we need not worry about those now, if any in fact exist.)

So that's great news.  A simple recipe:

1. On MS Windows (I'm using XP SP3).
(I hope someone on Windows will confirm and help.)

2. emacs -Q

3. Load cygwin-mount.el, then setup-cygwin.el (from Emacs Wiki's Elisp Area).

4. M-x set-variable pop-up-frames t

5. M-x shell

6. C-x C-c

The informative buffer *Process List* is popped up in a separate frame, which
apparently gets the focus.  The question about killing active processes appears
in the minibuffer of the original frame (which has only buffer *shell*).

Because the new frame has the focus, _you cannot answer the question_.  You are
forced to select the frame with the question (e.g. clicking mouse-1 on its title
bar), in order to answer it and exit Emacs.

A second bug (I think) is that there is NO feedback/response to your typing the
answer.  With focus in the *Process List* frame, which has a read-only buffer, I
would expect an error message saying that the buffer is read-only.  But you get
NO message - nada.  Not only that, but I see no such message in buffer
*Messages* if I look there.  Dunno why this is.

> So the problem seems that input doesn't get redirected to your 
> minibuffer frame when popping up a new minibuffer-less frame.

Seems to not depend on a standalone minibuffer frame, but yes, that seems to be
the problem.

Well, that's one problem, anyway.  Really, I do not want the new frame popped up
to have a minibuffer and pose the question about killing processes.  I want the
new frame to just be displayed and _not selected_ for input/output (user
interaction).  I do not want it to have a minibuffer.

More precisely, I don't have much of an opinion in the case of a non standalone
minibuffer.

But in the case of a standalone minibuffer, it definitely should continue to
have the input focus.  That's the point, for me.

It would not be a solution for me to give the new frame its own minibuffer or
something and to let it keep the input focus.  The user should be able to always
look to the same, standalone minibuffer - the *only* minibuffer area - for all
prompts and user replies.

>  > Oh, it also changed this: Now when I hit `q' in *Help*, 
>  > instead of the frame being removed I get another buffer in it,
>  > substituted for *Help*.  This in spite of the fact that
>  > `special-display-buffer-names' has this entry, which should
>  > make *Help* be dedicated:
>  >
>  > ("*Help*" 1on1-display-*Help*-frame
>  >   ((background-color . "Thistle")
>  >    (mouse-color . "Blue Violet")
>  >    (cursor-color . "Blue Violet")
>  >    (height . 40)))
>  >
>  > Buffer *Help* is still popped up in a new frame that has 
>  > those colors, but now when I hit `q' in it the frame does not
>  > disappear and its buffer is changed.  That's not what I would
>  > call "dedicated" anymore.
> 
> That's hardly surprising: With `pop-up-frames' t you shouldn't get a
> dedicated window, I suppose.

Uh, if you are saying what I think you are saying then I'm afraid I disagree
strongly about that.  To me, that would be a regression.

If a buffer is declared via `special-display-buffer-names' to be
special-display, then it _must be_ special-display.  That must not be violated
just because `pop-up-frames' might have some particular value.

I *hope* I am just misunderstanding you here - I hope you are not suggesting
that `special-display-buffer-names' is no longer enough to ensure that a buffer
is special-display.

>  >> BTW, has bug#11566 been resolved meanwhile?
>  >
>  > Not at all (not that I know of/can tell).  The last message in
>  > that thread is from me, and its questions were never answered.
> 
> Then why do you suggest at the beginning of the current thread to
> 
>  >> "look to `dired-mark-pop-up' which does something similar 
>  >> but gets it right"
> 
> if it apparently doesn't get it right anyway?

I'm sorry; I was probably confused in saying that.  I must have meant that it
works with the patch I sent, which (I thought) was applied to Emacs (or was
going to be applied).

If I use Dired+ (which does what my patch does) then there is no problem, so in
my daily use this is solved for the Dired but reported, but not in general (viz.
this bug wrt quitting with active processes).

> It would be fine if we were able to sketch the problem as 
> follows: If a user has a
> 
> (1) minibuffer-only frame and all other frames use that minibuffer and
> (2) a `yes-or-no-p' or `read-from-minibuffer' prompt pops up in a
>      separate frame
> 
> then `select-frame-set-input-focus' is needed to redirect 
> input to that minibuffer-only frame inorder to answer the question.

See above.  What you say might well be involved (i.e., be part of a solution),
but the problem (of this bug) is apparently present even without a standalone
minibuffer frame.

> Can't you try to provide a test example on this basis?

I don't know how.  I did suggest in the bug #11566 thread that perhaps
`read-from-minibuffer' could do something like that systematically, and I
thought briefly that I had found a general solution that way, but I soon
discovered that `message' then had no effect!  No messages were ever output if I
did that.

> The Elisp manual doesn't help me at all when I try doing that.
> For example, if I want to know how to use `set-minibuffer-window'
> for setting up the minibuffer-window to use for
> a minibuffer-less frame, I'm completely lost.

I'm sorry I can't help either, here.  I know less about this than you do -
especially wrt Emacs windows, for which you are the expert.

> If with emacs -Q I do
> (let ((frame-1 (make-frame '((minibuffer . only))))
>       (frame-2 (make-frame '((minibuffer . nil)))))
>    (set-minibuffer-window (frame-root-window frame-1)))
> 
> then I still can't delete the initial frame because the
> minibuffer-window for frame-2 is that of the initial frame.

Ah, there I can help, in a minimal way at least, by confirming.  I don't know
why, and I cannot really explain anything here, but yes:

If you want a standalone minibuffer frame to have the _only_ minibuffer then you
must do everything at load time, i.e., in .emacs.  That is why I have provided
bug-repro recipes in the past that used this:

 runemacs.exe -Q -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"

Command `1on1-emacs' must be run before the initial frame is created.
Otherwise, there will be a frame that has its own minibuffer, and you will never
be able to get rid of that frame (as you discovered).

IOW, it is too late to create your standalone minibuffer, once Emacs has already
created a frame with a normal minibuffer.  Whether this SHOULD be the case I
cannot answer, but it has always been the case with Gnu Emacs, AFAIK.

That is why I tell users of oneonone.el that they must do this:
  (require 'oneonone)
  (1on1-emacs)
rather than just invoke `1on1-emacs' after Emacs has already created its initial
frame, e.g., `M-x 1on1-emacs'.

With the simple reproducible test case above, we are making real progress.  I
hope we can finally find a solution to this problem.  My guess is that it lies
at the root of a majority of the problems I've had with GNU Emacs and frames -
problems that I have been trying to work around for decades.


FWIW:

Many Moon Ago, I used Epoch, which offered, out of the box, the ability to have
a standalone minibuffer frame (they did not call it that), which stretched
across the bottom of your display (by default).  (No customization necessary -
maybe you used a command switch when invoking the editor, I don't recall.)

I found that to be a wonderful, simple, reasonable way to interact with Emacs
(yes, Epoch was as much Emacs as GNU Emacs is).  And I tried to reproduce that
behavior in GNU Emacs.  I've come close, but this problem, in particular, has
always plagued me to some extent in my attempts.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 5112 bytes --]

 >> Sorry.  Do (defalias 'yes-or-no-p 'y-or-n-p) and then try.
 >
 > Are you sure you mean that?  AFAIK, `y-or-n-p' is not at all representative - it
 > does not even use the minibuffer, I think: it just reads events directly.  I
 > will try to do as you instruct, if you confirm, but I do not understand how
 > using `y-or-n-p' here can possibly help.

Because you can do `select-frame-set-input-focus' with it.

 >> ... what command is C-] bound to?  I can't type it on my keyboard ...
 >
 > `abort-recursive-edit'.  `C-]' is the (only) default global binding (emacs -Q)
 > for `abort-recursive-edit'.

My keyboard doesn't allow me to input things like C-] easily so I don't
know what these do.

 >> But it does work with emacs -Q on your system, I suppose?
 >
 > I'm not sure just what the test was to be here.  But I tried with emacs -Q (plus
 > loading cygwin-mount.el & setup-cygwin.el, so that I have a bash shell on
 > Windows).
 >
 > I tried first with nil `pop-up-frames' - that behaved normally, i.e., as it
 > should.  I tried then with non-nil `pop-up-frames' - and that manifested the
 > same problem that I reported!  Good news!

If you get the problem with `pop-up-frames' t and not with the special
display settings we have simplified the problem.

 > The informative buffer *Process List* is popped up in a separate frame, which
 > apparently gets the focus.  The question about killing active processes appears
 > in the minibuffer of the original frame (which has only buffer *shell*).
 >
 > Because the new frame has the focus, _you cannot answer the question_.  You are
 > forced to select the frame with the question (e.g. clicking mouse-1 on its title
 > bar), in order to answer it and exit Emacs.

OK.

 > A second bug (I think) is that there is NO feedback/response to your typing the
 > answer.  With focus in the *Process List* frame, which has a read-only buffer, I
 > would expect an error message saying that the buffer is read-only.  But you get
 > NO message - nada.  Not only that, but I see no such message in buffer
 > *Messages* if I look there.  Dunno why this is.

I suppose that as long as you don't type either yes or no in the
original frame nothing happens at all.

 >> So the problem seems that input doesn't get redirected to your
 >> minibuffer frame when popping up a new minibuffer-less frame.
 >
 > Seems to not depend on a standalone minibuffer frame, but yes, that seems to be
 > the problem.

Agreed.

 > Well, that's one problem, anyway.  Really, I do not want the new frame popped up
 > to have a minibuffer and pose the question about killing processes.  I want the
 > new frame to just be displayed and _not selected_ for input/output (user
 > interaction).  I do not want it to have a minibuffer.

But we must select a frame for answering the question.

 > More precisely, I don't have much of an opinion in the case of a non standalone
 > minibuffer.
 >
 > But in the case of a standalone minibuffer, it definitely should continue to
 > have the input focus.  That's the point, for me.

Why "continue"?  You could invoke C-x C-c in any frame.

 > It would not be a solution for me to give the new frame its own minibuffer or
 > something and to let it keep the input focus.  The user should be able to always
 > look to the same, standalone minibuffer - the *only* minibuffer area - for all
 > prompts and user replies.

We'll see to that.

 >>  > Buffer *Help* is still popped up in a new frame that has
 >>  > those colors, but now when I hit `q' in it the frame does not
 >>  > disappear and its buffer is changed.  That's not what I would
 >>  > call "dedicated" anymore.
 >>
 >> That's hardly surprising: With `pop-up-frames' t you shouldn't get a
 >> dedicated window, I suppose.
 >
 > Uh, if you are saying what I think you are saying then I'm afraid I disagree
 > strongly about that.  To me, that would be a regression.

Don't be afraid.  I meant with `pop-up-frames' t and
`special-display-buffer-names' and friends nil.

 > I'm sorry; I was probably confused in saying that.  I must have meant that it
 > works with the patch I sent, which (I thought) was applied to Emacs (or was
 > going to be applied).
 >
 > If I use Dired+ (which does what my patch does) then there is no problem, so in
 > my daily use this is solved for the Dired but reported, but not in general (viz.
 > this bug wrt quitting with active processes).

But your patch doesn't address the input focus issue or am I missing
something?

 > If you want a standalone minibuffer frame to have the _only_ minibuffer then you
 > must do everything at load time, i.e., in .emacs.

So this makes debugging more difficult for people who are not used to
work with minibuffer-only frames.

I have attached another version of `with-temp-buffer-window' which now
explicitly shifts input focus to the frame selected at the time the
macro is called.  I hope this will fix the `pop-up-frames' t scenario.
I'm afraid it will not fix the problem when you invoke C-x C-c in any
window but the minibuffer-only window so we probably have to fix that
issue separately.  Please try it.

martin

[-- Attachment #2: with-temp-buffer-window.el --]
[-- Type: application/emacs-lisp, Size: 21317 bytes --]

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  >> Sorry.  Do (defalias 'yes-or-no-p 'y-or-n-p) and then try.
>  >
>  > Are you sure you mean that?  AFAIK, `y-or-n-p' is not at 
>  > all representative - it does not even use the minibuffer,
>  > I think: it just reads events directly.  I will try to do as
>  > you instruct, if you confirm, but I do not understand how
>  > using `y-or-n-p' here can possibly help.
> 
> Because you can do `select-frame-set-input-focus' with it.

I'm afraid I still do not understand (but maybe I don't need to).  I thought the
problem has to do with input focus for minibuffer reading.  But maybe you are
saying that the minibuffer need not be involved, and that `read-event' will also
depend on which frame has the focus.

In any case, please give me the specific recipe that you would like me to try.
I'm afraid I've lost track at this point.

And is this still pertinent, given what we have discovered wrt a reproducible
recipe from emacs -Q?

>  >> ... what command is C-] bound to?  I can't type it on my 
>  >> keyboard ...
>  >
>  > `abort-recursive-edit'.  `C-]' is the (only) default 
>  > global binding (emacs -Q) for `abort-recursive-edit'.
> 
> My keyboard doesn't allow me to input things like C-] easily 
> so I don't know what these do.

You could rebind that command to see what it does.
And `C-h f' describes it.  (It is a bit like a super C-g.)

> If you get the problem with `pop-up-frames' t and not with the special
> display settings we have simplified the problem.

Yes, greatly.

>  > A second bug (I think) is that there is NO feedback/response
>  > to your typing the answer.  With focus in the *Process List*
>  > frame, which has a read-only buffer, I would expect an error
>  > message saying that the buffer is read-only.  But you get
>  > NO message - nada.  Not only that, but I see no such 
>  > message in buffer *Messages* if I look there.  Dunno why this is.
> 
> I suppose that as long as you don't type either yes or no in the
> original frame nothing happens at all.

Presumably _some_ buffer receives the input.  If it is a read-only buffer then I
would expect a read-only error message.  If it is not then I would expect to see
what I type in some buffer.  I see neither effect.  And presumably (it seems
that way anyway) it is the *Process List* buffer, which is read-only, that has
the focus.

This behavior does not seem normal.

>  > Well, that's one problem, anyway.  Really, I do not want 
>  > the new frame popped up to have a minibuffer and pose the
>  > question about killing processes.  I want the
>  > new frame to just be displayed and _not selected_ for 
>  > input/output (user interaction).  I do not want it to have
>  > a minibuffer.
> 
> But we must select a frame for answering the question.

The frame for posing and answering all questions should be, as usual, the
minibuffer frame.  Aside from `read-event' etc., reading user input should use
the minibuffer, and that means it should use the minibuffer frame.

Looking at the C code for `yes-or-no-p' (Emacs 23.3), it clearly calls
`read-from-minibuffer' (`Fread_from_minibuffer'), so it should use the
minibuffer.  The frame that should have the input focus for that prompt and
reading should be the standalone minibuffer frame - that is the _only_ frame
that has a minibuffer.

It makes no sense for any other frame to have the input focus when reading from
the minibuffer, since no other frame _has_ a minibuffer.

>  > More precisely, I don't have much of an opinion in the 
>  > case of a non standalone minibuffer.
>  >
>  > But in the case of a standalone minibuffer, it definitely 
>  > should continue to have the input focus.  That's the point, for me.
> 
> Why "continue"?  You could invoke C-x C-c in any frame.

See above.  It should have the input focus for any _reading from the
minibuffer_.  Obviously, other frames can have the input focus when not reading
from the minibuffer.  `yes-or-no-p' reads from the minibuffer.

>  > It would not be a solution for me to give the new frame 
>  > its own minibuffer or something and to let it keep the input
>  > focus.  The user should be able to always look to the same,
>  > standalone minibuffer - the *only* minibuffer area - for all
>  > prompts and user replies.
> 
> We'll see to that.

That would be a great fix.

>  >>  > Buffer *Help* is still popped up in a new frame that has
>  >>  > those colors, but now when I hit `q' in it the frame does not
>  >>  > disappear and its buffer is changed.  That's not what I would
>  >>  > call "dedicated" anymore.
>  >>
>  >> That's hardly surprising: With `pop-up-frames' t you 
>  >> shouldn't get a dedicated window, I suppose.
>  >
>  > Uh, if you are saying what I think you are saying then I'm 
>  > afraid I disagree strongly about that.  To me, that would be
>  > a regression.
> 
> Don't be afraid.  I meant with `pop-up-frames' t and
> `special-display-buffer-names' and friends nil.

OK.

But the behavior I saw with that test indicated/suggested that *Help* was not
entirely special-display (with `pop-up-frames' t and the *Help* frame defined as
indicated with `special-display-buffer-names'.

The frame was created with the correct colors etc., but buffer *Help* ended up
being replaced in the frame, which is not what "special display" means.  So I
think there might be a second bug here.

>  > If I use Dired+ (which does what my patch does) then there 
>  > is no problem, so in my daily use this is solved for the
>  > Dired but reported, but not in general (viz.
>  > this bug wrt quitting with active processes).
> 
> But your patch doesn't address the input focus issue or am I missing
> something?

Correct.  But the problem does not exist with my patch.  I don't have an
explanation.

But please see the #15566 thread - in particular, the part about the use of code
that is nearly identical but that does not manifest the input problem.  See the
message I sent that has the attachment `throw-chmod-vs-chmod-rec.el'.  I do not
understand why what I report happens, but it happens.

This is from that thread:

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

But let's not worry about that here/now.  Perhaps this thread will find a
solution to the problem _in general_.  That's my current hope, at least.

>  > If you want a standalone minibuffer frame to have the 
>  > _only_ minibuffer then you must do everything at load time,
>  > i.e., in .emacs.
> 
> So this makes debugging more difficult for people who are not used to
> work with minibuffer-only frames.

Yes.  That's not my doing; it's a fact of GNU Emacs life.  Unless someone
provides a fix that changes this.

> I have attached another version of `with-temp-buffer-window' which now
> explicitly shifts input focus to the frame selected at the time the
> macro is called.  I hope this will fix the `pop-up-frames' t scenario.
> I'm afraid it will not fix the problem when you invoke C-x C-c in any
> window but the minibuffer-only window so we probably have to fix that
> issue separately.  Please try it.

Just what is the recipe to try (e.g. from emacs -Q)?

Wrt "C-x C-c in any window but the minibuffer-only window": It's about reading
from the minibuffer (e.g. `read-from-minibuffer').  It never matters (apart from
this bug about new frames that get created during the minibuffer reading) which
buffer/frame is selected when you call `read-from-minibuffer'.  Focus is always
switched to the minibuffer (and its frame).

The problem here seems to be that just after focus is correctly switched to the
minibuffer frame, for minibuffer interaction (reading), the new frame is popped
up and MS Windows gives it the focus.  At least that's the (limited) conceptual
model I'm adopting so far.

IOW, I don't think the problem is to give the minibuffer frame the focus.  I'm
assuming that that is happening correctly, as usual.  The problem, I think, is
that the new frame creation happens at the same time or just afterward, and that
steals the focus from the minibuffer frame (thanks to MS Windows).

Thx - Drew

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > I'm afraid I still do not understand (but maybe I don't need to).  I thought the
 > problem has to do with input focus for minibuffer reading.  But maybe you are
 > saying that the minibuffer need not be involved, and that `read-event' will also
 > depend on which frame has the focus.
 >
 > In any case, please give me the specific recipe that you would like me to try.
 > I'm afraid I've lost track at this point.

`y-or-n-p' has the following two lines

                     (when minibuffer-auto-raise
                       (raise-frame (window-frame (minibuffer-window))))

So when you want to give focus to the minibuffer window you might want
to replace `raise-frame' by the stronger `select-frame-set-input-focus'

                     (when minibuffer-auto-raise
                       (select-frame-set-input-focus (window-frame (minibuffer-window))))

For this to work you have to defalias `yes-or-no-p' to `y-or-n-p'.

 > And is this still pertinent, given what we have discovered wrt a reproducible
 > recipe from emacs -Q?

As long as we have not found a solution, yes.

 >> I suppose that as long as you don't type either yes or no in the
 >> original frame nothing happens at all.
 >
 > Presumably _some_ buffer receives the input.  If it is a read-only buffer then I
 > would expect a read-only error message.  If it is not then I would expect to see
 > what I type in some buffer.  I see neither effect.  And presumably (it seems
 > that way anyway) it is the *Process List* buffer, which is read-only, that has
 > the focus.
 >
 > This behavior does not seem normal.

You would have to try with `y-or-n-p'.  read_minibuf has only

   Fmake_frame_visible (mini_frame);

   if (minibuffer_auto_raise)
     Fraise_frame (mini_frame);

which might not be sufficient for your case.  Once `y-or-n-p' with focus
selection works we can try to make it work in read_minibuf too.

 > The frame for posing and answering all questions should be, as usual, the
 > minibuffer frame.  Aside from `read-event' etc., reading user input should use
 > the minibuffer, and that means it should use the minibuffer frame.
 >
 > Looking at the C code for `yes-or-no-p' (Emacs 23.3), it clearly calls
 > `read-from-minibuffer' (`Fread_from_minibuffer'), so it should use the
 > minibuffer.  The frame that should have the input focus for that prompt and
 > reading should be the standalone minibuffer frame - that is the _only_ frame
 > that has a minibuffer.
 >
 > It makes no sense for any other frame to have the input focus when reading from
 > the minibuffer, since no other frame _has_ a minibuffer.

Most users don't care about standalone minibuffer frames.  They want to
see one frame where they find all information.

 >>  > More precisely, I don't have much of an opinion in the
 >>  > case of a non standalone minibuffer.
 >>  >
 >>  > But in the case of a standalone minibuffer, it definitely
 >>  > should continue to have the input focus.  That's the point, for me.
 >>
 >> Why "continue"?  You could invoke C-x C-c in any frame.
 >
 > See above.  It should have the input focus for any _reading from the
 > minibuffer_.  Obviously, other frames can have the input focus when not reading
 > from the minibuffer.  `yes-or-no-p' reads from the minibuffer.

So if another frame has input focus and emacs asks a `yes-or-no-p'
question, focus _should_ switch.

 > But the behavior I saw with that test indicated/suggested that *Help* was not
 > entirely special-display (with `pop-up-frames' t and the *Help* frame defined as
 > indicated with `special-display-buffer-names'.
 >
 > The frame was created with the correct colors etc., but buffer *Help* ended up
 > being replaced in the frame, which is not what "special display" means.  So I
 > think there might be a second bug here.

If this is independent from the behavior we discuss currently, we'll
have to investigate it.

 >>  > If I use Dired+ (which does what my patch does) then there
 >>  > is no problem, so in my daily use this is solved for the
 >>  > Dired but reported, but not in general (viz.
 >>  > this bug wrt quitting with active processes).
 >>
 >> But your patch doesn't address the input focus issue or am I missing
 >> something?
 >
 > Correct.  But the problem does not exist with my patch.  I don't have an
 > explanation.

Me neither.  You would have to go through it and find what it does
differently.

 > But please see the #15566 thread - in particular, the part about the use of code
 > that is nearly identical but that does not manifest the input problem.  See the
 > message I sent that has the attachment `throw-chmod-vs-chmod-rec.el'.  I do not
 > understand why what I report happens, but it happens.

 >> I have attached another version of `with-temp-buffer-window' which now
 >> explicitly shifts input focus to the frame selected at the time the
 >> macro is called.  I hope this will fix the `pop-up-frames' t scenario.
 >> I'm afraid it will not fix the problem when you invoke C-x C-c in any
 >> window but the minibuffer-only window so we probably have to fix that
 >> issue separately.  Please try it.
 >
 > Just what is the recipe to try (e.g. from emacs -Q)?

With your usual setting load the file and test the shell and the dired
scenarios.

 > Wrt "C-x C-c in any window but the minibuffer-only window": It's about reading
 > from the minibuffer (e.g. `read-from-minibuffer').  It never matters (apart from
 > this bug about new frames that get created during the minibuffer reading) which
 > buffer/frame is selected when you call `read-from-minibuffer'.  Focus is always
 > switched to the minibuffer (and its frame).

Because it does a simple `raise-frame' of the minibuffer frame which
seems to work when you don't pop up another frame before.

 > The problem here seems to be that just after focus is correctly switched to the
 > minibuffer frame, for minibuffer interaction (reading), the new frame is popped
 > up and MS Windows gives it the focus.  At least that's the (limited) conceptual
 > model I'm adopting so far.
 >
 > IOW, I don't think the problem is to give the minibuffer frame the focus.  I'm
 > assuming that that is happening correctly, as usual.  The problem, I think, is
 > that the new frame creation happens at the same time or just afterward, and that
 > steals the focus from the minibuffer frame (thanks to MS Windows).

It doesn't help to speculate.  I know of three functions to experiment
with (`select-frame' and `raise-frame' being apparently too weak):

- `select-frame-set-input-focus' which is probably too strong because it
   can change the Z-order thus obfuscating the frame where important
   information (like the list of directories to delete) is displayed,

- `x-focus-frame' which should redirect any input to the frame argument, and

- `redirect-frame-focus' which could be used to redirect input only from
   the frame where, for example, the marked directories are displayed to
   the minibuffer-only frame.

You can try to experiment with these, either in `y-or-n-p' or in
`with-temp-buffer-window'.  If neither of these helps to direct focus
away from the new frame, I see no solution.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  >> I have attached another version of 
>  >> `with-temp-buffer-window' which now explicitly shifts input
>  >> focus to the frame selected at the time the macro is called.
>  >> I hope this will fix the `pop-up-frames' t scenario.
>  >> I'm afraid it will not fix the problem when you invoke 
>  >> C-x C-c in any window but the minibuffer-only window so we
>  >> probably have to fix that issue separately.  Please try it.
>  >
>  > Just what is the recipe to try (e.g. from emacs -Q)?
> 
> With your usual setting load the file and test the shell and the dired
> scenarios.

I might be misunderstanding you, but I did this:

1. Started Emacs with my normal setup (not from emacs -Q).
2. Loaded the code you sent.
3. M-x shell

4. Clicked the title bar of the standalone minibuffer frame, to select it.  (Did
that since you said that your code would not help with the usual case, where
another frame has the focus).

5. C-x C-c

The result was the same as before: typing (e.g. "yes") had no effect.  The
minibuffer frame apparently lost the focus as soon as the new *Process List* was
created.

And when I canceled, the supposed special-display buffer *Process List* was
replaced in its frame by the buffer that was current when I hit C-x C-c.  This
part seems to be the same (separate) bug that I reported wrt *Help*.  In this
case, the special-display buffer *Process List* was defined via
`special-display-regexps' and not (as for *Help*) via
`special-display-buffer-names'.  So it seems there is a general bug that a
special-display buffer is no longer really special-display: its window/frame is
not dedicated as it should be.  Burying its buffer should not replace that
buffer in its dedicated window/frame.  It should remove that window/frame (I
have `frame-auto-hide-function' = `delete-frame').

HTH.  Let me know if I did not understand the recipe correctly.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > I might be misunderstanding you, but I did this:
 >
 > 1. Started Emacs with my normal setup (not from emacs -Q).
 > 2. Loaded the code you sent.
 > 3. M-x shell
 >
 > 4. Clicked the title bar of the standalone minibuffer frame, to select it.  (Did
 > that since you said that your code would not help with the usual case, where
 > another frame has the focus).
 >
 > 5. C-x C-c
 >
 > The result was the same as before: typing (e.g. "yes") had no effect.  The
 > minibuffer frame apparently lost the focus as soon as the new *Process List* was
 > created.

OK.  Then let's try again with `pop-up-frames' t.  With emacs -Q evaluate

(progn
   (setq pop-up-frames t)
   (load "~/with-temp-buffer-window.el")
   (shell))

type C-x C-c, and tell me what happens.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> With emacs -Q evaluate
> (progn
>    (setq pop-up-frames t)
>    (load "~/with-temp-buffer-window.el")
>    (shell))
> type C-x C-c, and tell me what happens.

Same behavior as the other emacs -Q recipe that manifested the problem:

The question about killing processes is shown in the minibuffer of the frame
with buffer *shell*.  Buffer *Process List* is popped up in a new frame, which
is apparently selected for focus (by MS Windows).  Typing yes/no has no effect
and there is no feedback, presumably because the wrong frame receives the input.

(I cannot tell the order between the behavior described in the first and second
sentences.  They seem to happen about the same time)

And if you click mouse-1 in the echo area of the *Process List* frame then
*Messages* is popped up in a new frame, confirming that there is no active
minibuffer there.

So now we have two recipes from emacs -Q, one with the code you sent.

BTW, if, after the kill-processes question is posed, I hit C-x C-c again (no
reason to do that, but I did, just to see) then I get this message:

  "window-normalize-window: #<window 8> is not a live window"

and the frame with *Process List* disappears.

Dunno whether this extra info helps at all, but I found it curious behavior.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 >> With emacs -Q evaluate
 >> (progn
 >>    (setq pop-up-frames t)
 >>    (load "~/with-temp-buffer-window.el")
 >>    (shell))
 >> type C-x C-c, and tell me what happens.
 >
 > Same behavior as the other emacs -Q recipe that manifested the problem:
 >
 > The question about killing processes is shown in the minibuffer of the frame
 > with buffer *shell*.  Buffer *Process List* is popped up in a new frame, which
 > is apparently selected for focus (by MS Windows).  Typing yes/no has no effect
 > and there is no feedback, presumably because the wrong frame receives the input.
 >
 > (I cannot tell the order between the behavior described in the first and second
 > sentences.  They seem to happen about the same time)
 >
 > And if you click mouse-1 in the echo area of the *Process List* frame then
 > *Messages* is popped up in a new frame, confirming that there is no active
 > minibuffer there.
 >
 > So now we have two recipes from emacs -Q, one with the code you sent.

This means that we have two different systems.  Here (Windows XP SP2)
the scenario above makes the *shell* buffer partially hide the *Process
List* buffer and typing yes/no has the desired effect.  Now we can only
wait till someone confirms either your or my behavior.

BTW, is it possible that Cygwin interferes here?  With Cygwin (rootless)
you apparently can't pop up an existing frame, see

http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00364.html

 > BTW, if, after the kill-processes question is posed, I hit C-x C-c again (no
 > reason to do that, but I did, just to see) then I get this message:
 >
 >   "window-normalize-window: #<window 8> is not a live window"
 >
 > and the frame with *Process List* disappears.
 >
 > Dunno whether this extra info helps at all, but I found it curious behavior.

It's a leftover from `quit-window'.  Thanks for noticing.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> This means that we have two different systems.  Here (Windows XP SP2)
> the scenario above makes the *shell* buffer partially hide 
> the *Process List* buffer and typing yes/no has the desired effect.
> Now we can only wait till someone confirms either your or my behavior.

Martin, I'm really sorry, but I was mistakenly not testing with the latest code
you sent.  I think I did not realize that you sent two versions of your
with-temp-buffer-window.el.

When I try your recipe from emacs -Q, this time loading the second version of
the code you sent, the problem for that emacs -Q recipe is solved.  Progress.

However, trying with my setup and then loading your code does not solve either
the shell frame problem or the Dired problem.

I then tried again from emacs -Q with your code, but loading only hexrgb.el,
oneonone.el, and the Cygwin setup libraries, to test whether the problem was a
standalone minibuffer.  I saw no problem when I used C-x C-c to quit with active
processes.  Likewise, no problem with the Dired scenario.  That's more good
news.

I then tried as for the last test, but also setting `special-display-regexps' to
("[ ]?[*][^*]+[*]") so that *Process List* is special-display.  Again, I saw no
problem (bug).  (But the *Process List* frame that was popped up was completely
hidden behind the frame that was selected when I hit C-x C-c.  That's not good.)

So I do not yet know what else in my setup causes the problem.  I will have to
dig to try to find out - can't do that today.

If we do find a solution for the problem in the end, it would be good if it were
also a solution for older Emacs versions, and not just Emacs 24+.  The same
problem exists in all Emacs versions I am aware of.  (But we're not there yet,
anyway.)

>  > BTW, if, after the kill-processes question is posed, I hit 
>  > C-x C-c again (no reason to do that, but I did, just to see)
>  > then I get this message:
>  >
>  >   "window-normalize-window: #<window 8> is not a live window"
>  >
>  > and the frame with *Process List* disappears.
>  >
>  > Dunno whether this extra info helps at all, but I found it 
>  > curious behavior.
> 
> It's a leftover from `quit-window'.  Thanks for noticing.

Glad my feedback serves some purpose occasionally. ;-)

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[Drew Adams]

> So I do not yet know what else in my setup causes the 
> problem.  I will have to dig to try to find out - can't do that today.

I found the problem in my code and fixed it.  It was kind of interesting, so
I'll describe it a bit in case you are interested.

In my code I put command `1on1-fit-minibuffer-frame' on `post-command-hook'.
That function fits the standalone minibuffer frame to its "buffer contents"
(taking Icomplete overlays into account etc.).

The function assumes that it is called from the minibuffer, i.e., that the
selected frame is the standalone frame.  Which it is...

But something apparently changed the focus in this case - I'm guessing, as I
said before, that it was the popping up of the new frame.  And some second
command is involved at that point - apparently `handle-switch-frame'.

So because of `post-command-hook', `1on1-fit-minibuffer-frame' got called a
second time, and this time with the previously selected frame being selected
(i.e., the frame that was selected prior to entering the minibuffer).  The
minibuffer was still active, but the selected frame was another one (e.g.
*Process List*).

I came up with three alternative fixes that work - I chose the second one:

1. The first fix is to call `select-frame-set-input-focus' at the end of
`1on1-fit-minibuffer-frame'.

I can tell by debugging using `message' that the frame switch happens outside
`1on1-fit-minibuffer-frame': the selected frame is the minibuffer frame the
first time `1on1-fit-minibuffer-frame' is called, right up till the end.  But it
is another frame the next time `1on1-fit-minibuffer-frame' is called, which
appears to be immediately afterward.

So why does this fix work?  Dunno.  Even though without adding the call to
`select-frame-set-input-focus' the frame is correct when the first call to
`1on1-fit-minibuffer-frame' ends, if I do not add that call then it is incorrect
for the second `1on1-fit-minibuffer-frame' call.  Well that's understandable
from a `switch-frame' event.

But what's not clear to me is why calling `select-frame-set-input-focus' at the
end of the first call to `1on1-fit-minibuffer-frame' fixes things.  As I said,
the frame switch seems to happen between the two calls, yet selecting the
minibuffer frame before the end of the first call solves the problem.  Maybe
this has something to do with the redisplay code?  No idea.

2. The second fix is to have `1on1-fit-minibuffer-frame' do nothing unless:

(eq last-event-frame
    (save-selected-window
     (select-window (minibuffer-window)) (selected-frame)))

3. The third fix is to have `1on1-fit-minibuffer-frame' do nothing unless:
`this-command' is not eq to `handle-switch-frame.


In sum, this is my guess: The creation of the new frame provoked a
`switch-frame' event, which, because of `post-command-hook' caused
`1on1-fit-minibuffer-frame' to be called a second time, this time with the new
frame selected because the last command was `handle-frame-switch'.

The bug was in my code.  I've wanted to clear this up for a long time, and I
think that's done now (including for older Emacs versions, obviously) - thanks
to your help.  Thank you very much!

----

BTW, in Icicle minor mode I have long used this (which Richard came up with,
IIRC), but it clearly did not help with this particular problem:

(define-key global-map [handle-switch-frame] 'icicle-skip-this-command)
(define-key global-map [switch-frame] 'icicle-handle-switch-frame)

where:

(defun icicle-skip-this-command ()
  "Prevent `handle-switch-frame' from being added to `this-command'."
  (interactive)
  (setq this-command  last-command))

(defun icicle-handle-switch-frame (event)
  "Call `handle-switch-frame', but don't add it to `this-command'."
  (interactive "e")
  (handle-switch-frame event)
  (setq this-command  last-command))

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[martin rudalics]

 > In my code I put command `1on1-fit-minibuffer-frame' on `post-command-hook'.
 > That function fits the standalone minibuffer frame to its "buffer contents"
 > (taking Icomplete overlays into account etc.).
 >
 > The function assumes that it is called from the minibuffer, i.e., that the
 > selected frame is the standalone frame.  Which it is...

Why does that function _assume_ that?  It should check it.

 > But something apparently changed the focus in this case - I'm guessing, as I
 > said before, that it was the popping up of the new frame.  And some second
 > command is involved at that point - apparently `handle-switch-frame'.

So `1on1-fit-minibuffer-frame' assumes that the selected frame is the
standalone minibuffer frame and that that frame has focus.  Why don't
you verify all that in the function's body?

 > So because of `post-command-hook', `1on1-fit-minibuffer-frame' got called a
 > second time, and this time with the previously selected frame being selected
 > (i.e., the frame that was selected prior to entering the minibuffer).  The
 > minibuffer was still active,

... you mean `active-minibuffer-window' returned the window of the
minibuffer-only frame ...

 > but the selected frame was another one (e.g.
 > *Process List*).
 >
 > I came up with three alternative fixes that work - I chose the second one:
 >
 > 1. The first fix is to call `select-frame-set-input-focus' at the end of
 > `1on1-fit-minibuffer-frame'.
 >
 > I can tell by debugging using `message' that the frame switch happens outside
 > `1on1-fit-minibuffer-frame': the selected frame is the minibuffer frame the
 > first time `1on1-fit-minibuffer-frame' is called, right up till the end.  But it
 > is another frame the next time `1on1-fit-minibuffer-frame' is called, which
 > appears to be immediately afterward.
 >
 > So why does this fix work?  Dunno.  Even though without adding the call to
 > `select-frame-set-input-focus' the frame is correct when the first call to
 > `1on1-fit-minibuffer-frame' ends, if I do not add that call then it is incorrect
 > for the second `1on1-fit-minibuffer-frame' call.  Well that's understandable
 > from a `switch-frame' event.
 >
 > But what's not clear to me is why calling `select-frame-set-input-focus' at the
 > end of the first call to `1on1-fit-minibuffer-frame' fixes things.  As I said,
 > the frame switch seems to happen between the two calls, yet selecting the
 > minibuffer frame before the end of the first call solves the problem.  Maybe
 > this has something to do with the redisplay code?  No idea.

You have two calls from `post-command-hook': The first seems due to
`save-buffers-kill-emacs' preliminary terminating with a `yes-or-no-p'
question which does not affect frame or focus.  The second should come
from `handle-switch-frame' as a consequence of emacs being called back
by the window manager.  IIUC `handle-switch-frame' calls do_switch_frame
with TRACK equal 0, so focus is not affected by `handle-switch-frame'.
But focus has been redirected to the new frame by the window manager and
emacs should probably adapt to that situation because that is the frame
that gets the keystrokes.

Now if whatever you want to do after `handle-switch-frame' has
terminated happens in the new frame, there's no problem.  We have a
problem if we want to make things happen in another frame and for that
purpose we have to redirect focus to that other frame.  That's what you
apparently do via the `select-frame-set-input-focus' call at the end of
the first `post-command-hook' execution since `handle-switch-frame'
won't change focus afterwards.  Looks like a very fragile hack.

 > 2. The second fix is to have `1on1-fit-minibuffer-frame' do nothing unless:
 >
 > (eq last-event-frame
 >     (save-selected-window
 >      (select-window (minibuffer-window)) (selected-frame)))

Is that (eq last-event-frame (window-frame (minibuffer-window)))?

This means that you don't do anything in this case so apparently some
side-effect gets suppressed.  Which side-effect?

 > 3. The third fix is to have `1on1-fit-minibuffer-frame' do nothing unless:
 > `this-command' is not eq to `handle-switch-frame.

Same as before.  What is the side-effect of `1on1-fit-minibuffer-frame'?

 > In sum, this is my guess: The creation of the new frame provoked a
 > `switch-frame' event, which, because of `post-command-hook' caused
 > `1on1-fit-minibuffer-frame' to be called a second time, this time with the new
 > frame selected because the last command was `handle-frame-switch'.

I think you should make sure two things: (1) `1on1-fit-minibuffer-frame'
should do something iff the frame in question is a minibuffer frame.
(2) `1on1-fit-minibuffer-frame' should avoid having any side-effects wrt
window selection or focus unless you explictly want that.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[Drew Adams]

>  > The function assumes that it is called from the 
>  > minibuffer, i.e., that the selected frame is the standalone frame.
>  > Which it is...
> 
> Why does that function _assume_ that?  It should check it.

It does now.  I did not realize that creation of a new frame by MS Windows with
the minibuffer frame selected (& having the focus) would change the focus.  And
I did not realize that such a change in focus would provoke another invocation
of that function (via command `handle-switch-frame', apparently), with the
minibuffer frame unfocused.

> So `1on1-fit-minibuffer-frame' assumes that the selected frame is the
> standalone minibuffer frame and that that frame has focus.  Why don't
> you verify all that in the function's body?

See above - you already asked that.  It _is_ the minibuffer frame for the call
that I expected.  I did not expect the second call provoked by the frame switch
command (via post-command-hook), with the wrong frame focused.

>  > The minibuffer was still active,
> 
> ... you mean `active-minibuffer-window' returned the window of the
> minibuffer-only frame ...

No, I meant only that the minibuffer was still active: accepting typed input.
My next sentence made it clear that the minibuffer-only frame was NOT selected:

>  > but the selected frame was another one (e.g. *Process List*).

Now maybe there is no real notion of a minibuffer being active, and it is more
correct to speak of an minibuffer _window_ being active.

I was describing things from a (possibly naive) user perspective: a
`read-from-minibuffer' was still in progress; the minibuffer was in principle
available for entering text (but its window was not selected).  IOW, if it were
selected it would accept input.

>  > I came up with three alternative fixes that work - I chose 
>  > the second one:
>  >
>  > 1. The first fix is to call `select-frame-set-input-focus' 
>  > at the end of `1on1-fit-minibuffer-frame'.
>  >
>  > But what's not clear to me is why calling 
>  >`select-frame-set-input-focus' at the
>  > end of the first call to `1on1-fit-minibuffer-frame' fixes 
>  > things.  As I said, the frame switch seems to happen between
>  > the two calls, yet selecting the minibuffer frame before the
>  > end of the first call solves the problem.  Maybe
>  > this has something to do with the redisplay code?  No idea.
> 
> You have two calls from `post-command-hook': The first seems due to
> `save-buffers-kill-emacs' preliminary terminating with a `yes-or-no-p'
> question which does not affect frame or focus.

Yes. The focus is in the minibuffer frame.  AFAICT, each time
`read-from-minibuffer' is called the focus (correctly) moves to that frame.  I
have not noticed any case where that did not happen.  Do you think there are
such cases?

> The second should come from `handle-switch-frame' as a consequence
> of emacs being called back by the window manager.

That's what I surmised also.

> IIUC `handle-switch-frame' calls do_switch_frame with TRACK equal 0,
> so focus is not affected by `handle-switch-frame'.

OK.  I'm not familiar with the code, but it's good to know that `h-s-f' (and
presumably also `switch-frame') do not affect focus.

I have not noticed that.  In fact, I thought that switching frames always did
seem to change the focus.  But perhaps it is something else and not just `h-s-f'
that actually causes the focus change (e.g. when you click another frame with
the mouse).  Perhaps it is (always?) the window mgr that changes the focus?

> But focus has been redirected to the new frame by the window 
> manager and emacs should probably adapt to that situation because
> that is the frame that gets the keystrokes.

Sounds like a plan.

> Now if whatever you want to do after `handle-switch-frame' has
> terminated happens in the new frame, there's no problem.  We have a
> problem if we want to make things happen in another frame and for that
> purpose we have to redirect focus to that other frame.
> 
> That's what you apparently do via the `select-frame-set-input-focus'
> call at the end of the first `post-command-hook' execution since
> `handle-switch-frame' won't change focus afterwards.

Yes, but it's still not clear to me just what is going on here.  The window mgr
changes the focus when it creates the new frame.  But
`1on1-fit-minibuffer-frame' is invoked via `post-command-hook', which means that
there is a command that initiates it.  I was thinking that that command must be
`h-s-f', and my testing seemed to confirm that (see fix #3, below), but if it is
not I would like to know what it really is.

If the focus change happens via the window mgr after
`1on1-fit-minibuffer-frame', and if `h-s-f' then provokes the second call to
`1on1-fit-minibuffer-frame', how can resetting the focus to the minibuffer frame
before the end of the first `1on1-fit-minibuffer-frame' solve the problem?  That
resetting would need to take place after the window mgr changed the focus, no?

It seems therefor like the window mgr changes the focus _before_ the end of the
first `1on1-fit-minibuffer-frame'.  But if I add a `message' call at the end, it
shows that the focus is still in the minibuffer frame.  That is what I do not
understand: On the one hand, the focus seems to remain in the minibuffer frame
throughout the first call to `1-f-m-f'.  On the other hand, explicitly setting
the focus to the minibuffer frame at the end of `1-f-m-f' solves the problem.
Can you explain that?

> Looks like a very fragile hack.

Which is why I picked the second fix.  And I still am not clear why the first
fix works - see previous.

>  > 2. The second fix is to have `1on1-fit-minibuffer-frame' 
>  > do nothing unless:
>  > (eq last-event-frame
>  >     (save-selected-window
>  >      (select-window (minibuffer-window)) (selected-frame)))
> 
> Is that (eq last-event-frame (window-frame (minibuffer-window)))?

Duh.  Thanks.

> This means that you don't do anything in this case so apparently some
> side-effect gets suppressed.  Which side-effect?

What the function does: fit the minibuffer frame to its displayed content.  As I
said, the function should be a no-op if the minibuffer is not active or the
minibuffer frame is not in focus.

FYI, this is the full condition under which it will not be a no-op:

;; We could assume the minibuffer frame is `1on1-minibuffer-frame', but we do
not.
(and 1on1-fit-minibuffer-frame-flag
     (active-minibuffer-window)
     ;; Do this because this command is on `post-command-hook',
     ;; and an event such as `handle-switch-frame' might have
     ;; changed the selected frame.
     (eq last-event-frame (window-frame (minibuffer-window)))
     (save-selected-window
       (select-window (minibuffer-window))
       ;; We should be able to use just (one-window-p),
       ;; but an Emacs bug means we need this:
       (one-window-p nil 'selected-frame)))

Perhaps you see some improvement/simplification possible there.  (I don't recall
what Emacs bug was involved wrt the last clause or what release that bug is in,
FWIW.)

And yes, I know that you feel that `one-window-p' is not the right way to check
for one-windowness.  But I need this to work for multiple Emacs versions, and so
far I've found that `one-window-p' DTRT.  Still, I'm open to suggestions if you
see an improvement here.

>  > 3. The third fix is to have `1on1-fit-minibuffer-frame' do 
>  > nothing unless: `this-command' is not eq to `handle-switch-frame.
> 
> Same as before.  What is the side-effect of `1on1-fit-minibuffer-frame'?

Same as before.  This is just a different way to make the function a no-op.
Testing seemed to show that `this-command' is `handle-switch-frame' in the
problematic case.  

But perhaps this is fragile also (perhaps there are additional commands where it
should be a no-op).  Which is why I picked fix #2.

>  > In sum, this is my guess: The creation of the new frame provoked a
>  > `switch-frame' event, which, because of `post-command-hook' caused
>  > `1on1-fit-minibuffer-frame' to be called a second time, 
>  > this time with the new frame selected because the last command
>  > was `handle-frame-switch'.
> 
> I think you should make sure two things: (1) 
> `1on1-fit-minibuffer-frame' should do something iff the frame in
> question is a minibuffer frame.

What do you mean by "a minibuffer frame"?  It just has a non-nil `minibuffer'
parameter?  Or that parameter has a value of `only'?  Or something else?

Is the following test not sufficient to ensure that it is "a minibuffer frame"?

(eq last-event-frame (window-frame (minibuffer-window)))

Let me know if you think I should add an additional test or replace that test
with another.

> (2) `1on1-fit-minibuffer-frame' should avoid having any 
> side-effects wrt window selection or focus unless you explictly want that.

That is the case - it has no side effects wrt window selection or focus.  The
selection window and the focus are at the end what they were at the beginning.

All it does, when it is not a no-op, is (maybe) resize and reposition the
minibuffer frame.

Thx.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[martin rudalics]

 > It does now.  I did not realize that creation of a new frame by MS Windows with
 > the minibuffer frame selected (& having the focus) would change the focus.  And
 > I did not realize that such a change in focus would provoke another invocation
 > of that function (via command `handle-switch-frame', apparently), with the
 > minibuffer frame unfocused.

Can a minibuffer-less frame get the focus?

 >> So `1on1-fit-minibuffer-frame' assumes that the selected frame is the
 >> standalone minibuffer frame and that that frame has focus.  Why don't
 >> you verify all that in the function's body?
 >
 > See above - you already asked that.  It _is_ the minibuffer frame for the call
 > that I expected.  I did not expect the second call provoked by the frame switch
 > command (via post-command-hook), with the wrong frame focused.

Can you check somehow that the minibuffer-less frame is focussed?

 >>  > The minibuffer was still active,
 >>
 >> ... you mean `active-minibuffer-window' returned the window of the
 >> minibuffer-only frame ...
 >
 > No, I meant only that the minibuffer was still active: accepting typed input.

When?

 > My next sentence made it clear that the minibuffer-only frame was NOT selected:
 >
 >>  > but the selected frame was another one (e.g. *Process List*).
 >
 > Now maybe there is no real notion of a minibuffer being active, and it is more
 > correct to speak of an minibuffer _window_ being active.
 >
 > I was describing things from a (possibly naive) user perspective: a
 > `read-from-minibuffer' was still in progress; the minibuffer was in principle
 > available for entering text (but its window was not selected).  IOW, if it were
 > selected it would accept input.

I don't understand: With `minibuffer-auto-raise' nil you can redirect
focus to a frame A while keeping frame B selected.  Or am I missing
something?  I'd rather think that a new popped up frame doesn't have
it's focus redirected yet to the minibuffer frame or something like
that.

 > Yes. The focus is in the minibuffer frame.  AFAICT, each time
 > `read-from-minibuffer' is called the focus (correctly) moves to that frame.  I
 > have not noticed any case where that did not happen.  Do you think there are
 > such cases?

Apparently just the one where a new frame just popped up.

 > OK.  I'm not familiar with the code, but it's good to know that `h-s-f' (and
 > presumably also `switch-frame') do not affect focus.

IIUC `handle-switch-frame' has to switch focus only if the frame that
previosly had focus gets deleted.

 > I have not noticed that.  In fact, I thought that switching frames always did
 > seem to change the focus.  But perhaps it is something else and not just `h-s-f'
 > that actually causes the focus change (e.g. when you click another frame with
 > the mouse).  Perhaps it is (always?) the window mgr that changes the focus?

I don't think so since redirecting frame focus and not bringing the
focussed frame to the foreground works.

 > Yes, but it's still not clear to me just what is going on here.  The window mgr
 > changes the focus when it creates the new frame.  But
 > `1on1-fit-minibuffer-frame' is invoked via `post-command-hook', which means that
 > there is a command that initiates it.  I was thinking that that command must be
 > `h-s-f', and my testing seemed to confirm that (see fix #3, below), but if it is
 > not I would like to know what it really is.

You can try putting something on `mouse-leave-buffer-hook'.  IIUC
`handle-switch-frame' calls this even when the mouse is not used.

 > If the focus change happens via the window mgr after
 > `1on1-fit-minibuffer-frame', and if `h-s-f' then provokes the second call to
 > `1on1-fit-minibuffer-frame', how can resetting the focus to the minibuffer frame
 > before the end of the first `1on1-fit-minibuffer-frame' solve the problem?  That
 > resetting would need to take place after the window mgr changed the focus, no?

I suppose that Emacs has selected the new frame but not redirected frame
focus yet.  Note that each frame (see frame.h) has a focus_frame field
which, if nil, tells which frame should get the input.  If this field is
not set and the new frame does not have a minibuffer, input gets lost
until you manually select the minibuffer frame.

 >
 > It seems therefor like the window mgr changes the focus _before_ the end of the
 > first `1on1-fit-minibuffer-frame'.  But if I add a `message' call at the end, it
 > shows that the focus

... I'm not sure whether "the focus" exists.  Rather, each frame seems
to either have focus itself or have it redirected elsewhere.  But there
need not exist one single focus for two different frames.

 > is still in the minibuffer frame.  That is what I do not
 > understand: On the one hand, the focus seems to remain in the minibuffer frame
 > throughout the first call to `1-f-m-f'.  On the other hand, explicitly setting
 > the focus to the minibuffer frame at the end of `1-f-m-f' solves the problem.
 > Can you explain that?

Because the focus of the new frame was not yet directed to the
minibuffer frame, I suppose.

 > What the function does: fit the minibuffer frame to its displayed content.  As I
 > said, the function should be a no-op if the minibuffer is not active or the
 > minibuffer frame is not in focus.

The minibuffer frame can be in focus all the time without ever being selected.

 > FYI, this is the full condition under which it will not be a no-op:
 >
 > ;; We could assume the minibuffer frame is `1on1-minibuffer-frame', but we do
 > not.
 > (and 1on1-fit-minibuffer-frame-flag
 >      (active-minibuffer-window)
 >      ;; Do this because this command is on `post-command-hook',
 >      ;; and an event such as `handle-switch-frame' might have
 >      ;; changed the selected frame.
 >      (eq last-event-frame (window-frame (minibuffer-window)))
 >      (save-selected-window
 >        (select-window (minibuffer-window))
 >        ;; We should be able to use just (one-window-p),
 >        ;; but an Emacs bug means we need this:
 >        (one-window-p nil 'selected-frame)))
 >
 > Perhaps you see some improvement/simplification possible there.  (I don't recall
 > what Emacs bug was involved wrt the last clause or what release that bug is in,
 > FWIW.)
 >
 > And yes, I know that you feel that `one-window-p' is not the right way to check
 > for one-windowness.  But I need this to work for multiple Emacs versions, and so
 > far I've found that `one-window-p' DTRT.  Still, I'm open to suggestions if you
 > see an improvement here.

If you understand it, `one-window-p' is OK.  For me the NOMINI and
ALL-FRAMES arguments are difficult to understand.

 >> I think you should make sure two things: (1)
 >> `1on1-fit-minibuffer-frame' should do something iff the frame in
 >> question is a minibuffer frame.
 >
 > What do you mean by "a minibuffer frame"?  It just has a non-nil `minibuffer'
 > parameter?  Or that parameter has a value of `only'?  Or something else?

I don't know.  How do usually check whether you are in your minibuffer frame?

 > Is the following test not sufficient to ensure that it is "a minibuffer frame"?
 >
 > (eq last-event-frame (window-frame (minibuffer-window)))

Probably.  I'd have to look how this is assigned.

 > Let me know if you think I should add an additional test or replace that test
 > with another.
 >
 >> (2) `1on1-fit-minibuffer-frame' should avoid having any
 >> side-effects wrt window selection or focus unless you explictly want that.
 >
 > That is the case - it has no side effects wrt window selection or focus.  The
 > selection window and the focus are at the end what they were at the beginning.
 >
 > All it does, when it is not a no-op, is (maybe) resize and reposition the
 > minibuffer frame.

OK.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[Drew Adams]

> Can a minibuffer-less frame get the focus?

In what scenario?  I don't know what you are asking.

Of course a minibuffer-less frame can get the focus either programmatically (a
function executing in the minibuffer can select another frame) or through user
interaction (the user can click another frame, etc.).

In my use, the focus can change fairly often, but intentionally (e.g. via a user
initiating some command/key from the minibuffer).

>  >> So `1on1-fit-minibuffer-frame' assumes that the selected 
>  >> frame is the standalone minibuffer frame and that that
>  >> frame has focus.  Why don't you verify all that in the
>  >> function's body?
>  >
>  > See above - you already asked that.  It _is_ the 
>  > minibuffer frame for the call that I expected.  I did not
>  > expect the second call provoked by the frame switch
>  > command (via post-command-hook), with the wrong frame focused.
> 
> Can you check somehow that the minibuffer-less frame is focussed?

Again, I don't know what you mean, or how to do that.

I'm pretty sure that I saw earlier (e.g. when I reported the bug) that the new
frame, which was read-only, had the focus.  I could tell via debug messages and
because it raised a buffer-read-only error.

If I remove the test I added that prevents `1on1-fit...' from doing anything if
the minibuffer frame is not selected, I can see that buffer and frame *Process
List* are selected.  And I believe that that is where the typed input goes in
that case.

>  >>  > The minibuffer was still active,
>  >>
>  >> ... you mean `active-minibuffer-window' returned the window of the
>  >> minibuffer-only frame ...
>  >
>  > No, I meant only that the minibuffer was still active: 
>  > accepting typed input.
> 
> When?

Let's not get confused with the language here.  I was not talking about the
minibuffer _frame_ accepting input, i.e., having the focus.  That is of course
the problem.

I was talking only about the minibuffer still being active (not exited) and
`read-from-minibuffer' still expecting input.

>  > My next sentence made it clear that the minibuffer-only 
>  > frame was NOT selected:
>  >
>  >>  > but the selected frame was another one (e.g. *Process List*).
>  >
>  > Now maybe there is no real notion of a minibuffer being 
>  > active, and it is more correct to speak of an minibuffer _window_
>  > being active.
>  >
>  > I was describing things from a (possibly naive) user perspective: a
>  > `read-from-minibuffer' was still in progress; the minibuffer was in
>  > principle available for entering text (but its window was not 
>  > selected).  IOW, if it were selected it would accept input.
> 
> I don't understand: With `minibuffer-auto-raise' nil you can redirect
> focus to a frame A while keeping frame B selected.  Or am I missing
> something?  I'd rather think that a new popped up frame doesn't have
> it's focus redirected yet to the minibuffer frame or something like
> that.

That sounds right to me also.  That is what I wrote (as my "guess") in previous
messages.

>  > Yes. The focus is in the minibuffer frame.  AFAICT, each time
>  > `read-from-minibuffer' is called the focus (correctly) 
>  > moves to that frame.  I have not noticed any case where that did
>  > not happen.  Do you think there are such cases?
> 
> Apparently just the one where a new frame just popped up.

It is still my guess that the focus _was_ directed to the minibuffer for/by
`read-from-minibuffer', but that thereafter the new frame was popped up and the
window mgr gave it the focus (i.e., took focus away from the minibuffer frame).
No, I do not have any proof of that, but that's my conceptual model so far.

But you understand this stuff at a better, lower level than I: you understand it
at the level of windows etc.  It is no doubt correct to speak of the minibuffer
window and not (as I did, waving my hands) of the "minibuffer" expecting input.

I'm just trying to make sense of this as best I can, without a good
understanding of windows and frames etc.  You need not pay attention to my
interpretations of the behavior.

>  > OK.  I'm not familiar with the code, but it's good to know 
>  > that `h-s-f' (and presumably also `switch-frame') do not affect focus.
> 
> IIUC `handle-switch-frame' has to switch focus only if the frame that
> previosly had focus gets deleted.
> 
>  > I have not noticed that.  In fact, I thought that switching
>  > frames always did seem to change the focus.  But perhaps it is
>  > something else and not just `h-s-f' that actually causes the
>  > focus change (e.g. when you click another frame with
>  > the mouse).  Perhaps it is (always?) the window mgr that 
>  > changes the focus?
> 
> I don't think so since redirecting frame focus and not bringing the
> focussed frame to the foreground works.

I don't see how that contradicts things.  I was not saying that a frame could
not have the focus unless it was in front.

I'm not sure what we're talking about anymore.  What seems to me to be happening
is that the window mgr gives the new frame the focus.  I'm guessing that it does
that after the minibuffer already had the focus (correctly), but I don't know
that for a fact.

But in all other cases (i.e., where there is no such bug), reading from the
minibuffer does move the focus to the minibuffer frame.  To me, the simplest
assumption that fits the observed behavior is that the minibuffer frame did get
the focus for reading input, but then the window mgr popped up the new frame and
gave it the focus.

>  > Yes, but it's still not clear to me just what is going on 
>  > here.  The window mgr changes the focus when it creates the new
>  > frame.  But `1on1-fit-minibuffer-frame' is invoked via 
>  > `post-command-hook', which means that there is a command that
>  > initiates it.  I was thinking that that command must be
>  > `h-s-f', and my testing seemed to confirm that (see fix 
>  > #3, below), but if it is not I would like to know what it really is.
> 
> You can try putting something on `mouse-leave-buffer-hook'.  IIUC
> `handle-switch-frame' calls this even when the mouse is not used.

Did you see the #3 that I referenced?  It seems pretty clear to me that `h-s-f'
is the command whose post-command-hook action invoked
`1on1-fit-minibuffer-frame' the second time.  That was tested vis `this-command'
etc.

>  > If the focus change happens via the window mgr after
>  > `1on1-fit-minibuffer-frame', and if `h-s-f' then provokes 
>  > the second call to `1on1-fit-minibuffer-frame', how can
>  > resetting the focus to the minibuffer frame
>  > before the end of the first `1on1-fit-minibuffer-frame' 
>  > solve the problem?  That resetting would need to take place
>  > after the window mgr changed the focus, no?
> 
> I suppose that Emacs has selected the new frame but not 
> redirected frame focus yet.  Note that each frame (see frame.h)
> has a focus_frame field which, if nil, tells which frame should
> get the input.  If this field is not set and the new frame does
> not have a minibuffer, input gets lost until you manually select
> the minibuffer frame.

Perhaps that is the explanation.  But until I added the test to do nothing if
the minibuffer frame was not selected I had the impression that the *Process
List* buffer had the focus AND received the typed input.

I thought I could tell this from the read-only error.  But I no longer see that
error message now when I take out that test.  I see debug message output saying
that the current buffer and current frame are *Process List*.  But I guess that
is not the same thing as saying that that buffer & frame have the focus for
input.

When this happens, if I click the frame for *Messages* and then type more input,
the debug messages say that the current buffer and frame are *Messages*, but the
typed input is not inserted in *Messages*. 

So maybe you are right that "input gets lost".  It does not appear in any frame,
at least.  Dunno whether the act of adding debug output messages interferes with
what's going on at all.

>  > It seems therefor like the window mgr changes the focus 
>  > _before_ the end of the first `1on1-fit-minibuffer-frame'.
>  > But if I add a `message' call at the end, it shows that the focus
> 
> ... I'm not sure whether "the focus" exists.  Rather, each frame seems
> to either have focus itself or have it redirected elsewhere.  
> But there need not exist one single focus for two different frames.

OK.  I didn't realize that.  So things are more complicated than my simple
conceptual model allows.

>  > is still in the minibuffer frame.  That is what I do not
>  > understand: On the one hand, the focus seems to remain in 
>  > the minibuffer frame throughout the first call to `1-f-m-f'.
>  > On the other hand, explicitly setting the focus to the
>  > minibuffer frame at the end of `1-f-m-f' solves the problem.
>  > Can you explain that?
> 
> Because the focus of the new frame was not yet directed to the
> minibuffer frame, I suppose.

I guess so.

>  > What the function does: fit the minibuffer frame to its 
>  > displayed content.  As I said, the function should be a
>  > no-op if the minibuffer is not active or the
>  > minibuffer frame is not in focus.
> 
> The minibuffer frame can be in focus all the time without 
> ever being selected.
> 
> If you understand it, `one-window-p' is OK.  For me the NOMINI and
> ALL-FRAMES arguments are difficult to understand.
> 
>  >> I think you should make sure two things: (1)
>  >> `1on1-fit-minibuffer-frame' should do something iff the frame in
>  >> question is a minibuffer frame.
>  >
>  > What do you mean by "a minibuffer frame"?  It just has a 
>  > non-nil `minibuffer' parameter?  Or that parameter has a
>  > value of `only'?  Or something else?
> 
> I don't know.  How do usually check whether you are in your 
> minibuffer frame?

I don't usually check.  But if I did I guess I'd do it the way I do in the code
I showed (but which does not seem to work now).  But I'm open to suggestions.

Keep in mind that, apart from this bug, whenever the minibuffer (window) is
active the minibuffer frame is focused (receives the input).

>  > Is the following test not sufficient to ensure that it is 
>  > "a minibuffer frame"?
>  > (eq last-event-frame (window-frame (minibuffer-window)))
> 
> Probably.  I'd have to look how this is assigned.

Thanks for hanging in there.

 - Drew

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[martin rudalics]

 >> Can a minibuffer-less frame get the focus?
 >
 > In what scenario?  I don't know what you are asking.
 >
 > Of course a minibuffer-less frame can get the focus either programmatically (a
 > function executing in the minibuffer can select another frame) or through user
 > interaction (the user can click another frame, etc.).

Here and everywhere else I meant focus redirection for interaction with
the minibuffer.  Obviously `redirect-frame-focus' can redirect focus to
a minibuffer-less frame.  But choose_minibuf_frame has this

       /* I don't think that any frames may validly have a null minibuffer
	 window anymore.  */
       if (NILP (sf->minibuffer_window))
	abort ();

and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't
have a valid minibuffer window, emacs should abort.  If it does, the
latter

   if (!EQ (mini_frame, selected_frame))
     Fredirect_frame_focus (selected_frame, mini_frame);

in read_minibuf should redirect focus but apparently it doesn't.

 >>  >> So `1on1-fit-minibuffer-frame' assumes that the selected
 >>  >> frame is the standalone minibuffer frame and that that
 >>  >> frame has focus.  Why don't you verify all that in the
 >>  >> function's body?
 >>  >
 >>  > See above - you already asked that.  It _is_ the
 >>  > minibuffer frame for the call that I expected.  I did not
 >>  > expect the second call provoked by the frame switch
 >>  > command (via post-command-hook), with the wrong frame focused.
 >>
 >> Can you check somehow that the minibuffer-less frame is focussed?
 >
 > Again, I don't know what you mean, or how to do that.

Probably by checking whether the focus of the minibuffer-less frame A is
redirected to the minibuffer-equipped frame B.

 >>  > No, I meant only that the minibuffer was still active:
 >>  > accepting typed input.
 >>
 >> When?
 >
 > Let's not get confused with the language here.  I was not talking about the
 > minibuffer _frame_ accepting input, i.e., having the focus.  That is of course
 > the problem.
 >
 > I was talking only about the minibuffer still being active (not exited)

But what does that mean in practice?  Apart from looping.

 > and
 > `read-from-minibuffer' still expecting input.

Obviously so.

 > It is still my guess that the focus _was_ directed to the minibuffer for/by
 > `read-from-minibuffer', but that thereafter the new frame was popped up and the
 > window mgr gave it the focus (i.e., took focus away from the minibuffer frame).

 From the window manager's POV the minibuffer-less frame does have
focus.  The emacs redirection mechanism works on top of that.

 > No, I do not have any proof of that, but that's my conceptual model so far.
 >
 > But you understand this stuff at a better, lower level than I: you understand it
 > at the level of windows etc.

I understand next to nothing about WM windows.

 > It is no doubt correct to speak of the minibuffer
 > window and not (as I did, waving my hands) of the "minibuffer" expecting input.

It makes a difference if you have a minibuffer-less frame that has no
minibuffer window it can direct input to.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[Drew Adams]

> But choose_minibuf_frame has this
> 
>        /* I don't think that any frames may validly have a 
>           null minibuffer window anymore.  */
>        if (NILP (sf->minibuffer_window))
> 	abort ();

Wow, that comment seems weird.  Unless a frame that has nil as the value of its
`minibuffer' frame parameter is still expected to have a minibuffer _window_.
That's a distinction that is beyond me.  I do not claim to understand things at
the Emacs window level.

But certainly there can be frames that have no minibuffer - their `minibuffer'
frame parameter value is nil.

> and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't
> have a valid minibuffer window, emacs should abort.

What does abort mean here - does it mean that Emacs exits?

> If it does, the latter
>    if (!EQ (mini_frame, selected_frame))
>      Fredirect_frame_focus (selected_frame, mini_frame);
> 
> in read_minibuf should redirect focus but apparently it doesn't.

Again, are you sure it does not?  I've been (stubbornly) guessing that it always
does, but then, in the problematic case we've been looking at, the focus is
grabbed away and given to the new frame that is popped up.

I understand that you don't see it that way, that you instead guess that in this
problematic case there is never any redirection of focus to the minibuffer
frame.  But I haven't yet understood why you think that.  (I do not say you are
wrong.)

>  >>  >> So `1on1-fit-minibuffer-frame' assumes that the selected
>  >>  >> frame is the standalone minibuffer frame and that that
>  >>  >> frame has focus.  Why don't you verify all that in the
>  >>  >> function's body?
>  >>  >
>  >>  > See above - you already asked that.  It _is_ the
>  >>  > minibuffer frame for the call that I expected.  I did not
>  >>  > expect the second call provoked by the frame switch
>  >>  > command (via post-command-hook), with the wrong frame focused.
>  >>
>  >> Can you check somehow that the minibuffer-less frame is focussed?
>  >
>  > Again, I don't know what you mean, or how to do that.
> 
> Probably by checking whether the focus of the minibuffer-less 
> frame A is redirected to the minibuffer-equipped frame B.

I don't know how to do that.

And in `1on1-fit-minibuffer-frame' I do not know how to find out what the
minibuffer-less frame is.  That function is just invoked by `post-command-hook'.

It seems that in the problematic case it is command `handle-switch-frame' that
is the command current when `post-command-hook' does its thing here.  But I
don't know how to determine what frame was switched to.  I can check
`selected-frame', which is what I do, but I'm not sure what you are suggesting I
do.

>  > I was talking only about the minibuffer still being active 
>  > (not exited)
> 
> But what does that mean in practice?  Apart from looping.

In my mind it means only that (active-minibuffer-window) returns non-nil.  But
again, I'm really no expert on this stuff, and I do not pretend to understand
what really happens, especially at the level of Emacs windows.

AFAIK, the only test available to Lisp programmers to tell whether the
minibuffer is active (expecting input), wherever it might be located, is
`active-minibuffer-window'.

>  > It is still my guess that the focus _was_ directed to the 
>  > minibuffer for/by `read-from-minibuffer', but that thereafter
>  > the new frame was popped up and the window mgr gave it the focus
>  > (i.e., took focus away from the minibuffer frame).
> 
> From the window manager's POV the minibuffer-less frame does have
> focus.

OK, but did the minibuffer frame ever receive the focus, after
`read-from-minibuffer' was invoked?  That's the question that I think we are
assuming different answers to.  I'm guessing yes, and I think you are saying no.
I'm guessing yes, but then the window mgr gave the focus instead to the new
frame it created.

> The emacs redirection mechanism works on top of that.
> 
>  > No, I do not have any proof of that, but that's my 
>  > conceptual model so far.
>  >
>  > But you understand this stuff at a better, lower level 
>  > than I: you understand it at the level of windows etc.
> 
> I understand next to nothing about WM windows.

Me too.  I meant Emacs windows.

>  > It is no doubt correct to speak of the minibuffer
>  > window and not (as I did, waving my hands) of the 
>  > "minibuffer" expecting input.
> 
> It makes a difference if you have a minibuffer-less frame that has no
> minibuffer window it can direct input to.

OK.  What's needed I guess is to make sure somehow that every frame redirects
input to the minibuffer frame when the minibuffer becomes active.

Perhaps it would help to imagine the new frame scenario a bit like the
switch-to-*Completions*-frame scenario (dunno).

As I mentioned in my other reply today, you can, when the minibuffer is active,
explicitly switch the focus to the *Completions* frame, to do something there
(e.g. move to some completion candidate).

In Icicles you can do this by hitting `C-insert' from the minibuffer (i.e., in a
minibuffer keymap).  You can then switch back to the minibuffer by hitting
`C-insert' again (this time, that's a key binding in
`completion-list-mode-map').  For example, you can use `C-insert' to move to
*Completions*, then move to a particular completion, then use `C-insert' to move
back to the minibuffer.  The latter `C-insert' brings the candidate back, i.e.,
inserts it into the minibuffer.

Now in the case of the new frame that is popped up while reading from the
minibuffer, the window mgr (I'm supposing) does the equivalent of my `C-insert':
it switches the focus to the new frame, just like `C-insert' switches the focus
to *Completions*.  That's not an intention on the part of the user, but it
happens (due to MS Windows).

So a possible (hack) solution, if we could detect that unprogrammed (in Emacs)
focus switch, might be to automatically switch focus back to the minibuffer
frame (IF the minibuffer is active).

Does this new frame creation necessarily go through Emacs `make-frame'?  Maybe
there is a hook there that could be used for such a hack?  Dunno - just some
rough ideas.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[martin rudalics]

 >> But choose_minibuf_frame has this
 >>
 >>        /* I don't think that any frames may validly have a
 >>           null minibuffer window anymore.  */
 >>        if (NILP (sf->minibuffer_window))
 >> 	abort ();
 >
 > Wow, that comment seems weird.  Unless a frame that has nil as the value of its
 > `minibuffer' frame parameter is still expected to have a minibuffer _window_.
 > That's a distinction that is beyond me.  I do not claim to understand things at
 > the Emacs window level.

Usually, each frame must have a minibuffer window.  How else should
`read-minibuffer' work?  But within the C routines this invariant seems
too strong.

 > But certainly there can be frames that have no minibuffer - their `minibuffer'
 > frame parameter value is nil.

That's a different story.  IIUC only the selected frame must have the
minibuffer_window slot always set.

 >> and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't
 >> have a valid minibuffer window, emacs should abort.
 >
 > What does abort mean here - does it mean that Emacs exits?

Ungracefully, yes.

 >> If it does, the latter
 >>    if (!EQ (mini_frame, selected_frame))
 >>      Fredirect_frame_focus (selected_frame, mini_frame);
 >>
 >> in read_minibuf should redirect focus but apparently it doesn't.
 >
 > Again, are you sure it does not?  I've been (stubbornly) guessing that it always
 > does, but then, in the problematic case we've been looking at, the focus is
 > grabbed away and given to the new frame that is popped up.
 >
 > I understand that you don't see it that way, that you instead guess that in this
 > problematic case there is never any redirection of focus to the minibuffer
 > frame.  But I haven't yet understood why you think that.  (I do not say you are
 > wrong.)

As explained many times before I'm just speculating.  Note, however,
that the redirection in the code above works only for the selected
frame.  That's why I ask the `yes-or-no-p' questions with the new frame
selected.

 >> Probably by checking whether the focus of the minibuffer-less
 >> frame A is redirected to the minibuffer-equipped frame B.
 >
 > I don't know how to do that.
 >
 > And in `1on1-fit-minibuffer-frame' I do not know how to find out what the
 > minibuffer-less frame is.  That function is just invoked by `post-command-hook'.
 >
 > It seems that in the problematic case it is command `handle-switch-frame' that
 > is the command current when `post-command-hook' does its thing here.  But I
 > don't know how to determine what frame was switched to.  I can check
 > `selected-frame', which is what I do, but I'm not sure what you are suggesting I
 > do.

Why don't you try what I suggested earlier: Put something on
`mouse-leave-buffer-hook' and in a `pre-' or `post-command-hook' check
whether that something got executed.  Then you can be sure that
somewhere in between a `handle-switch-frame' interfered.

 > OK, but did the minibuffer frame ever receive the focus, after
 > `read-from-minibuffer' was invoked?  That's the question that I think we are
 > assuming different answers to.  I'm guessing yes, and I think you are saying no.
 > I'm guessing yes, but then the window mgr gave the focus instead to the new
 > frame it created.

So you mean the following happens:

(1) Emacs ask a `yes-or-no-p' with input focus directed to frame A.

(2) The window manager redirects focus to the new frame B and the
     `handle-switch-frame' which should redirect focus from B to A gets
     delayed as long as Emacs waits for minibuffer input.

 > OK.  What's needed I guess is to make sure somehow that every frame redirects
 > input to the minibuffer frame when the minibuffer becomes active.

Which won't help in (2) above.

 > Perhaps it would help to imagine the new frame scenario a bit like the
 > switch-to-*Completions*-frame scenario (dunno).
 >
 > As I mentioned in my other reply today, you can, when the minibuffer is active,
 > explicitly switch the focus to the *Completions* frame, to do something there
 > (e.g. move to some completion candidate).

Which function precisely does that?

 > So a possible (hack) solution, if we could detect that unprogrammed (in Emacs)
 > focus switch, might be to automatically switch focus back to the minibuffer
 > frame (IF the minibuffer is active).

Or assume that the focus switch happened and react accordingly.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[Drew Adams]

> Usually, each frame must have a minibuffer window.  How else should
> `read-minibuffer' work?

It can read from the minibuffer in a standalone minibuffer frame?

> But within the C routines this invariant seems too strong.
> 
>  > But certainly there can be frames that have no minibuffer 
>  > - their `minibuffer' frame parameter value is nil.
> 
> That's a different story.  IIUC only the selected frame must have the
> minibuffer_window slot always set.

That's what I was guessing, that a frame's `minibuffer' parameter might be
non-nil but it somehow has a minibuffer _window_.  Seems odd, but I guess these
things are at two different levels.  I am used to the Lisp & frame level - I
know almost nothing about the C & window level.

>  >> Fredirect_frame_focus (selected_frame, mini_frame); in
>  >> read_minibuf should redirect focus but apparently it doesn't.
>  >
>  > Again, are you sure...?...
> 
> I'm just speculating.  Note, however, that the redirection
> in the code above works only for the selected frame.
> That's why I ask the `yes-or-no-p' questions with the 
> new frame selected.
> 
> Why don't you try what I suggested earlier: Put something on
> `mouse-leave-buffer-hook' and in a `pre-' or
> `post-command-hook' check whether that something got executed.
> Then you can be sure that somewhere in between a
> `handle-switch-frame' interfered.

Sorry, I don't follow you (and I haven't found where you suggested something
similar earlier).  If you can be more specific I'll be glad to try whatever you
ask.

>  > did the minibuffer frame ever receive the focus, after
>  > `read-from-minibuffer' was invoked?  That's the question 
>  > that I think we are assuming different answers to.  I'm
>  > guessing yes, and I think you are saying no.
>  > I'm guessing yes, but then the window mgr gave the focus 
>  > instead to the new frame it created.
> 
> So you mean the following happens:
> 
> (1) Emacs ask a `yes-or-no-p' with input focus directed to frame A.
> 
> (2) The window manager redirects focus to the new frame B and the
>      `handle-switch-frame' which should redirect focus from B 
>      to A gets delayed as long as Emacs waits for minibuffer input.

I didn't mean that, but maybe that's what happens.

All I meant was that (I'm guessing that):

a. Emacs asks the question, directing focus to the minibuffer frame for the user
to input a response.

b. MS Windows creates the new frame and gives it the focus, taking the focus
away from the minibuffer.

>  > OK.  What's needed I guess is to make sure somehow that 
>  > every frame redirects input to the minibuffer frame when
>  > the minibuffer becomes active.
> 
> Which won't help in (2) above.

Right, and maybe not in my supposition either.

>  > Perhaps it would help to imagine the new frame scenario a 
>  > bit like the switch-to-*Completions*-frame scenario (dunno).
>  >
>  > As I mentioned in my other reply today, you can, when the 
>  > minibuffer is active, explicitly switch the focus to the
>  > *Completions* frame, to do something there
>  > (e.g. move to some completion candidate).
> 
> Which function precisely does that?

With just oneonone.el loaded (which creates a standalone minibuffer and
special-display *Help* and *Completions*, with the latter frame redirected to
the minibuffer frame), even just `C-x o' during completion will do it.  I.e.,
from the minibuffer, `C-x o' moves you (focus) to *Completions*.

Or you can click *Completions* with the mouse - same effect.

In Icicles, you can use C-<insert> to flip back and forth between the minibuffer
and *Completions*.  C-<insert> is command `switch-to-*Completions*' in the
minibuffer completion keymaps, and C-<insert> is command
`icicle-insert-completion' in keymap `completion-list-mode-map'.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[martin rudalics]

 >> Usually, each frame must have a minibuffer window.  How else should
 >> `read-minibuffer' work?
 >
 > It can read from the minibuffer in a standalone minibuffer frame?

Is this a question or an answer?

 > That's what I was guessing, that a frame's `minibuffer' parameter might be
 > non-nil but it somehow has a minibuffer _window_.  Seems odd, but I guess these
 > things are at two different levels.  I am used to the Lisp & frame level - I
 > know almost nothing about the C & window level.

Emacs must be able to work internally even if you make all your frames
minibuffer-less.

 >> `mouse-leave-buffer-hook' and in a `pre-' or
 >> `post-command-hook' check whether that something got executed.
 >> Then you can be sure that somewhere in between a
 >> `handle-switch-frame' interfered.
 >
 > Sorry, I don't follow you (and I haven't found where you suggested something
 > similar earlier).  If you can be more specific I'll be glad to try whatever you
 > ask.

When you want to check of `handle-switch-frame' executions you cannot
trace otherwise and you do not run emacs in the debugger, the most
simple way to trace these is to put some function on
`mouse-leave-buffer-hook', and inspect the output of that function later
on.

 > All I meant was that (I'm guessing that):
 >
 > a. Emacs asks the question, directing focus to the minibuffer frame for the user
 > to input a response.
 >
 > b. MS Windows creates the new frame and gives it the focus, taking the focus
 > away from the minibuffer.

I can live with that assumption.

 >>  > As I mentioned in my other reply today, you can, when the
 >>  > minibuffer is active, explicitly switch the focus to the
 >>  > *Completions* frame, to do something there
 >>  > (e.g. move to some completion candidate).
 >>
 >> Which function precisely does that?
 >
 > With just oneonone.el loaded (which creates a standalone minibuffer and
 > special-display *Help* and *Completions*, with the latter frame redirected to
 > the minibuffer frame), even just `C-x o' during completion will do it.  I.e.,
 > from the minibuffer, `C-x o' moves you (focus) to *Completions*.
 >
 > Or you can click *Completions* with the mouse - same effect.
 >
 > In Icicles, you can use C-<insert> to flip back and forth between the minibuffer
 > and *Completions*.  C-<insert> is command `switch-to-*Completions*' in the
 > minibuffer completion keymaps, and C-<insert> is command
 > `icicle-insert-completion' in keymap `completion-list-mode-map'.

I see.  On first reading I missed the term "explictly".  IIUC what we
need is a mechansim that switches frames implicitly to the minibuffer
frame.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[Drew Adams]

>  >> Usually, each frame must have a minibuffer window.  How 
>  >> else should `read-minibuffer' work?
>  >
>  > It can read from the minibuffer in a standalone minibuffer frame?
> 
> Is this a question or an answer?

An answer, followed by "Is that not correct?", since I'm not sure we're talking
about the same thing.  I would expect that it is obvious to you too that Emacs
can read from a minibuffer in a standalone frame.  And it's not clear to me why
that possibility is not an answer to your question.

Keep in mind that I do not understand windows, including minibuffer windows, at
the level you do.

>  > That's what I was guessing, that a frame's `minibuffer' 
>  > parameter might be non-nil but it somehow has a minibuffer 
>  > _window_.  Seems odd, but I guess these things are at two
>  > different levels.  I am used to the Lisp & frame level - I
>  > know almost nothing about the C & window level.
> 
> Emacs must be able to work internally even if you make all your frames
> minibuffer-less.

I never claimed otherwise.  But I don't see the relation here.  And I do not
make all my frames minibuffer-less.  So I guess I'm not following you very well.

>  >> `mouse-leave-buffer-hook' and in a `pre-' or
>  >> `post-command-hook' check whether that something got executed.
>  >> Then you can be sure that somewhere in between a
>  >> `handle-switch-frame' interfered.
>  >
>  > Sorry, I don't follow you (and I haven't found where you 
>  > suggested something similar earlier).  If you can be more
>  > specific I'll be glad to try whatever you ask.
> 
> When you want to check of `handle-switch-frame' executions you cannot
> trace otherwise and you do not run emacs in the debugger, the most
> simple way to trace these is to put some function on
> `mouse-leave-buffer-hook', and inspect the output of that 
> function later on.

OK, but I still do not know what you would like me to do/test.  Can you give me
a recipe to test?

> I see.  On first reading I missed the term "explictly".  IIUC what we
> need is a mechansim that switches frames implicitly to the minibuffer
> frame.

Yes, I think so.  But the trick might be to do this only when it should be done.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[martin rudalics]

 >>  >> Usually, each frame must have a minibuffer window.  How
 >>  >> else should `read-minibuffer' work?
 >>  >
 >>  > It can read from the minibuffer in a standalone minibuffer frame?
 >>
 >> Is this a question or an answer?
 >
 > An answer, followed by "Is that not correct?", since I'm not sure we're talking
 > about the same thing.  I would expect that it is obvious to you too that Emacs
 > can read from a minibuffer in a standalone frame.  And it's not clear to me why
 > that possibility is not an answer to your question.

But then you didn't answer my initial question.  I didn't ask about
standalone frames only, I asked about "each" frame.

 >>  > That's what I was guessing, that a frame's `minibuffer'
 >>  > parameter might be non-nil but it somehow has a minibuffer
 >>  > _window_.  Seems odd, but I guess these things are at two
 >>  > different levels.  I am used to the Lisp & frame level - I
 >>  > know almost nothing about the C & window level.
 >>
 >> Emacs must be able to work internally even if you make all your frames
 >> minibuffer-less.
 >
 > I never claimed otherwise.  But I don't see the relation here.  And I do not
 > make all my frames minibuffer-less.  So I guess I'm not following you very well.

When you exit emacs deleting its last frame, there might be an internal
state where only a minibuffer less frame remains.  And that may cause
a(n unwanted) crash IIUC.

 >>  >> `mouse-leave-buffer-hook' and in a `pre-' or
 >>  >> `post-command-hook' check whether that something got executed.
 >>  >> Then you can be sure that somewhere in between a
 >>  >> `handle-switch-frame' interfered.
 >>  >
 >>  > Sorry, I don't follow you (and I haven't found where you
 >>  > suggested something similar earlier).  If you can be more
 >>  > specific I'll be glad to try whatever you ask.
 >>
 >> When you want to check of `handle-switch-frame' executions you cannot
 >> trace otherwise and you do not run emacs in the debugger, the most
 >> simple way to trace these is to put some function on
 >> `mouse-leave-buffer-hook', and inspect the output of that
 >> function later on.
 >
 > OK, but I still do not know what you would like me to do/test.  Can you give me
 > a recipe to test?

No.  All I did was to reply to an issue you raised earlier - that of
`handle-switch-frame' possibly interfering with "normal" execution of
commands.  And I said that IMHO the most simple way to notice whether
`handle-switch-frame' got executed in between is to put a function on
`mouse-leave-buffer-hook'.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[Drew Adams]

>  >>  >> Usually, each frame must have a minibuffer window.  How
>  >>  >> else should `read-minibuffer' work?
>  >>  >
>  >>  > It can read from the minibuffer in a standalone minibuffer frame?
>  >>
>  >> Is this a question or an answer?
>  >
>  > An answer, followed by "Is that not correct?", since I'm 
>  > not sure we're talking about the same thing.  I would expect that
>  > it is obvious to you too that Emacs can read from a minibuffer in a
>  > standalone frame.  And it's not clear to me why
>  > that possibility is not an answer to your question.
> 
> But then you didn't answer my initial question.  I didn't ask about
> standalone frames only, I asked about "each" frame.

I was saying only that using a standalone minibuffer frame is a case where it is
not true that each frame has a minibuffer.  And yet it is a case works.  That's
all I was pointing out.

Whether a frame with nil `minibuffer' parameter might actually have a minibuffer
_window_ is not something I know about, as I said.  I'm sure I'm not saying
anything here that you are not aware of, so if this part is only a word game for
you then let's move on, please.

>  >>  > That's what I was guessing, that a frame's `minibuffer'
>  >>  > parameter might be non-nil but it somehow has a minibuffer
>  >>  > _window_.  Seems odd, but I guess these things are at two
>  >>  > different levels.  I am used to the Lisp & frame level - I
>  >>  > know almost nothing about the C & window level.
>  >>
>  >> Emacs must be able to work internally even if you make 
>  >> all your frames minibuffer-less.
>  >
>  > I never claimed otherwise.  But I don't see the relation 
>  > here.  And I do not make all my frames minibuffer-less.
>  > So I guess I'm not following you very well.
> 
> When you exit emacs deleting its last frame, there might be an internal
> state where only a minibuffer less frame remains.  And that may cause
> a(n unwanted) crash IIUC.

OK.  Do you see me saying anything that contradicts that?  I do not understand
what the point is here - what it is that we are discussing.  I am not disputing
anything I hear you to be saying.

>  >>  >> `mouse-leave-buffer-hook' and in a `pre-' or
>  >>  >> `post-command-hook' check whether that something got executed.
>  >>  >> Then you can be sure that somewhere in between a
>  >>  >> `handle-switch-frame' interfered.
>  >>  >
>  >>  > Sorry, I don't follow you (and I haven't found where you
>  >>  > suggested something similar earlier).  If you can be more
>  >>  > specific I'll be glad to try whatever you ask.
>  >>
>  >> When you want to check of `handle-switch-frame' executions you cannot
>  >> trace otherwise and you do not run emacs in the debugger, the most
>  >> simple way to trace these is to put some function on
>  >> `mouse-leave-buffer-hook', and inspect the output of that
>  >> function later on.
>  >
>  > OK, but I still do not know what you would like me to 
>  > do/test.  Can you give me a recipe to test?
> 
> No.  All I did was to reply to an issue you raised earlier - that of
> `handle-switch-frame' possibly interfering with "normal" execution of
> commands.  And I said that IMHO the most simple way to notice whether
> `handle-switch-frame' got executed in between is to put a function on
> `mouse-leave-buffer-hook'.

I see.

But as I said earlier, I already determined that `h-s-f' was in fact the current
(i.e., last) command when `1on1-fit-minibuffer-frame' kicked in from
`post-command-hook'.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

 > (But the *Process List* frame that was popped up was completely
 > hidden behind the frame that was selected when I hit C-x C-c.  That's not good.)

Because that code was for experimental purposes only.  It's not the task
of `with-temp-buffer-window' or its callers to handle that.  The problem
is elsewhere.  I attach the first version of `with-temp-buffer-window',
however, with a redefined `y-or-n-p'.  Try it with your code but with
`yes-or-no-p' aliased to `y-or-n-p'.

Here, with emacs -Q

(progn
   (defalias 'yes-or-no-p 'y-or-n-p)
   (load "~/with-temp-buffer-window.el")
   (shell)
   (setq minibuffer-auto-raise t)
   (setq pop-up-frame-function
	(lambda () (make-frame '((minibuffer . nil)))))
   (setq pop-up-frames t))

C-x C-c creates a minibuffer-less frame for *Process List* and
redirects the prompt to the initial *shell* frame.  Not 100% perfect
because the *shell* frame partly obscures the *Process List* frame but
this could be tweaked with a better `pop-up-frame-function'.  With the
more conventional

(progn
   (defalias 'yes-or-no-p 'y-or-n-p)
   (load "~/with-temp-buffer-window.el")
   (shell)
   (setq pop-up-frames t))

the prompt appears in the *Process List* window.

So I suppose that we should (at least optionally) have all functions
accessing the minibuffer redirect frame focus to it first.

martin

[-- Attachment #2: with-temp-buffer-window.el --]
[-- Type: application/emacs-lisp, Size: 24132 bytes --]

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> I attach the first version of `with-temp-buffer-window',
> however, with a redefined `y-or-n-p'.  Try it with your code but with
> `yes-or-no-p' aliased to `y-or-n-p'.
> 
> Here, with emacs -Q
> (progn
>    (defalias 'yes-or-no-p 'y-or-n-p)
>    (load "~/with-temp-buffer-window.el")
>    (shell)
>    (setq minibuffer-auto-raise t)
>    (setq pop-up-frame-function
> 	(lambda () (make-frame '((minibuffer . nil)))))
>    (setq pop-up-frames t))

I did this:

1. Used my setup.  Then did the defalias.  Then loaded your file.  Then `M-x
shell'.  Then `C-x C-c'.  Then `y'.  No problem.

2. emacs -Q, then used your code above, but first loaded cygwin-mount.el and
setup-cygwin.el.  C-x C-c.  No problem.

HTH.

BTW, you did not answer my question of how you get shell etc. to work on Windows
with emacs -Q and without Cygwin.  I'm still interested to learn what you are
doing in that regard.

> I suppose that we should (at least optionally) have all functions
> accessing the minibuffer redirect frame focus to it first.

I thought that was already the case - it seems to be.  In the problem reported
for this bug the minibuffer frame had the focus, but it then lost it because of
a frame switch (I mean, because a new frame creation by Windows switched the
focus).

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]

 > 1. Used my setup.  Then did the defalias.  Then loaded your file.  Then `M-x
 > shell'.  Then `C-x C-c'.  Then `y'.  No problem.

See below.

 > BTW, you did not answer my question of how you get shell etc. to work on Windows
 > with emacs -Q and without Cygwin.  I'm still interested to learn what you are
 > doing in that regard.

I'm using cmd.exe.

 >> I suppose that we should (at least optionally) have all functions
 >> accessing the minibuffer redirect frame focus to it first.
 >
 > I thought that was already the case - it seems to be.  In the problem reported
 > for this bug the minibuffer frame had the focus, but it then lost it because of
 > a frame switch (I mean, because a new frame creation by Windows switched the
 > focus).

As a matter of fact `yes-or-no-p' indirectly calls read_minibuf which does

   if (!EQ (mini_frame, selected_frame))
     Fredirect_frame_focus (selected_frame, mini_frame);

So focus is redirected but somehow this doesn't always work when popping
up a new frame.  In any case, it's not necessary to do the defaliasing,
`yes-or-no-p' should do the same, in principle.  Moreover, my
`redirect-frame-focus' call in `y-or-n-p' was silly because I mixed up
the arguments.  So let's forget about this.

I still don't understand the consequences described in the doc-string of
`redirect-frame-focus' as

    A frame's focus redirection can be changed by `select-frame'.  If frame
    FOO is selected, and then a different frame BAR is selected, any
    frames redirecting their focus to FOO are shifted to redirect their
    focus to BAR.  This allows focus redirection to work properly when the
    user switches from one frame to another using `select-window'.

    This means that a frame whose focus is redirected to itself is treated
    differently from a frame whose focus is redirected to nil; the former
    is affected by `select-frame', while the latter is not.

so there might be still some surprises around the corner.

IMHO the thing that's crucial is that if you want to peruse a separate
minibuffer frame after popping up a new frame, you have to do it from
the freshly popped up frame.  For example, if you pop up a new frame and
then want to ask a `yes-or-no-p' question, you have to select the new
frame, issue the `yes-or-no-p' there, and hope that read_minibuf
correctly redirects the prompt to the minibuffer frame.  If
`minibuffer-auto-raise' is non-nil, this will raise the minibuffer
frame, otherwise it will only redirect input to that frame.  I suppose
that was already your understanding of this issue but I was surprised
that issuing the `yes-or-no-p' from an old frame won't work.

So I attach yet another version of `with-temp-buffer-window'.  Please
test it with

(progn
   (load "~/with-temp-buffer-window.el")
   (shell)
   (setq minibuffer-auto-raise t) ; Optional
   (setq pop-up-frame-function (lambda () (make-frame '((minibuffer . nil)))))
   (setq pop-up-frames t))

(progn
   (setq pop-up-frames t)
   (load "~/with-temp-buffer-window.el")
   (shell))

and with your usual settings and tell me what you see.  Also test it
with `minibuffer-auto-raise' either nil or t.  Finally, try to exit it
in various ways, for example by deleting some frame during the dialogue.
I found a not yet 100% reproducible way to crash Emacs doing that.

If the above work, test also the delete files in dired scenario.  The
first dialogue will probably fail in the usual way, then you have to
load `with-temp-buffer-window.el' once more and try another time.

Thanks, martin

[-- Attachment #2: with-temp-buffer-window.el --]
[-- Type: application/emacs-lisp, Size: 21692 bytes --]

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> I'm using cmd.exe.

How?  What are you doing to not get this error, which I get when I use emacs -Q
without loading the Cygwin stuff?

 "Spawning child process: invalid argument"

>  >> I suppose that we should (at least optionally) have all functions
>  >> accessing the minibuffer redirect frame focus to it first.
>  >
>  > I thought that was already the case - it seems to be.  In the problem
>  > reported for this bug the minibuffer frame had the focus, but it then
>  > lost it because of a frame switch (I mean, because a new frame
>  > creation by Windows switched the focus).
> 
> As a matter of fact `yes-or-no-p' indirectly calls 
> read_minibuf which does
> 
>    if (!EQ (mini_frame, selected_frame))
>      Fredirect_frame_focus (selected_frame, mini_frame);
> 
> So focus is redirected but somehow this doesn't always work 
> when popping up a new frame.

Yes, that's more or less what I was trying to say.  My guess is still that it
does get redirected but when the frame is popped up the new frame takes the
focus.  IOW, that redirection was from the frame that was selected before the
popped-up frame gets selected/focused.  Just a guess, based on what I've seen.

> In any case, it's not necessary to do the defaliasing,
> `yes-or-no-p' should do the same, in principle.  Moreover, my
> `redirect-frame-focus' call in `y-or-n-p' was silly because I mixed up
> the arguments.  So let's forget about this.

Forgotten.

> I still don't understand the consequences described in the 
> doc-string of `redirect-frame-focus' as
> 
>     A frame's focus redirection can be changed by `select-frame'.
>     If frame FOO is selected, and then a different frame BAR is
>     selected, any frames redirecting their focus to FOO are shifted
>     to redirect their focus to BAR.  This allows focus redirection
>     to work properly when the user switches from one frame to another
>     using `select-window'.

I think that last part means only that focus switches when you select a frame,
even if the previously selected frame was not really selected but had the focus
only via a redirection from the actually selected frame.

>     This means that a frame whose focus is redirected to itself is
>     treated differently from a frame whose focus is redirected to 
>     nil; the former is affected by `select-frame', while the latter is not.

It does not say what does affect the latter.  Not too clear to me.

> so there might be still some surprises around the corner.
> 
> IMHO the thing that's crucial is that if you want to peruse a separate
> minibuffer frame after popping up a new frame, you have to do it from
> the freshly popped up frame.

Sounds reasonable.  What might (?) be good would be to find a way to simply
counteract (undo) the auto-focus/selection of the new frame whenever focus was
in the minibuffer frame (and the minibuffer is active).  IOW, perhaps that can
be done automatically.  Dunno whether doing that systematically would be a good
idea or not (or whether it is easy to do).

> For example, if you pop up a new frame and
> then want to ask a `yes-or-no-p' question, you have to select the new
> frame, issue the `yes-or-no-p' there,

Yes, that would be one way of solving the problem, perhaps, if we could ensure
that that happened.  But the ordering of such events might be fragile - and it
might depend on the platform etc.

> and hope that read_minibuf correctly redirects the prompt to the minibuffer
frame.

My guess is that it does, always.  Again, my guess is that it did that
correctly, but the new frame was then created (the creation might have started
before the read_minibuf, but the new focus took effect after the redirection to
the minibuffer, in any case).  Just a guess.

> If `minibuffer-auto-raise' is non-nil, this will raise the minibuffer
> frame, otherwise it will only redirect input to that frame.  I suppose
> that was already your understanding of this issue but I was surprised
> that issuing the `yes-or-no-p' from an old frame won't work.

I'll have to get to the rest of your message(s) a bit later.  Thx.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > How?  What are you doing to not get this error, which I get when I use emacs -Q
 > without loading the Cygwin stuff?
 >
 >  "Spawning child process: invalid argument

No idea.  Maybe this is the Powershell issue described in

http://tb-nguyen.blogspot.co.at/2010/05/how-to-fix-emacs-windows-error-spawning.html

I just checked on a SP3 machine and am sure that just installing SP3 is
not sufficient for the problem to show up.

 >> I still don't understand the consequences described in the
 >> doc-string of `redirect-frame-focus' as
 >>
 >>     A frame's focus redirection can be changed by `select-frame'.
 >>     If frame FOO is selected, and then a different frame BAR is
 >>     selected, any frames redirecting their focus to FOO are shifted
 >>     to redirect their focus to BAR.  This allows focus redirection
 >>     to work properly when the user switches from one frame to another
 >>     using `select-window'.
 >
 > I think that last part means only that focus switches when you select a frame,
 > even if the previously selected frame was not really selected but had the focus
 > only via a redirection from the actually selected frame.

It seems to say that when a frame X has focus redirected to the selected
frame A and I now select a frame B then focus for X is redirected to B.

But why is that useful?

 >>     This means that a frame whose focus is redirected to itself is
 >>     treated differently from a frame whose focus is redirected to
 >>     nil; the former is affected by `select-frame', while the latter is not.
 >
 > It does not say what does affect the latter.  Not too clear to me.

It seems to say that when a selected frame A's focus is redirected to A
itself and I now select frame B, focus from A is redirected to B.  Now
suppose a minibuffer-only frame is selected and had focus directed to
itself. If now a minibuffer-less frame gets selected, focus will be
directed to that frame which hardly makes sense to me.

 >> so there might be still some surprises around the corner.
 >>
 >> IMHO the thing that's crucial is that if you want to peruse a separate
 >> minibuffer frame after popping up a new frame, you have to do it from
 >> the freshly popped up frame.
 >
 > Sounds reasonable.  What might (?) be good would be to find a way to simply
 > counteract (undo) the auto-focus/selection of the new frame whenever focus was
 > in the minibuffer frame (and the minibuffer is active).  IOW, perhaps that can
 > be done automatically.  Dunno whether doing that systematically would be a good
 > idea or not (or whether it is easy to do).

Someone (maybe Jan) once said that it's hard to override any such
decisions when they are made by the window manager.

 >> For example, if you pop up a new frame and
 >> then want to ask a `yes-or-no-p' question, you have to select the new
 >> frame, issue the `yes-or-no-p' there,
 >
 > Yes, that would be one way of solving the problem, perhaps, if we could ensure
 > that that happened.  But the ordering of such events might be fragile - and it
 > might depend on the platform etc.

IIUC creating a WM window (via CreateWindow) returns a handle to a new
WM window independently from whether that window already appears on the
screen and/or obscures other windows.  I don't know whether and how the
window manager informs Emacs that a window has appeared on the screen.
I suppose it doesn't and that information is passed to emacs implicitly
when the user "selects" that window by using the keyboard or the mouse.

 >> and hope that read_minibuf correctly redirects the prompt to the minibuffer
 > frame.
 >
 > My guess is that it does, always.

Apparently not always as we know meanwhile.

 > Again, my guess is that it did that
 > correctly, but the new frame was then created (the creation might have started
 > before the read_minibuf, but the new focus took effect after the redirection to
 > the minibuffer, in any case).  Just a guess.

 From what you said it seems to work as long as no new frames are
created.  When a new frame is created, it may take some time for this
mechanism to adapt itself to the new configuration.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  >  "Spawning child process: invalid argument
> 
> No idea.  Maybe this is the Powershell issue described in
> http://tb-nguyen.blogspot.co.at/2010/05/how-to-fix-emacs-windo
> ws-error-spawning.html
> 
> I just checked on a SP3 machine and am sure that just 
> installing SP3 is not sufficient for the problem to show up.

I do not have/use Powershell, AFAIK.  But I see that my env var SHELL has the
value "/bin/bash".  That is no doubt the cause.

>  >> I still don't understand the consequences described in the
>  >> doc-string of `redirect-frame-focus' as
>  >>
>  >>     A frame's focus redirection can be changed by `select-frame'.
>  >>     If frame FOO is selected, and then a different frame BAR is
>  >>     selected, any frames redirecting their focus to FOO 
>  >>     are shifted to redirect their focus to BAR.  This allows focus
>  >>     redirection to work properly when the user switches from one 
>  >>     frame to another using `select-window'.
>  >
>  > I think that last part means only that focus switches when 
>  > you select a frame, even if the previously selected frame
>  > was not really selected but had the focus
>  > only via a redirection from the actually selected frame.
> 
> It seems to say that when a frame X has focus redirected to 
> the selected frame A and I now select a frame B then focus
> for X is redirected to B.  But why is that useful?

The reason given is to pass redirection on, when you switch to another frame.
But I agree that it is not clear, and I too wonder about the usefulness.

I would think that redirection should be a simple mapping from one frame to
another.

Now maybe what was really meant is that if X redirects to Y and Y redirects to Z
then X ends up redirecting to Z.  That would make sense (and also go without
saying).  Dunno.

>  >>     This means that a frame whose focus is redirected to itself is
>  >>     treated differently from a frame whose focus is redirected to
>  >>     nil; the former is affected by `select-frame', while 
>  >>     the latter is not.
>  >
>  > It does not say what does affect the latter.  Not too clear to me.
> 
> It seems to say that when a selected frame A's focus is 
> redirected to A itself and I now select frame B, focus from A is
> redirected to B.

Yes, I think it says that.  And it says that a frame that is redirected to nil
is not affected by select-frame.  (It does not say what does affect a frame that
is redirected to nil.)

> Now suppose a minibuffer-only frame is selected and had focus directed to
> itself. If now a minibuffer-less frame gets selected, focus will be
> directed to that frame which hardly makes sense to me.

I agree.  But why would someone redirect the minibuffer frame's focus to itself?
What are you envisioning?

FWIW, the only redirection that I use (AFAIK) is to redirect my *Completions*
(special-display) frame to the minibuffer frame.  That seems to work just as I
would expect - no problems.

But nothing prevents you from explicitly selecting *Completions* and even trying
to type input there, even when the minibuffer is active.  But *Completions* is
read-only, so if you do that you get a read-only error.

For example, in the minibuffer, Icicle mode binds `C-insert' to a command that
does (select-window (get-buffer-window "*Completions*" 0)).  You can do various
things there, but if you try to type a self-inserting char or delete a char then
you get this error: "Buffer is read-only: #<buffer *Completions*>".

> Someone (maybe Jan) once said that it's hard to override any such
> decisions when they are made by the window manager.

I did not mean override (prevent/nullify).  I meant automatically take remedial
action after the window manager's autofocus takes effect.  I.e., automatically
move the focus back where it was.

But again, I have no idea whether (a) that is easy to do or (b) whether it is
really a good idea to do it.

> IIUC creating a WM window (via CreateWindow) returns a handle to a new
> WM window independently from whether that window already 
> appears on the screen and/or obscures other windows.
>
> I don't know whether and how the window manager informs Emacs
> that a window has appeared on the screen.  I suppose it doesn't
> and that information is passed to emacs implicitly
> when the user "selects" that window by using the keyboard or 
> the mouse.

How does Emacs determine the selected frame?  Doesn't the code of
`selected-frame' help understand this?

>  >> and hope that read_minibuf correctly redirects the prompt 
>  >> to the minibuffer frame.
>  >
>  > My guess is that it does, always.
> 
> Apparently not always as we know meanwhile.

I did not really mean "redirects the prompt".  I was thinking of it moving the
input focus (which would also put the prompt where that focus is, presumably).

My guess was/is that it might always move the focus to the minibuffer frame, but
that the focus is then moved away from it to the new frame that is popped up.

How do you know that that is not what happens?  I.e., how do you know that there
are some situations where the focus is *not* (initially) switched to the
minibuffer frame?  (I'm not saying you are wrong - just wondering how you know
that.) 

>  > Again, my guess is that it did that
>  > correctly, but the new frame was then created (the 
>  > creation might have started before the read_minibuf, but the
>  > new focus took effect after the redirection to
>  > the minibuffer, in any case).  Just a guess.
> 
> From what you said it seems to work as long as no new frames are
> created.  When a new frame is created, it may take some time for this
> mechanism to adapt itself to the new configuration.

Perhaps, but waiting does not help.  Perhaps you meant that there is some
timeout and if things are too slow then the focus is automatically moved to the
new frame?

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > Now maybe what was really meant is that if X redirects to Y and Y redirects to Z
 > then X ends up redirecting to Z.  That would make sense (and also go without
 > saying).  Dunno.

Maybe because it would be too easy to introduce circular redirection
this way.

 >> Now suppose a minibuffer-only frame is selected and had focus directed to
 >> itself. If now a minibuffer-less frame gets selected, focus will be
 >> directed to that frame which hardly makes sense to me.
 >
 > I agree.  But why would someone redirect the minibuffer frame's focus to itself?

Indeed, that would not be reasonable.

 > What are you envisioning?

I was only speculating.

 >> Someone (maybe Jan) once said that it's hard to override any such
 >> decisions when they are made by the window manager.
 >
 > I did not mean override (prevent/nullify).  I meant automatically take remedial
 > action after the window manager's autofocus takes effect.  I.e., automatically
 > move the focus back where it was.

I'm not quite sure what "after" means in this context.  IIUC Emacs is
not informed that the frame has been posted on screen.  It will know
about it only implicitly when it's passed input directed to that frame.

 >> IIUC creating a WM window (via CreateWindow) returns a handle to a new
 >> WM window independently from whether that window already
 >> appears on the screen and/or obscures other windows.
 >>
 >> I don't know whether and how the window manager informs Emacs
 >> that a window has appeared on the screen.  I suppose it doesn't
 >> and that information is passed to emacs implicitly
 >> when the user "selects" that window by using the keyboard or
 >> the mouse.
 >
 > How does Emacs determine the selected frame?  Doesn't the code of
 > `selected-frame' help understand this?

Emacs selects a new frame.  But if it's minibufferless, it doesn't
necesarily redirect input to the minibuffer frame.  IIUC it does so only
when it reads input from that frame.

 > I did not really mean "redirects the prompt".  I was thinking of it moving the
 > input focus (which would also put the prompt where that focus is, presumably).

I suppose we mean the same here.

 > My guess was/is that it might always move the focus to the minibuffer frame, but
 > that the focus is then moved away from it to the new frame that is popped up.

The window manager moves the focus to the new frame and Emacs selects
it.  But Emacs apparently does not redirect input focus.

 > How do you know that that is not what happens?  I.e., how do you know that there
 > are some situations where the focus is *not* (initially) switched to the
 > minibuffer frame?  (I'm not saying you are wrong - just wondering how you know
 > that.)

I have no other explanation.

 >> From what you said it seems to work as long as no new frames are
 >> created.  When a new frame is created, it may take some time for this
 >> mechanism to adapt itself to the new configuration.
 >
 > Perhaps, but waiting does not help.  Perhaps you meant that there is some
 > timeout and if things are too slow then the focus is automatically moved to the
 > new frame?

My speculation is still the same: The window manager focuses the new
frame and Emacs does not redirect input to the minibuffer frame.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  >> Someone (maybe Jan) once said that it's hard to override any such
>  >> decisions when they are made by the window manager.
>  >
>  > I did not mean override (prevent/nullify).  I meant 
>  > automatically take remedial action after the window manager's
>  > autofocus takes effect.  I.e., automatically
>  > move the focus back where it was.
> 
> I'm not quite sure what "after" means in this context.  IIUC Emacs is
> not informed that the frame has been posted on screen.  It will know
> about it only implicitly when it's passed input directed to 
> that frame.

OK.  I really know nothing about this area.

> Emacs selects a new frame.  But if it's minibufferless, it doesn't
> necesarily redirect input to the minibuffer frame.  IIUC it 
> does so only when it reads input from that frame.

I see.  And if reading from the minibuffer was already started (e.g. before the
new frame was actually created) then the new frame will not have its focus
directed to the minibuffer, even though reading is in progress.

> My speculation is still the same: The window manager focuses the new
> frame and Emacs does not redirect input to the minibuffer frame.

OK.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> I attach yet another version of `with-temp-buffer-window'.  Please
> test it with

#1
> (progn
>    (load "~/with-temp-buffer-window.el")
>    (shell)
>    (setq minibuffer-auto-raise t) ; Optional
>    (setq pop-up-frame-function
>          (lambda () (make-frame '((minibuffer . nil)))))
>    (setq pop-up-frames t))

#2
> (progn
>    (setq pop-up-frames t)
>    (load "~/with-temp-buffer-window.el")
>    (shell))
> 
> and with your usual settings and tell me what you see.  Also test it
> with `minibuffer-auto-raise' either nil or t.
>
> If the above work, test also the delete files in dired scenario.  The
> first dialogue will probably fail in the usual way, then you have to
> load `with-temp-buffer-window.el' once more and try another time.

I used my normal setup.  I tried #1.  No problem.  I started again and tried #1
with nil `minibuffer-auto-raise'.  Still no problem.  I tried #2.  Still no
problem.

My setup already has non-nil pop-up-frames, so apparently all that is needed is
your file.  If I comment out the load of your file and try #2 then the bugged
behavior reappears.

So it seems that you have found a solution.

> Finally, try to exit it in various ways, for example by
> deleting some frame during the dialogue.
> I found a not yet 100% reproducible way to crash Emacs doing that.

I could not reproduce that problem.  I was able, after hitting C-x C-c, to click
the corner "X" and thus delete each of the frames.  When I did that on the last
frame (the minibuffer frame), an Emacs popup window gave me the question about
killing active processes (instead of the question appearing in the minibuffer).
I clicked the Yes button.  Emacs exited normally.

Perhaps the crash you see is related to bug #11984, which I see mentioned in
passing?

-----

But I'm sorry to say that I am totally confused now - not by these recent tests
you've had me do with your code, but by the code fix that I reported for my own
code (on 7/16), where I spoke of 3 fixes, each of which worked.

Now, none of them work.  I am certain that before, when I reported them, that
each of the 3 fixes worked.  (And the same is and was true for all Emacs
versions - all worked and now none work.)  I do not understand at all.

It is true that if I do not add that test of (eq last-event-frame (window-frame
(minibuffer-window))), which is fix one I chose, then the *Process List* frame
and buffer are current/selected.  But that test does _not_ solve the focus
problem.  I still cannot type "yes" into the minibuffer frame.

All that happens is that `1on1-fit-minibuffer-frame' does nothing, and that does
not help with the frame focus problem.  Similarly if I, instead of that test,
add the call to `select-frame-set-input-focus' at the end of the function - that
too no longer is a fix.

So I am totally confused.  I am glad at least that you seem to have found a
solution, with your code, for the Emacs 24 case.  I'm disappointed and
incredulous, however, about my own "fix" that does not work, especially because
it worked (on 7/16) in all Emacs versions.  I have no idea what is going on.

And I'm afraid I'm probably just confusing you now with my current reporting.
Calling it a day now.  If I figure something out I'll let you know.  Sorry for
the confusion.

Thx - Drew

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > #1
 >> (progn
 >>    (load "~/with-temp-buffer-window.el")
 >>    (shell)
 >>    (setq minibuffer-auto-raise t) ; Optional
 >>    (setq pop-up-frame-function
 >>          (lambda () (make-frame '((minibuffer . nil)))))
 >>    (setq pop-up-frames t))
 >
 > #2
 >> (progn
 >>    (setq pop-up-frames t)
 >>    (load "~/with-temp-buffer-window.el")
 >>    (shell))
 >>
 >> and with your usual settings and tell me what you see.  Also test it
 >> with `minibuffer-auto-raise' either nil or t.
 >>
 >> If the above work, test also the delete files in dired scenario.  The
 >> first dialogue will probably fail in the usual way, then you have to
 >> load `with-temp-buffer-window.el' once more and try another time.
 >
 > I used my normal setup.  I tried #1.  No problem.  I started again and tried #1
 > with nil `minibuffer-auto-raise'.  Still no problem.  I tried #2.  Still no
 > problem.

You should have tried #1 and #2 with emacs -Q.  Otherwise, your private
settings will shadow #1 and #2 (I tested #1 and #2 here but would like a
confirmation).

 > My setup already has non-nil pop-up-frames, so apparently all that is needed is
 > your file.  If I comment out the load of your file and try #2 then the bugged
 > behavior reappears.
 >
 > So it seems that you have found a solution.

Since you do set `pop-up-frames' to non-nil you have inirectly confirmed
that it works for your setup.

You did not report whether it works for `minibuffer-auto-raise' nil.
Can you look into that?

 >> Finally, try to exit it in various ways, for example by
 >> deleting some frame during the dialogue.
 >> I found a not yet 100% reproducible way to crash Emacs doing that.
 >
 > I could not reproduce that problem.  I was able, after hitting C-x C-c, to click
 > the corner "X" and thus delete each of the frames.  When I did that on the last
 > frame (the minibuffer frame), an Emacs popup window gave me the question about
 > killing active processes (instead of the question appearing in the minibuffer).
 > I clicked the Yes button.  Emacs exited normally.
 >
 > Perhaps the crash you see is related to bug #11984, which I see mentioned in
 > passing?

No. The crash happens because the following assumption in frame.c

	  /* We know that there must be some frame with a minibuffer out
	     there.  If this were not true, all of the frames present
	     would have to be minibufferless, which implies that at some
	     point their minibuffer frames must have been deleted, but
	     that is prohibited at the top; you can't delete surrogate
	     minibuffer frames.  */
	  if (NILP (frame_with_minibuf))
	    abort ();

does not always hold during the exit dialogue.  And it's bad because it
crashes Emacs when I try to avoid the exit because of a running
subprocess.

 > But I'm sorry to say that I am totally confused now - not by these recent tests
 > you've had me do with your code, but by the code fix that I reported for my own
 > code (on 7/16), where I spoke of 3 fixes, each of which worked.
 >
 > Now, none of them work.  I am certain that before, when I reported them, that
 > each of the 3 fixes worked.  (And the same is and was true for all Emacs
 > versions - all worked and now none work.)  I do not understand at all.

Trivial.  At the time you wrote the "fixes" you had "fixed" it already
by doing something else.  Now you "just" have to find out what else you
did then ;-) Are you sure you ran your changes without my file loaded?

 > It is true that if I do not add that test of (eq last-event-frame (window-frame
 > (minibuffer-window))), which is fix one I chose, then the *Process List* frame
 > and buffer are current/selected.  But that test does _not_ solve the focus
 > problem.  I still cannot type "yes" into the minibuffer frame.

If you use Emacs 24.1 without my changes, then `list-processes' will pop
up a new frame and give it focus.  When it now asks the `y-or-n-p'
question you _are_ lost if the new frame does not have a minibuffer and
you can't redirect it to one.

 > All that happens is that `1on1-fit-minibuffer-frame' does nothing, and that does
 > not help with the frame focus problem.  Similarly if I, instead of that test,
 > add the call to `select-frame-set-input-focus' at the end of the function - that
 > too no longer is a fix.

Try explicitly redirecting the focus from the new frame to the
minibuffer-only frame via `redirect-frame-focus'.

 > So I am totally confused.  I am glad at least that you seem to have found a
 > solution, with your code, for the Emacs 24 case.  I'm disappointed and
 > incredulous, however, about my own "fix" that does not work, especially because
 > it worked (on 7/16) in all Emacs versions.  I have no idea what is going on.

Une solution peut en cacher une autre.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  >> and with your usual settings and tell me what you see.  
> 
> You should have tried #1 and #2 with emacs -Q.

Sorry, I thought that's what you meant by "with your usual settings".

> Otherwise, your private settings will shadow #1 and #2 
> (I tested #1 and #2 here but would like a confirmation).

#1 (emacs -Q): No problem.

#2 (emacs -Q): Does not work. The *Process List* frame is in front, and the
question is posed in the minibuffer of the *shell* frame.  Typing seems to go
nowhere, but when I hit RET after typing I get this error msg:

yes-or-no-p: Buffer is read-only: #<buffer *Process List*>

Interestingly, If I then try C-x C-c from *Messages*, after manually bring that
frame to the front, then again *Process List* is moved to the front and the
question is posed in the *Messages* frame.  I expect that info might help, and
perhaps you guessed already that that would happen.

> You did not report whether it works for `minibuffer-auto-raise' nil.
> Can you look into that?

It is nil by default, no?  So the tests for #2 test that.

But #1 with the value nil works also.  The only difference is that with the
value nil the *Process List* frame is foremost (in front), and with it t the
*shell* frame is in foremost.

It's a choice, I guess, whether it is more important to see all of the question
(prompt) or to see the *Process List* buffer completely.  I'm not sure I have a
settled opinion about that.

In the case of emacs -Q, where there is no standalone minibuffer frame, I think
the best behavior (if possible) would be to have the question appear in the
minibuffer of the *Process List* frame (and have that frame be foremost).

In the case of a standalone minibuffer frame, the best behavior is probably to
always have the minibuffer frame foremost (at least when it asks a question).
Typically, a user with a standalone m. frame has it positioned out of the way as
much as possible.  In my case, for instance, it stretches across the bottom of
my screen (and new frames are popped up by the window mgr at or near the top of
the screen).

>  > Perhaps the crash you see is related to bug #11984, which 
>  > I see mentioned in passing?
> 
> No. The crash happens because the following assumption in frame.c
> 
> 	  /* We know that there must be some frame with a minibuffer out
> 	     there.  If this were not true, all of the frames present
> 	     would have to be minibufferless, which implies that at some
> 	     point their minibuffer frames must have been deleted, but
> 	     that is prohibited at the top; you can't delete surrogate
> 	     minibuffer frames.  */
> 	  if (NILP (frame_with_minibuf))
> 	    abort ();
> 
> does not always hold during the exit dialogue.  And it's bad 
> because it crashes Emacs when I try to avoid the exit because
> of a running subprocess.

Got it.  I don't get a crash (on MS Windows).  Are you seeing the crash on MS
Windows also?

> Trivial.  At the time you wrote the "fixes" you had "fixed" it already
> by doing something else.  Now you "just" have to find out 
> what else you did then ;-) Are you sure you ran your changes without
> my file loaded?

No, I'm not sure.  In fact, I thought about that after sending my last mail (I
was tired at the time).  And looking over the thread I see now that I must have
been loading your (earlier) code also.  The problem I was looking into at the
time was why your code made things work with emacs -Q but not with my setup.
The fix to my code no doubt enabled your fix to do its job.

But I thought that I had tested with all Emacs versions, and they all worked
after my fix.  I'll have to revisit this when I get some time.  I imagine that
your code is applicable only to Emacs 24+ (is that right?), so it could not have
helped fix things with my setup for other Emacs versions.

> If you use Emacs 24.1 without my changes, then `list-processes' will
> pop up a new frame and give it focus.  When it now asks the `y-or-n-p'
> question you _are_ lost if the new frame does not have a minibuffer and
> you can't redirect it to one.

Got it.  What about other Emacs releases - are relevant at all in this context?
Should we expect that your code can help them also?

>  > All that happens is that `1on1-fit-minibuffer-frame' does 
>  > nothing, and that does not help with the frame focus problem.
>  > Similarly if I, instead of that test, add the call to
>  > `select-frame-set-input-focus' at the end of the function - that
>  > too no longer is a fix.
> 
> Try explicitly redirecting the focus from the new frame to the
> minibuffer-only frame via `redirect-frame-focus'.

Where?  At the end of `1on1-fit-minibuffer-frame', instead of
`select-frame-set-input-focus'?

And would this be in order to try to make things work even without your code
(e.g., for older Emacs versions)?  Because if not I do not need to do it, since
the code I have now already works well in Emacs 24, when I use your code also.

IOW, I'm not clear what you are suggesting, and what problem it might solve.  If
it is a possible cure for the problem in other Emacs versions, e.g. without your
code, then I'll definitely try it.

> Une solution peut en cacher une autre.

:-D   Ca y est.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > #2 (emacs -Q): Does not work. The *Process List* frame is in front, and the
 > question is posed in the minibuffer of the *shell* frame.  Typing seems to go
 > nowhere, but when I hit RET after typing I get this error msg:
 >
 > yes-or-no-p: Buffer is read-only: #<buffer *Process List*>
 >
 > Interestingly, If I then try C-x C-c from *Messages*, after manually bring that
 > frame to the front, then again *Process List* is moved to the front and the
 > question is posed in the *Messages* frame.  I expect that info might help, and
 > perhaps you guessed already that that would happen.

Are you sure you started Emacs again before you went through

(progn
   (setq pop-up-frames t)
   (load "~/with-temp-buffer-window.el")
   (shell))

Here I get a new frame in the foreground, focussed, with the process
list in its root window and the `yes-or-no-p' prompt in its minibuffer
window.  Please try once more.  If this does not work on your system, we
might have a smoking gun.

 >> You did not report whether it works for `minibuffer-auto-raise' nil.
 >> Can you look into that?
 >
 > It is nil by default, no?  So the tests for #2 test that.

It's a NOOP for #2.

 > But #1 with the value nil works also.  The only difference is that with the
 > value nil the *Process List* frame is foremost (in front), and with it t the
 > *shell* frame is in foremost.
 >
 > It's a choice, I guess, whether it is more important to see all of the question
 > (prompt) or to see the *Process List* buffer completely.  I'm not sure I have a
 > settled opinion about that.

Occasionally they obscure each other.

 > In the case of emacs -Q, where there is no standalone minibuffer frame, I think
 > the best behavior (if possible) would be to have the question appear in the
 > minibuffer of the *Process List* frame (and have that frame be foremost).

That's what happens here in scenario #2.

 > In the case of a standalone minibuffer frame, the best behavior is probably to
 > always have the minibuffer frame foremost (at least when it asks a question).
 > Typically, a user with a standalone m. frame has it positioned out of the way as
 > much as possible.  In my case, for instance, it stretches across the bottom of
 > my screen (and new frames are popped up by the window mgr at or near the top of
 > the screen).

In any case, this is what the user may customize via
`minibuffer-auto-raise'.

 > Got it.  I don't get a crash (on MS Windows).  Are you seeing the crash on MS
 > Windows also?

On Windows.

 > But I thought that I had tested with all Emacs versions, and they all worked
 > after my fix.  I'll have to revisit this when I get some time.  I imagine that
 > your code is applicable only to Emacs 24+ (is that right?), so it could not have
 > helped fix things with my setup for other Emacs versions.

Yes.  But maybe you could adapt your buffer display function
accordingly.

 >> If you use Emacs 24.1 without my changes, then `list-processes' will
 >> pop up a new frame and give it focus.  When it now asks the `y-or-n-p'
 >> question you _are_ lost if the new frame does not have a minibuffer and
 >> you can't redirect it to one.
 >
 > Got it.  What about other Emacs releases - are relevant at all in this context?
 > Should we expect that your code can help them also?

If you have an appropriate hook.

 >> Try explicitly redirecting the focus from the new frame to the
 >> minibuffer-only frame via `redirect-frame-focus'.
 >
 > Where?  At the end of `1on1-fit-minibuffer-frame', instead of
 > `select-frame-set-input-focus'?

I think so.

 > And would this be in order to try to make things work even without your code
 > (e.g., for older Emacs versions)?  Because if not I do not need to do it, since
 > the code I have now already works well in Emacs 24, when I use your code also.
 >
 > IOW, I'm not clear what you are suggesting, and what problem it might solve.  If
 > it is a possible cure for the problem in other Emacs versions, e.g. without your
 > code, then I'll definitely try it.

If your `1on1-fit-minibuffer-frame' can hook in after the new frame pops
up, it might be worth a try.  With `temp-output-buffer-show' the only
suitable hook at your disposition is `temp-buffer-show-hook' where
selecting another window won't work because the hook's call is wrapped
in `with-selected-window'.  But you can remember the new frame's window
and select it later, for example, in `post-command-hook'.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> Are you sure you started Emacs again before you went through
> (progn
>    (setq pop-up-frames t)
>    (load "~/with-temp-buffer-window.el")
>    (shell))
> 
> Here I get a new frame in the foreground, focussed, with the process
> list in its root window and the `yes-or-no-p' prompt in its minibuffer
> window.  Please try once more.  If this does not work on your 
> system, we might have a smoking gun.

My bad, I think.  I think what I did was forget to load your code (!).  I tried
again, using emacs -Q with the following, and it did what you say (i.e., no
problem):

(progn
  (load-file "~/drews-lisp-20/contrib/cygwin-mount.el")
  (load-file "~/drews-lisp-20/setup-cygwin.el")

   (setq pop-up-frames t)
   (load "~/with-temp-buffer-window.el")
   (shell))

>  >> You did not report whether it works for 
> `minibuffer-auto-raise' nil.
>  >> Can you look into that?
>  >
>  > It is nil by default, no?  So the tests for #2 test that.
> 
> It's a NOOP for #2.

I tried also with the above code, inserting (setq minibuffer-auto-raise nil)
after (shell).  No problem, and no difference from not having that code.

>  > the best behavior (if possible) would be to have the 
>  > question appear in the minibuffer of the *Process List*
>  > frame (and have that frame be foremost).
> 
> That's what happens here in scenario #2.

Same here.

>  > Got it.  I don't get a crash (on MS Windows).  Are you 
>  > seeing the crash on MS Windows also?
> 
> On Windows.

Hm.

>  > I imagine that your code is applicable only to Emacs 24+
>  > (is that right?), so it could not have
>  > helped fix things with my setup for other Emacs versions.
> 
> Yes.  But maybe you could adapt your buffer display function
> accordingly.

What do you mean?

>  > What about other Emacs releases - are relevant at 
>  > all in this context?
>  > Should we expect that your code can help them also?
> 
> If you have an appropriate hook.

Meaning?  Is this something I can do (how)?

>  >> Try explicitly redirecting the focus from the new frame to the
>  >> minibuffer-only frame via `redirect-frame-focus'.
>  >
>  > Where?  At the end of `1on1-fit-minibuffer-frame', instead of
>  > `select-frame-set-input-focus'?
> 
> I think so.
> 
>  > And would this be in order to try to make things work even 
>  > without your code (e.g., for older Emacs versions)?  Because if
>  > not I do not need to do it, since the code I have now already
>  > works well in Emacs 24, when I use your code also.
>  >
>  > IOW, I'm not clear what you are suggesting, and what 
>  > problem it might solve.  If it is a possible cure for the problem
>  > in other Emacs versions, e.g. without your code, then I'll
>  > definitely try it.
> 
> If your `1on1-fit-minibuffer-frame' can hook in after the new 
> frame pops up, it might be worth a try.  With
> `temp-output-buffer-show' the only suitable hook at your
> disposition is `temp-buffer-show-hook' where selecting another
> window won't work because the hook's call is wrapped in
> `with-selected-window'.  But you can remember the new 
> frame's window and select it later, for example, in
> `post-command-hook'.

I don't understand everything you said, but that's OK - I can refer back to it
later if I need to try to understand more.

I tried adding this at the end of `1on1-fit-minibuffer-frame',
instead of guarding the function with the test
(eq last-event-frame (window-frame (minibuffer-window))):

(redirect-frame-focus last-event-frame
                      (window-frame (minibuffer-window)))

Is that what you meant?

That works, in all Emacs versions, even without your code!  And so does using
this in its place:

(select-frame-set-input-focus
  (window-frame (minibuffer-window)))

(Is there a difference?  What is the advantage of either?)

But there is a problem, for Emacs 23+.  It happens in my setup, with the call to
`redirect-frame-focus' added at the end of `1on1-fit-minibuffer-frame'.  I can
also repro it with a reduced version of my setup - essentially loading
oneonone.el and fit-frame.el and doing (add-hook 'post-command-hook
'1on1-fit-minibuffer-frame) so that I pick up the redirection that is needed.

[BTW, for oneonone.el users who do not use fit-frame.el I suppose I will put the
redirection directly on `post-command-hook', instead of putting it at the end of
`1on1-fit-minibuffer-frame'.  I will no doubt have to use a similar guard: do
nothing unless (a) the minibuffer window is active, (b) the minibuffer frame is
`last-event-frame', and (c) the minibuffer window is alone in its frame.]

Anyway, this the problem:

1. When I do C-x C-c, and respond to the yes/no question, it seems I must wait a
tiny bit before typing yes/no.  Otherwise, the first char (e.g. `y') is lost, so
I end up with just `es' (I see the `y' nowhere).  Not a big deal; just FYI.

2. If I type "no," and then I do `C-x k', then even though *Process List* has
its frame border highlighted as if it is selected, the buffer proposed for
deletion is *shell*.  OK, so I kill *shell*, and confirm ("yes') to kill its
processes also.  (BTW, `C-x k' in my setup also deletes the window/frame.)  So
far, so good.

But if I try to use `C-x k' again to kill *Process List*, then, as soon as I hit
the `k':

a. The default buffer to kill is proposed as some other buffer, not *Process
List* (in my setup the default value is automatically inserted in the
minibuffer, so I can see it without doing M-n).

b. Emacs crashes, but gives no "fatal error" dialog box - hence no way to access
gdb.  It just directly shows the MS Windows dialog box for sending an error
report to MS.  When I click yes/no in that dialog box Emacs exits (disappears).

I can repro this systematically, but there seems to be no way to use gdb.  If I
do something else instead of `C-x k' - e.g. `C-x o', then there is no problem.
I can, for instance, use `C-x o' to move among frames (`C-x o' moves to the
other frame in my setup, if there is no other window on the same frame), coming
eventually to *Process List*, and then use `C-x k' to kill *Process List*.

This crash is reproducible also with Emacs 23.3, not just with the latest Emacs
24 build.  It does not happen with Emacs 22.3, however.  Dunno whether this
crash is related to the crashes you are seeing.

Anyway, it seems we are very close, for my needs.  I suppose I can put that
redirection on `post-command-hook' (instead of in `1on1-fit-minibuffer-frame',
which some oneonone.el users will not use), and things should generally work.  I
will try that next.

Another problem I saw, when I used only a reduced version of my setup, was that
(presumably because of the redirection?) `query-replace' no longer worked: When
I hit `y' or `.' to replace, no replacement occurred.  I will try later to repro
this etc.

I want to get this info off to you now so you can digest it.

Thx - Drew

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 >>  > I imagine that your code is applicable only to Emacs 24+
 >>  > (is that right?), so it could not have
 >>  > helped fix things with my setup for other Emacs versions.
 >>
 >> Yes.  But maybe you could adapt your buffer display function
 >> accordingly.
 >
 > What do you mean?

Write you own version of `special-display-popup-frame' replacing

        (let* ((frame
	       (with-current-buffer buffer
		 (make-frame (append args special-display-frame-alist))))
	      (window (frame-selected-window frame)))
	 (display-buffer-record-window 'frame window buffer)
	 (set-window-dedicated-p window t)

with something like

        (let* ((frame
	       (with-current-buffer buffer
		 (make-frame (append args special-display-frame-alist))))
	      (window (frame-selected-window frame)))
	 (with-selected-window window
	   (redirect-frame-focus frame last-event-frame))
	 (display-buffer-record-window 'frame window buffer)
	 (set-window-dedicated-p window t)

where I used `last-event-frame' because you mentioned it.  I'm not
familiar with that variable.

 >>  > What about other Emacs releases - are relevant at
 >>  > all in this context?
 >>  > Should we expect that your code can help them also?
 >>
 >> If you have an appropriate hook.
 >
 > Meaning?  Is this something I can do (how)?

The above should be applicable to earlier versions to.

 > (redirect-frame-focus last-event-frame
 >                       (window-frame (minibuffer-window)))
 >
 > Is that what you meant?

Not really because I don't understand the semantics of
`last-event-frame' well enough.  But if it works, all the better.

 > That works, in all Emacs versions, even without your code!  And so does using
 > this in its place:
 >
 > (select-frame-set-input-focus
 >   (window-frame (minibuffer-window)))
 >
 > (Is there a difference?  What is the advantage of either?)

If you do this wrapped in a `with-selected-window' it should do the same
as `redirect-frame-focus'.  Otherwise, it will probably bring the frame
into foreground.  If `redirect-frame-focus' works, stay with it.

 > 1. When I do C-x C-c, and respond to the yes/no question, it seems I must wait a
 > tiny bit before typing yes/no.  Otherwise, the first char (e.g. `y') is lost, so
 > I end up with just `es' (I see the `y' nowhere).  Not a big deal; just FYI.

Does this happen _only_ with your code or also in the emacs -Q scenarios
_without_ your code?  What happens with a `y-or-no-p' defalias?

 > 2. If I type "no," and then I do `C-x k', then even though *Process List* has
 > its frame border highlighted as if it is selected, the buffer proposed for
 > deletion is *shell*.  OK, so I kill *shell*, and confirm ("yes') to kill its
 > processes also.  (BTW, `C-x k' in my setup also deletes the window/frame.)  So
 > far, so good.
 >
 > But if I try to use `C-x k' again to kill *Process List*, then, as soon as I hit
 > the `k':
 >
 > a. The default buffer to kill is proposed as some other buffer, not *Process
 > List* (in my setup the default value is automatically inserted in the
 > minibuffer, so I can see it without doing M-n).
 >
 > b. Emacs crashes, but gives no "fatal error" dialog box - hence no way to access
 > gdb.  It just directly shows the MS Windows dialog box for sending an error
 > report to MS.  When I click yes/no in that dialog box Emacs exits (disappears).

Could be the abort in delete_frame I've told you about.  Why don't you
run Emacs in the debugger jsut from the beginning?  (In a running
instance of Emacs go to the src directory, type M-x gdb, give your
full-path emacs.exe as argument, type "run" and do your things until the
emacs fired up this way becomes unresponsive.  A "bt full" in the first
instance should tell you what happened.)

 > I can repro this systematically, but there seems to be no way to use gdb.  If I
 > do something else instead of `C-x k' - e.g. `C-x o', then there is no problem.
 > I can, for instance, use `C-x o' to move among frames (`C-x o' moves to the
 > other frame in my setup, if there is no other window on the same frame), coming
 > eventually to *Process List*, and then use `C-x k' to kill *Process List*.
 >
 > This crash is reproducible also with Emacs 23.3, not just with the latest Emacs
 > 24 build.  It does not happen with Emacs 22.3, however.  Dunno whether this
 > crash is related to the crashes you are seeing.
 >
 > Anyway, it seems we are very close, for my needs.  I suppose I can put that
 > redirection on `post-command-hook' (instead of in `1on1-fit-minibuffer-frame',
 > which some oneonone.el users will not use), and things should generally work.  I
 > will try that next.

That's a bad idea in my opinion.  Redirect as soon as possible.  Why
don't you use `after-make-frame-functions'?

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  >>  > I imagine that your code is applicable only to Emacs 24+
>  >>  > (is that right?), so it could not have
>  >>  > helped fix things with my setup for other Emacs versions.
>  >>
>  >> Yes.  But maybe you could adapt your buffer display function
>  >> accordingly.
>  >
>  > What do you mean?
> 
> Write you own version of `special-display-popup-frame' replacing
> ... with something like...
> where I used `last-event-frame' because you mentioned it.  I'm not
> familiar with that variable.

I really don't want to get into more redefining of such stuff if I can avoid it.
But we'll see.

I never heard of `last-event-frame' either until this thread, when I started
looking at this stuff more closely, trying to find something that would help.

>  >>  > What about other Emacs releases - are relevant at
>  >>  > all in this context?  Should we expect that your code
>  >>  > can help them also?
>  >>
>  >> If you have an appropriate hook.
>  >
>  > Meaning?  Is this something I can do (how)?
> 
> The above should be applicable to earlier versions to.

What do you mean by "the above" here?  The redefinition code you just suggested
(elided above) or something else?

>  > (redirect-frame-focus last-event-frame
>  >                       (window-frame (minibuffer-window)))
>  > Is that what you meant?
> 
> Not really because I don't understand the semantics of
> `last-event-frame' well enough.  But if it works, all the better.
> 
>  > That works, in all Emacs versions, even without your code! 
>  > And so does using this in its place:
>  >
>  > (select-frame-set-input-focus
>  >   (window-frame (minibuffer-window)))
>  >
>  > (Is there a difference?  What is the advantage of either?)
> 
> If you do this wrapped in a `with-selected-window' it should 
> do the same as `redirect-frame-focus'.  Otherwise, it will
> probably bring the frame into foreground.  If
> `redirect-frame-focus' works, stay with it.

Got it.  Good to know that difference.

>  > 1. When I do C-x C-c, and respond to the yes/no question, 
>  > it seems I must wait a tiny bit before typing yes/no.
>  > Otherwise, the first char (e.g. `y') is lost, so
>  > I end up with just `es' (I see the `y' nowhere).  Not a 
>  > big deal; just FYI.
> 
> Does this happen _only_ with your code or also in the emacs 
> -Q scenarios _without_ your code?  What happens with a
> `y-or-no-p' defalias?

Not sure what you mean.  There is no equivalent in the emacs -Q tests you asked
me to do.  There is nothing on post-command-hook etc.

> Could be the abort in delete_frame I've told you about.  Why don't you
> run Emacs in the debugger jsut from the beginning?  (In a running
> instance of Emacs go to the src directory, type M-x gdb, give your
> full-path emacs.exe as argument, type "run" and do your 
> things until the emacs fired up this way becomes unresponsive.
> A "bt full" in the first instance should tell you what happened.)

I must be missing something when I try to follow that recipe.

I started Emacs with my setup.  I moved to the src directory (in Emacs 24.1,
since I don't have src for later builds - but Emacs 24.1 has the same problem).
I typed M-x gdb, appended c:/Emacs-24.1/bin/emacs.exe and hit RET.

That seemed to pop up a new emacs -Q session (splash page, none of my
customizations, minibuffer in the same frame, etc.), with this message in buffer
*Warnings*, whose window split the screen with the splash page:

"Error (initialization): User has no home directory"

(There are no messages in *Messages*.)

And in buffer *gud-emacs.exe* I see this:

(gdb) run
Starting program: /cygdrive/c/Emacs-24.1/bin/emacs.exe 
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/secur32.dll
Loaded symbols for
/cygdrive/c/WINDOWS/WinSxS/X86_Microsoft.Windows.Common-Controls_6595b64144ccf1d
f_6.0.2600.6028_x-ww_61e65202/comctl32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/msvcrt.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/gdi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/user32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/shlwapi.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/comdlg32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/shell32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/mpr.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/ole32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/usp10.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/winmm.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/winspool.drv

Should I have appended something different to `M-x gdb'?  This is what I use
when I start Emacs with my setup:

C:\Emacs-24.1\bin\runemacs.exe --debug-init

That is what I used this time too, before using `M-x gdb' in src/.

>  > Anyway, it seems we are very close, for my needs.  I 
>  > suppose I can put that redirection on `post-command-hook'
>  > (instead of in `1on1-fit-minibuffer-frame', which some
>  > oneonone.el users will not use), and things should
>  > generally work.  I will try that next.
> 
> That's a bad idea in my opinion.  Redirect as soon as possible.  Why
> don't you use `after-make-frame-functions'?

I'm not sure what you mean.  I tried this:

1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'.

2. Put back the guard (eq last-event-frame (window-frame (minibuffer-window)))
at the beginning of `1on1-fit-minibuffer-frame' (so it is a no-op otherwise).

3. Defined this and added it to `after-make-frame-functions':

(defun 1on1-redirect-to-minibuffer (new-frame)
  "..."
  (when (and 1on1-fit-minibuffer-frame-flag
             (active-minibuffer-window)
             (save-selected-window
               (select-window (minibuffer-window))
               (one-window-p nil 'selected-frame)))
    (redirect-frame-focus
      new-frame
      (window-frame (minibuffer-window)))))

That did not help at all.  The original symptoms returned (typing yes/no did not
go to the minibuffer etc.).

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 22 Jul 2012 09:46:51 -0700
> Cc: 11939@debbugs.gnu.org
> 
> > Could be the abort in delete_frame I've told you about.  Why don't you
> > run Emacs in the debugger jsut from the beginning?  (In a running
> > instance of Emacs go to the src directory, type M-x gdb, give your
> > full-path emacs.exe as argument, type "run" and do your 
> > things until the emacs fired up this way becomes unresponsive.
> > A "bt full" in the first instance should tell you what happened.)
> 
> I must be missing something when I try to follow that recipe.
> 
> I started Emacs with my setup.  I moved to the src directory (in Emacs 24.1,
> since I don't have src for later builds - but Emacs 24.1 has the same problem).
> I typed M-x gdb, appended c:/Emacs-24.1/bin/emacs.exe and hit RET.
> 
> That seemed to pop up a new emacs -Q session (splash page, none of my
> customizations, minibuffer in the same frame, etc.), with this message in buffer
> *Warnings*, whose window split the screen with the splash page:
> 
> "Error (initialization): User has no home directory"
> 
> (There are no messages in *Messages*.)
> 
> And in buffer *gud-emacs.exe* I see this:
> 
> (gdb) run
> Starting program: /cygdrive/c/Emacs-24.1/bin/emacs.exe 
> Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/secur32.dll
> Loaded symbols for
> /cygdrive/c/WINDOWS/WinSxS/X86_Microsoft.Windows.Common-Controls_6595b64144ccf1d
> f_6.0.2600.6028_x-ww_61e65202/comctl32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/msvcrt.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/gdi32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/user32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/shlwapi.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/comdlg32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/shell32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/mpr.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/ole32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/usp10.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/winmm.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/winspool.drv
> 
> Should I have appended something different to `M-x gdb'?  This is what I use
> when I start Emacs with my setup:
> 
> C:\Emacs-24.1\bin\runemacs.exe --debug-init

Don't invoke GDB from inside Emacs, that's only good when you do that
from the same version of Emacs you are debugging, and even then there
are a few gotchas.

Instead, go to the directory where you have .gdbinit, and type from
the shell prompt:

 >gdb /path/to/emacs.exe RET

When GDB ends its initialization and shows the "(gdb)" prompt, type:

 (gdb) run --debug-init

You should now have your normal Emacs session, with all the
customizations you normally have.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> Don't invoke GDB from inside Emacs, that's only good when you do that
> from the same version of Emacs you are debugging, and even then there
> are a few gotchas.
> 
> Instead, go to the directory where you have .gdbinit, and type from
> the shell prompt:
>  >gdb /path/to/emacs.exe RET
> 
> When GDB ends its initialization and shows the "(gdb)" prompt, type:
>  (gdb) run --debug-init

OK, thanks.  I did exactly that.

> You should now have your normal Emacs session, with all the
> customizations you normally have.

No, unfortunately, I get exactly the same behavior described earlier: an emacs
-Q session with a splash screen and a displayed buffer *Warnings* with this
message:

Error (initialization): User  has no home directory

And no messages in *Messages*, except this:

Warning: Lisp directory `c:/Emacs-24-2012-07-16/../site-lisp' does not exist.

For information about GNU Emacs and the GNU system, type C-h C-a.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11939@debbugs.gnu.org>
> Date: Sun, 22 Jul 2012 12:42:54 -0700
> 
> > Don't invoke GDB from inside Emacs, that's only good when you do that
> > from the same version of Emacs you are debugging, and even then there
> > are a few gotchas.
> > 
> > Instead, go to the directory where you have .gdbinit, and type from
> > the shell prompt:
> >  >gdb /path/to/emacs.exe RET
> > 
> > When GDB ends its initialization and shows the "(gdb)" prompt, type:
> >  (gdb) run --debug-init
> 
> OK, thanks.  I did exactly that.
> 
> > You should now have your normal Emacs session, with all the
> > customizations you normally have.
> 
> No, unfortunately, I get exactly the same behavior described earlier: an emacs
> -Q session with a splash screen and a displayed buffer *Warnings* with this
> message:
> 
> Error (initialization): User  has no home directory
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
What does that last message tell you?  I think this is the key to
unlock your mystery.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> > Error (initialization): User  has no home directory
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> What does that last message tell you?  I think this is the key to
> unlock your mystery.

Perhaps you can tell me how so?

The bash cmd prompt recognizes ~ correctly.  And so does Emacs (aside from emacs
-Q).

And env var HOME is also defined correctly and recognized by both bash (outside
and inside Emacs, aside from emacs -Q) and Emacs (aside from emacs -Q).

Can you please demystify the mystery that you see?

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

> The bash cmd prompt recognizes ~ correctly.  And so does 
> Emacs (aside from emacs -Q).
> 
> And env var HOME is also defined correctly and recognized by 
> both bash (outside
> and inside Emacs, aside from emacs -Q) and Emacs (aside from 
> emacs -Q).

Perhaps I should add that in a bash command prompt outside Emacs, echoing $HOME
or ~ shows this:

/cygdrive/c

Inside Emacs (apart from emacs -Q), `C-x d ~' takes me to c:/,
and (getenv "HOME") returns "c:\\".

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On 7/22/12 2:07 PM, Drew Adams wrote:
>> The bash cmd prompt recognizes ~ correctly.  And so does 
>> Emacs (aside from emacs -Q).
>>
>> And env var HOME is also defined correctly and recognized by 
>> both bash (outside
>> and inside Emacs, aside from emacs -Q) and Emacs (aside from 
>> emacs -Q).
> 
> Perhaps I should add that in a bash command prompt outside Emacs, echoing $HOME
> or ~ shows this:
> 
> /cygdrive/c
> 
> Inside Emacs (apart from emacs -Q), `C-x d ~' takes me to c:/,
> and (getenv "HOME") returns "c:\\".

If you want to use Cygwin, you should run a Cygwin Emacs. Any ad-hoc
Cygwin integration in NT Emacs is necessarily incomplete. Is there any
interest in now taking my patch that allows compiling Cygwin Emacs
with Win32 widgets? I've been using it since I submitted that patch,
and it's been working fine for me.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

> If you want to use Cygwin, you should run a Cygwin Emacs. Any ad-hoc
> Cygwin integration in NT Emacs is necessarily incomplete.

I appreciate the advice, but sorry, I like to live dangerously, I guess. ;-)

I have used vanilla GNU Emacs with Cygwin for decades, and I have no plans to
change that.

Yes, I am aware of the arguments and admonitions against it, esp. from Eli, and
I do not say that such are wrong.  But I am not interested, sorry.

My use of Cygwin is quite limited.  I do no code development, for example (other
than piddling around with Emacs Lisp for fun).

> Is there any
> interest in now taking my patch that allows compiling Cygwin Emacs
> with Win32 widgets? I've been using it since I submitted that patch,
> and it's been working fine for me.

Please do not sidetrack this bug thread.  Bring that topic up in emacs-devel if
you want to.  Thx.

(FWIW, I, for one, am not interested in a Cygwin Emacs.)

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

> > > Error (initialization): User  has no home directory
> >                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > What does that last message tell you?  I think this is the key to
> > unlock your mystery.
> 
> Perhaps you can tell me how so?

And in Emacs (including emacs -Q), my `user-login-name' is defined correctly.

I mention this because I notice that there seem to be 2 spaces between "User"
and "has" in that message. Perhaps it is trying to print a user name of only ""
between the two words.

BTW, if that is the case, then that error message is pretty lame.  It is almost
always better to quote the name that a message wants to refer to (i.e., wants to
quote).

That message would be clearer (if this in fact is the problem) if it said:

"User `' has no home directory".  Or perhaps "User name is empty".

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <11939@debbugs.gnu.org>
> Date: Sun, 22 Jul 2012 14:16:55 -0700
> 
> > > > Error (initialization): User  has no home directory
> > >                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > What does that last message tell you?  I think this is the key to
> > > unlock your mystery.
> > 
> > Perhaps you can tell me how so?
> 
> And in Emacs (including emacs -Q), my `user-login-name' is defined correctly.
> 
> I mention this because I notice that there seem to be 2 spaces between "User"
> and "has" in that message. Perhaps it is trying to print a user name of only ""
> between the two words.
> 
> BTW, if that is the case, then that error message is pretty lame.  It is almost
> always better to quote the name that a message wants to refer to (i.e., wants to
> quote).
> 
> That message would be clearer (if this in fact is the problem) if it said:
> 
> "User `' has no home directory".  Or perhaps "User name is empty".

There's no problem with your user name.  What you see above is
startup.el shooting itself in the foot, because it actually _sets_ the
variable that holds the user name to an empty string (for boring
reasons related to the implementation; see the code around the error
message for the details, if you are interested).

I've committed a fix to display the user name correctly, even if that
variable is set to an empty string.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

> > That message would be clearer (if this in fact is the 
> > problem) if it said:
> > 
> > "User `' has no home directory".  Or perhaps "User name is empty".
> 
> There's no problem with your user name.  What you see above is
> startup.el shooting itself in the foot, because it actually _sets_ the
> variable that holds the user name to an empty string (for boring
> reasons related to the implementation; see the code around the error
> message for the details, if you are interested).
> 
> I've committed a fix to display the user name correctly, even if that
> variable is set to an empty string.

Good. Thx.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11939@debbugs.gnu.org>
> Date: Sun, 22 Jul 2012 14:01:58 -0700
> 
> > > Error (initialization): User  has no home directory
> >                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > What does that last message tell you?  I think this is the key to
> > unlock your mystery.
> 
> Perhaps you can tell me how so?

How could I, without knowing all that you told about your environment
since my message?  Even now, with all that additional info in hand, I
can only guess (see below).  By contrast, you should be well equipped
to find out what is going on, because this message comes from
startup.el (says 'grep').

> The bash cmd prompt recognizes ~ correctly.  And so does Emacs (aside from emacs
> -Q).
> 
> And env var HOME is also defined correctly and recognized by both bash (outside
> and inside Emacs, aside from emacs -Q) and Emacs (aside from emacs -Q).
> 
> Can you please demystify the mystery that you see?

Given this:

> Perhaps I should add that in a bash command prompt outside Emacs, echoing $HOME
> or ~ shows this:
> 
> /cygdrive/c
> 
> Inside Emacs (apart from emacs -Q), `C-x d ~' takes me to c:/,
> and (getenv "HOME") returns "c:\\".

I'm guessing that you invoked GDB from the Cygwin Bash's prompt, which
has the effect of setting HOME to /cygdrive/c, which the native
Windows Emacs doesn't grok.  The code in startup.el that looks for
~/.emacs tests the value of HOME by calling file-directory-p, which
fails for /cygdrive/c, the result being the error message.  I'm
guessing that invoking GDB from the Windows shell cmd.exe should fix
this.

In any case, since the purpose of this discussion is not to "fix" your
environment, I suggest that instead of invoking Emacs from GDB, you
invoke it normally (presumably from a desktop shortcut); then
immediately attach GDB to it, like you do when Emacs crashes; then
type "continue" at GDB's prompt to let Emacs run; and finally do
whatever Martin asked you to for which he wanted GDB to kick in.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> I suggest that instead of invoking Emacs from GDB, you
> invoke it normally (presumably from a desktop shortcut); then
> immediately attach GDB to it, like you do when Emacs crashes; then
> type "continue" at GDB's prompt to let Emacs run; and finally do
> whatever Martin asked you to for which he wanted GDB to kick in.

That I would like to try, but I don't know the recipe.

What I have done in the past I did after getting the Emacs popup dialog window
about a fatal crash (what you have called the "Emacs abort dialog"), following
instructions that you gave me in the past.

For the current crash, which presents no such dialog box, I tried following
Martin's instructions for invoking gdb from within Emacs.  You then instructed
me not to do that but to instead invoke gdb outside Emacs.  That's when I tried
doing invoking it from a bash shell etc.

If you give me the recipe for invoking gdb from within Emacs the right way then
I will be glad to try it.  In sum, this is not clear to me: "immediately attach
GDB to it, like you do when Emacs crashes".

Thx.

P.S. These are the instructions from you that I follow when I do get the "Emacs
abort dialog" box:

> when you see the Emacs abort dialog do this in order:
> 
>   . Find out the PID of the Emacs process
>   . Open a shell window and chdir to the directory where you have GDB
>     and .gdbinit
>   . Type "./gdb -p PID" and hit RET
>   . When you see the "(gdb)" prompt, type "c RET"
>   . Click YES on the Emacs abort dialog
> 
> You should then see GDB announcing the crash, something like this:
> 
>  Program received signal SIGTRAP, Trace/breakpoint trap.
>  [Switching to Thread 3684.0x1210]
>  0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
> 
> and then the GDB prompt "(gdb)".  Now you are ready to debug the
> crash.

At that point, I type `bt'.  And perhaps `frame N' for some N followed by `p
XYZ' for something XYZ such as `selected_window'.  Then I type `xtype'.

If you can tell me what to do differently here, where there is no "Emacs abort
dialog" box, I will follow the recipe and let you know what I see.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11939@debbugs.gnu.org>
> Date: Mon, 23 Jul 2012 09:28:00 -0700
> 
> > I suggest that instead of invoking Emacs from GDB, you
> > invoke it normally (presumably from a desktop shortcut); then
> > immediately attach GDB to it, like you do when Emacs crashes; then
> > type "continue" at GDB's prompt to let Emacs run; and finally do
> > whatever Martin asked you to for which he wanted GDB to kick in.
> 
> That I would like to try, but I don't know the recipe.
> 
> What I have done in the past I did after getting the Emacs popup dialog window
> about a fatal crash (what you have called the "Emacs abort dialog"), following
> instructions that you gave me in the past.
> 
> For the current crash, which presents no such dialog box, I tried following
> Martin's instructions for invoking gdb from within Emacs.

Don't wait for the crash.  Instead, attach GDB to Emacs right after
starting Emacs, with "gdb -p PID".  When GDB attaches to a program,
the program stops, so to let Emacs run normally thereafter, you will
need to type "continue" at GDB prompt.  After that, operate Emacs
normally, and do whatever is needed to reproduce the problem.

> If you give me the recipe for invoking gdb from within Emacs the right way then
> I will be glad to try it.  In sum, this is not clear to me: "immediately attach
> GDB to it, like you do when Emacs crashes".

  . invoke Emacs as you normally do
  . find out its PID
  . from the shell prompt, type "gdb -p PID" from the directory where
    you have .gdbinit
  . wait until GDB starts and displays its prompt, then type
    "continue" at that prompt.
  . go to the Emacs window and reproduce the problem.
  . when the problem (crash) happens, the debugger will kick in and
    display its prompt again, so you can type GDB command there.

> P.S. These are the instructions from you that I follow when I do get the "Emacs
> abort dialog" box:
> 
> > when you see the Emacs abort dialog do this in order:
> > 
> >   . Find out the PID of the Emacs process
> >   . Open a shell window and chdir to the directory where you have GDB
> >     and .gdbinit
> >   . Type "./gdb -p PID" and hit RET
> >   . When you see the "(gdb)" prompt, type "c RET"
> >   . Click YES on the Emacs abort dialog

Do the same, just don't wait for the abort dialog.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>   . invoke Emacs as you normally do
>   . find out its PID
>   . from the shell prompt, type "gdb -p PID" from the directory where
>     you have .gdbinit
>   . wait until GDB starts and displays its prompt, then type
>     "continue" at that prompt.
>   . go to the Emacs window and reproduce the problem.
>   . when the problem (crash) happens, the debugger will kick in and
>     display its prompt again, so you can type GDB command there.

Got it; thanks.

Unfortunately, I cannot get much in the way of results that way, for this test
at least.

After `(gdb) continue', I followed the recipe I followed before to produce the
crash.  When it would have crashed before (i.e., without gdb) it now just seemed
to hang.

I can, however, see this in the command-prompt window (outside Emacs):

$ gdb -p 4252
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Attaching to process 4252
[Switching to thread 4252.0xc80]
/cygdrive/c/drews-lisp-20/bin/.gdbinit:32: Error in sourced command file:
No symbol "main" in current context.
(gdb) continue
Continuing.
warning: frame 049AE200 (*shell*) obscured

warning: frame 049AE200 (*shell*) reexposed by WM_PAINT

warning: obscured frame 049AE200 (*shell*) found to be visible


Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 4252.0xfb0]
0x01252ab3 in ?? ()
(gdb) bt
#0  0x01252ab3 in ?? ()
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or y)
Detaching from program: , Pid 4252

At that point, I did get the MS Windows "encountered a problem and needs to
close" dialog box, and clicked button "Send Error Report", and Emacs exited.

Dunno whether that helps at all.  As the problem is reproducible, I can try
again if you give me more instructions to try.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11939@debbugs.gnu.org>
> Date: Mon, 23 Jul 2012 11:29:40 -0700
> 
> Unfortunately, I cannot get much in the way of results that way, for this test
> at least.
> 
> After `(gdb) continue', I followed the recipe I followed before to produce the
> crash.  When it would have crashed before (i.e., without gdb) it now just seemed
> to hang.

That's not what I see:

> (gdb) continue
> Continuing.
> warning: frame 049AE200 (*shell*) obscured
> 
> warning: frame 049AE200 (*shell*) reexposed by WM_PAINT
> 
> warning: obscured frame 049AE200 (*shell*) found to be visible
> 
> 
> Program received signal SIGSEGV, Segmentation fault.  <<<<<<<<<<<

This is definitely a crash.


> (gdb) quit
> The program is running.  Quit anyway (and detach it)? (y or y)
> Detaching from program: , Pid 4252
> 
> At that point, I did get the MS Windows "encountered a problem and needs to
> close" dialog box, and clicked button "Send Error Report", and Emacs exited.

Well, don't say "quit".  Instead, I hope that Martin will be able to
give you instructions what to look for once you get SIGSEGV.

Martin, the floor is yours ;-)

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

> Martin, the floor is yours ;-)

Thanks Eli, but I'm a stranger here myself.  Drew, what does bt full say?

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> > Martin, the floor is yours ;-)
> Thanks Eli, but I'm a stranger here myself.
> Drew, what does bt full say?

It says this:

$ gdb -p 2964
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Attaching to process 2964

[Switching to thread 2964.0x1220]
/cygdrive/c/drews-lisp-20/bin/.gdbinit:32: Error in sourced command file:
No symbol "main" in current context.
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 2964.0x15c0]
0x01102012 in ?? ()
(gdb) bt full
#0  0x01102012 in ?? ()
No symbol table info available.
(gdb)

IOW, `bt full' just adds the statement "No symbol table info available." to what
`bt' shows.

Reminder: This is without your `with-temp-buffer-window.el' loaded, and with
`redirect-frame-focus' added to the end of `1on1-fit-minibuffer-frame'.  If I
also load your `with-temp-buffer-window.el' then I do not get the crash.

But in that case (i.e., with your code) the *Process List* buffer is replaced in
its frame by *shell*, so I then have two frames showing *shell* at that point.
This is an example of the problem of the frame (for *Process Control*) not
really being special-display as it should be.

Again, this is with Emacs 24.1, and the scenario is the following, after
evaluating my  modified `1on1-fit-minibuffer-frame' and optionally loading your
code:

M-x shell
C-x C-c
Reply "no" to the question about active processes - IOW, do not quit Emacs.
C-x k

At that point, if your code was not loaded, the *Process List* frame has its
title bar selected/highlighted, but the buffer to be killed, by default, is
*shell*. If your code was loaded then buffer *Process Control* has been replaced
in its (supposedly special-display) frame by buffer *shell* (so there are two
frames for *shell* now).

If your code was loaded, then I can kill buffer *shell* normally, after
confirming to kill its processes - the two *shell* frames disappear (as they
should, with my setup). And C-x C-b shows that there is no buffer *Process
List*.

If your code was not loaded, then I can still kill *shell* normally, but the
*Process List* frame remains (frame *shell* disappears, as it should).  If I
then try C-x k, and try to type a char or move the cursor in the minibuffer,
then I get the crash.

If, however, I do something that explicitly selects some frame, then I can
proceed normally to kill any buffer using C-x k - including buffer *Process
List* (which is still hanging around).  An example of explicitly selecting some
frame would be clicking the mouse on a frame title bar.

HTH/Thx - Drew

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <11939@debbugs.gnu.org>
> Date: Wed, 25 Jul 2012 08:42:47 -0700
> 
> > > Martin, the floor is yours ;-)
> > Thanks Eli, but I'm a stranger here myself.
> > Drew, what does bt full say?
> 
> It says this:
> 
> $ gdb -p 2964
> GNU gdb 6.5.50.20060706-cvs (cygwin-special)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin".
> Attaching to process 2964
> 
> [Switching to thread 2964.0x1220]
> /cygdrive/c/drews-lisp-20/bin/.gdbinit:32: Error in sourced command file:
> No symbol "main" in current context.
> (gdb) continue
> Continuing.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to thread 2964.0x15c0]
> 0x01102012 in ?? ()
> (gdb) bt full
> #0  0x01102012 in ?? ()
> No symbol table info available.
> (gdb)
> 
> IOW, `bt full' just adds the statement "No symbol table info available." to what
> `bt' shows.

Try this instead:

  (gdb) thread apply all bt full

(IOW, there's more than one thread in the program, and you happen to
be in the wrong one.)

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> Try this instead:
>   (gdb) thread apply all bt full
> 
> (IOW, there's more than one thread in the program, and you happen to
> be in the wrong one.)

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 420.0x1468]
0x01102012 in ?? ()
(gdb) thread apply all bt full

Thread 2 (thread 420.0x14c4):
#0  0x7c90e514 in ntdll!LdrAccessResource ()
No symbol table info available.
#1  0x7e4191be in USER32!GetProcessWindowStation ()
No symbol table info available.
#2  0x7e42776b in USER32!GetMessageA ()
No symbol table info available.
#3  0x723dfee0 in ?? ()
No symbol table info available.

Thread 1 (thread 420.0x1468):
#0  0x01102012 in ?? ()
No symbol table info available.
(gdb)

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

Martin, I tried what you suggested about `after-make-frame-functions' again, but
this time with my setup (with unmodified oneonone.el).  I added only this to my
usual setup:

(add-hook 'after-make-frame-functions
          (lambda (frame)
            (redirect-frame-focus frame frame)))

I then ran through the scenario that lead to a crash (C-x C-c, no to exit, C-x k
*shell* + yes, C-x k again, try to type or move cursor).

No crash in this case, but when I try to type something or move the cursor after
the second C-x k (which is the point at which the crash occurred), I can see
that the input is being sent to buffer & frame *Process List*.  That's not what
you expected, is it?  It is not TRT, in any case.

I do not understand, BTW, why you redirect the focus from the new frame to
itself, instead of to the minibuffer frame.

So I tried instead redirecting the focus to the minibuffer frame.  That worked
OK, but the default buffer for killing with C-x k was ` *Minibuf-0*', not
*shell* or *Process List*.

It seems that when a new frame is created, the default value for C-x k (and
other buffer commands) becomes *Minibuf-0*.  I can of course choose not to use
the default value, but it would be good to get this part fixed also.

Or as a workaround I can explicitly select the frame of the buffer I want to
kill - e.g., click the title bar of frame *shell*.  After I do that, that buffer
becomes the default value for C-x k.

IOW, it seems that not only is the input focus redirected to the minibuffer
frame, but also the current buffer is changed to *Minibuf-0*.  And if I do `M-:
(current-buffer)' I do get *Minibuf-0*.  Is it normal for frame-focus
redirection to change the current buffer also?  That does not seem right to me.

Anyway, aside from this problem of default value for C-x k, things seemed to
work OK.  So overall this seems like a reasonable solution, except for the
default buffer problem.  This is all I did, along with my usual setup:

(add-hook 'after-make-frame-functions
          (lambda (frame)
            (redirect-frame-focus frame (window-frame (minibuffer-window)))))

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[martin rudalics]

 > (add-hook 'after-make-frame-functions
 >           (lambda (frame)
 >             (redirect-frame-focus frame frame)))
 >
 > I then ran through the scenario that lead to a crash (C-x C-c, no to exit, C-x k
 > *shell* + yes, C-x k again, try to type or move cursor).
 >
 > No crash in this case, but when I try to type something or move the cursor after
 > the second C-x k (which is the point at which the crash occurred), I can see
 > that the input is being sent to buffer & frame *Process List*.  That's not what
 > you expected, is it?  It is not TRT, in any case.
 >
 > I do not understand, BTW, why you redirect the focus from the new frame to
 > itself, instead of to the minibuffer frame.

I came to this when trying out various scenarios and it seemed this worked
for me.

 > So I tried instead redirecting the focus to the minibuffer frame.  That worked
 > OK, but the default buffer for killing with C-x k was ` *Minibuf-0*', not
 > *shell* or *Process List*.
 >
 > It seems that when a new frame is created, the default value for C-x k (and
 > other buffer commands) becomes *Minibuf-0*.  I can of course choose not to use
 > the default value, but it would be good to get this part fixed also.

You mean *Minibuf-0* became the current buffer?  Probably so because you
selected its window.

 > Or as a workaround I can explicitly select the frame of the buffer I want to
 > kill - e.g., click the title bar of frame *shell*.  After I do that, that buffer
 > becomes the default value for C-x k.
 >
 > IOW, it seems that not only is the input focus redirected to the minibuffer
 > frame, but also the current buffer is changed to *Minibuf-0*.  And if I do `M-:
 > (current-buffer)' I do get *Minibuf-0*.  Is it normal for frame-focus
 > redirection to change the current buffer also?  That does not seem right to me.

I nowhere in the code see that it does.  Are you sure you did not use
`select-frame-set-input-focus' in this case?

 > Anyway, aside from this problem of default value for C-x k, things seemed to
 > work OK.  So overall this seems like a reasonable solution, except for the
 > default buffer problem.  This is all I did, along with my usual setup:
 >
 > (add-hook 'after-make-frame-functions
 >           (lambda (frame)
 >             (redirect-frame-focus frame (window-frame (minibuffer-window)))))

That was my initial idea.  I forgot why it didn't work (maybe it failed
when I created a new frame with a minibuffer).

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

>  > I do not understand, BTW, why you redirect the focus from 
>  > the new frame to itself, instead of to the minibuffer frame.
> 
> I came to this when trying out various scenarios and it 
> seemed this worked for me.

OK.  It does not work for me.

>  > So I tried instead redirecting the focus to the minibuffer 
>  > frame.  That worked OK, but the default buffer for killing
>  > with C-x k was ` *Minibuf-0*', not *shell* or *Process List*.
>  >
>  > It seems that when a new frame is created, the default 
>  > value for C-x k (and other buffer commands) becomes *Minibuf-0*.
>  > I can of course choose not to use the default value, but it
>  > would be good to get this part fixed also.
> 
> You mean *Minibuf-0* became the current buffer?  Probably so 
> because you selected its window.

I did not do so explicitly, AFAIK.  But perhaps read-from-minibuffer (actually
the C code for it) does that?  I do not see anywhere that I do so in my code.

>  > Or as a workaround I can explicitly select the frame of 
>  > the buffer I want to kill - e.g., click the title bar of frame
>  > *shell*.  After I do that, that buffer becomes the default
>  > value for C-x k.
>  >
>  > IOW, it seems that not only is the input focus redirected 
>  > to the minibuffer frame, but also the current buffer is
>  > changed to *Minibuf-0*.  And if I do `M-:
>  > (current-buffer)' I do get *Minibuf-0*.  Is it normal for 
>  > frame-focus redirection to change the current buffer also?
>  > That does not seem right to me.
> 
> I nowhere in the code see that it does.  Are you sure you did
> not use `select-frame-set-input-focus' in this case?

Yes, I'm pretty sure.  I can always try to look closer, but there is certainly
nothing in oneonone.el that does that.

>  > Anyway, aside from this problem of default value for C-x 
>  > k, things seemed to work OK.  So overall this seems like a
>  > reasonable solution, except for the default buffer problem.
>  > This is all I did, along with my usual setup:
>  >
>  > (add-hook 'after-make-frame-functions
>  >           (lambda (frame)
>  >             (redirect-frame-focus frame
>  >               (window-frame (minibuffer-window)))))
> 
> That was my initial idea.  I forgot why it didn't work (maybe 
> it failed when I created a new frame with a minibuffer).

What do you think about it now?  Do you see a problem with it (aside from the
current-buffer problem I mentioned)?  Maybe it is worth pursuing; dunno.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[martin rudalics]

 >>  > So I tried instead redirecting the focus to the minibuffer
 >>  > frame.  That worked OK, but the default buffer for killing
 >>  > with C-x k was ` *Minibuf-0*', not *shell* or *Process List*.
 >>  >
 >>  > It seems that when a new frame is created, the default
 >>  > value for C-x k (and other buffer commands) becomes *Minibuf-0*.
 >>  > I can of course choose not to use the default value, but it
 >>  > would be good to get this part fixed also.
 >>
 >> You mean *Minibuf-0* became the current buffer?  Probably so
 >> because you selected its window.
 >
 > I did not do so explicitly, AFAIK.  But perhaps read-from-minibuffer (actually
 > the C code for it) does that?  I do not see anywhere that I do so in my code.

It indeed selects the window and sets the current buffer.  But C-x k
should never offer *Minibuf-0* for killing.  Does it really prompt with
*Minibuf-0*?  If so, then the following excerpt from Fcall_interactively

	case 'b':   		/* Name of existing buffer */
	  args[i] = Fcurrent_buffer ();
	  if (EQ (selected_window, minibuf_window))
	    args[i] = Fother_buffer (args[i], Qnil, Qnil);
	  args[i] = Fread_buffer (callint_message, args[i], Qt);
	  break;

is broken.  IIUC it means that the current buffer is the buffer of the
minibuffer window (how did that happen?) but the minibuffer window is
not selected.  What is missing from the form below to reproduce it?

(progn
   (add-hook 'after-make-frame-functions
	    #'(lambda (frame)
		(redirect-frame-focus
		 frame (window-frame (minibuffer-window)))))
   (setq pop-up-frame-function (lambda () (make-frame '((minibuffer . nil)))))
   (setq pop-up-frames t)
   (display-buffer "*Messages*")
   (yes-or-no-p "???"))

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

>  > I did not do so explicitly, AFAIK.  But perhaps 
>  > read-from-minibuffer (actually the C code for it) does that?
>  > I do not see anywhere that I do so in my code.
> 
> It indeed selects the window and sets the current buffer.  But C-x k
> should never offer *Minibuf-0* for killing.  Does it really 
> prompt with *Minibuf-0*? 

Yes, but (I think) I explained that I have a different command bound to `C-x k'.
That command proposes the name of (current-buffer) as the default value.  And as
I said, the name of the buffer returned by (current-buffer) here is in fact
" *Minibuf-0*".

> If so, then ... Fcall_interactively... is broken.

See above - I am not using `kill-buffer' for `C-x k'.  I doubt that anything so
basic is broken.

> IIUC it means that the current buffer is the buffer of the
> minibuffer window (how did that happen?)

Yes, that is what I am seeing, confirmed by evaluating (current-buffer)
there/then.

> but the minibuffer window is not selected.

Are you sure?  How to know?

> What is missing from the form below to reproduce it?
> (progn
>    (add-hook 'after-make-frame-functions
> 	    #'(lambda (frame)
> 		(redirect-frame-focus
> 		 frame (window-frame (minibuffer-window)))))
>    (setq pop-up-frame-function
>          (lambda () (make-frame  '((minibuffer . nil)))))
>    (setq pop-up-frames t)
>    (display-buffer "*Messages*")
>    (yes-or-no-p "???"))

I don't know.  I can try to dig into it later, I suppose (I cannot now).  But
perhaps try binding `C-x k' to a command that proposes the name of
(current-buffer) as the default?

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[martin rudalics]

 > Yes, but (I think) I explained that I have a different command bound to `C-x k'.
 > That command proposes the name of (current-buffer) as the default value.  And as
 > I said, the name of the buffer returned by (current-buffer) here is in fact
 > " *Minibuf-0*".

I see.  But then where do you see a problem if your function prompts
with the current buffer for killing?  Do you ever want to kill the
minibuffer's buffer?  If not, your function should provide an
appropriate workaround default just as `call-interactively' does.

 >> IIUC it means that the current buffer is the buffer of the
 >> minibuffer window (how did that happen?)
 >
 > Yes, that is what I am seeing, confirmed by evaluating (current-buffer)
 > there/then.
 >
 >> but the minibuffer window is not selected.
 >
 > Are you sure?  How to know?

I assumed that you used `kill-buffer' with the standard prompt.  If you
use your own function, my conclusion is void.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

> I see.  But then where do you see a problem if your function prompts
> with the current buffer for killing?  

In the scenario I described - see my previous descriptions, but here is a
summary of what I did (before):

C-x C-c, reply "no"

C-x k, with the default being *shell* (even though frame *Process List* was on
top and had its title bar highlighted).  Reply "yes" to killing the processes.

C-x k, wanting to kill *Process List* - see previous descriptions for the
problems here.

But in the latest test, where I did only the `redirect-*', the default buffer to
kill was ALWAYS " *Minibuf-0*".  It's not a problem, in the sense that focus is
at least in the minibuffer frame and I can therefore choose not to use the
default.  (In my setup, I automatically have the default inserted in the
minibuffer, but I can easily remove it.)

> Do you ever want to kill the minibuffer's buffer?

No, never.

> If not, your function should provide an
> appropriate workaround default just as `call-interactively' does.

Well OK, I suppose - I can certainly try to do that.

But I have never had to do it before.  Obviously, if the right thing to do is to
work around this hiccup then I can and might try to do that.  And as I said:

>>> Or as a workaround I can explicitly select the frame of the
>>> buffer I want to kill - e.g., click the title bar of frame *shell*.
>>> After I do that, that buffer becomes the default value for C-x k.

But the point was that the minibuffer buffer was the (current-buffer) here,
suggesting to me that the minibuffer frame (and its buffer) was selected.

Is that TRT?  I didn't think so.  I didn't think that just calling `redirect-*'
would/should also select the frame and its buffer.  That is why I said this:

>>> IOW, it seems that not only is the input focus redirected 
>>> to the minibuffer frame, but also the current buffer is
>>> changed to *Minibuf-0*.  And if I do `M-:
>>> (current-buffer)' I do get *Minibuf-0*.  Is it normal for 
>>> frame-focus redirection to change the current buffer also?
>>> That does not seem right to me.

None of that has to do with my `C-x k' command, I believe.  AFAIK, I do not
select the minibuffer frame or buffer.  I speculated that perhaps the C code for
read-from-minibuffer does, but I don't know that.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

> > Do you ever want to kill the minibuffer's buffer?
> 
> No, never.
> 
> > If not, your function should provide an
> > appropriate workaround default just as `call-interactively' does.
> 
> Well OK, I suppose - I can certainly try to do that.
> 
> But I have never had to do it before.  Obviously, if the 
> right thing to do is to work around this hiccup then I can and
> might try to do that.  

But I would add that I prefer not to do that, for a couple of reasons.  One is
that the same general list of buffer candidates and default value are used for
multiple commands, not just the command bound to `C-x k'.  And while it is true
that I never want to kill the minibuffer buffer, that does not mean that I never
want to do some other operation using it.

Anyway, I'm sure you get the point: the buffer that I would expect to be
(current-buffer) here is the buffer in which I invoked `C-x k' (or whatever) -
not " *Minibuf-0*.  The latter does not make much sense to me.

And I think (still, so far) that that is the case because (somehow) the
minibuffer frame got _selected_, and did not just have its input focus
redirected to it.  And I think, a priori, that is not TRT.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 > And I think (still, so far) that that is the case because (somehow) the
 > minibuffer frame got _selected_, and did not just have its input focus
 > redirected to it.  And I think, a priori, that is not TRT.

Yes.  But as long as we don't know how this happens there's not much we
can do about it.  Can't you try displaying in the mode-line of each
window (1) that window (2) the selected window and (3) the current
buffer.  So after redisplay we know which window is selected ...

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

>  > And I think (still, so far) that that is the case because 
>  > (somehow) the minibuffer frame got _selected_, and did not
>  > just have its input focus redirected to it.  And I think,
>  > a priori, that is not TRT.
> 
> Yes.  But as long as we don't know how this happens there's 
> not much we can do about it.

I don't understand.  Your other message, sent at the same time as that one, said
that you know it is `yes-or-no-p' that does that, and that that is necessary.

> Can't you try displaying in the mode-line of each
> window (1) that window (2) the selected window and (3) the current
> buffer.  So after redisplay we know which window is selected ...

Can you tell me how to do that?

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 >>  > And I think (still, so far) that that is the case because
 >>  > (somehow) the minibuffer frame got _selected_, and did not
 >>  > just have its input focus redirected to it.  And I think,
 >>  > a priori, that is not TRT.
 >>
 >> Yes.  But as long as we don't know how this happens there's
 >> not much we can do about it.
 >
 > I don't understand.  Your other message, sent at the same time as that one, said
 > that you know it is `yes-or-no-p' that does that, and that that is necessary.

I "know that `yes-or-no-p' does that, and that that is necessary" but I
do not know whether "it is `yes-or-no-p' that does that".  Only you
could find out by going through this with the debugger.

 >> Can't you try displaying in the mode-line of each
 >> window (1) that window (2) the selected window and (3) the current
 >> buffer.  So after redisplay we know which window is selected ...
 >
 > Can you tell me how to do that?

No.  I forgot that when displaying the modeline, its window is selected
and its buffer made current.  But the following unnecessarily complex
part of my setup displays the window number in the modeline.

(defun prettify (size-string pretty-string)
   "Prettify number by inserting dots."
   (if (> (length size-string) 3)
       (prettify (substring size-string 0 -3)
                 (concat "." (substring size-string -3) pretty-string))
     (concat size-string pretty-string)))

(defface mode-line-numbers
   '((t :family "Verdana"
        :weight bold))
   "Basic mode line face for selected window."
   :version "23.1"
   :group 'mode-line-faces)

(let* ((help-echo
         ;; The multi-line message doesn't work terribly well on the
         ;; bottom mode line...  Better ideas?
         ;;        "\
         ;; mouse-1: select window, mouse-2: delete others, mouse-3: delete,
         ;; drag-mouse-1: resize, C-mouse-2: split horizontally"
         "mouse-1: select (drag to resize), mouse-3: delete or split")
        (dashes (propertize "--" 'help-echo help-echo)))
   (setq-default mode-line-format
		(list
		 "%e"
		 (propertize " " 'help-echo help-echo)
		 'mode-line-mule-info
		 'mode-line-modified
		 (propertize " " 'help-echo help-echo)
		 'mode-line-buffer-identification
		 (propertize "   " 'help-echo help-echo)
		 'mode-line-position
		 '(vc-mode vc-mode)
		 (propertize "   " 'help-echo help-echo)
		 'mode-line-modes
		 `(which-func-mode ("" which-func-format ,dashes))
		 `(global-mode-string (,dashes global-mode-string))
		 (propertize " " 'help-echo help-echo)))

   (setq-default mode-line-modes
		(list
		 `(:propertize ("" mode-name)
			       help-echo "mouse-1: major mode menu   mouse-3: minor modes menu"
			       mouse-face mode-line-highlight
			       local-map ,mode-line-major-mode-keymap)
		 '("" mode-line-process)
		 `(:propertize ("" minor-mode-alist)
			       mouse-face mode-line-highlight
			       help-echo "mouse-1: minor mode menu  mouse-3: minor modes menu"
			       local-map ,mode-line-minor-mode-keymap)
		 (propertize "%n" 'help-echo "mouse-3: widen"
			     'mouse-face 'mode-line-highlight
			     'local-map (make-mode-line-mouse-map
					 'mouse-3 #'mode-line-widen))))

   (setq-default
    mode-line-position
    '(:eval (let ((help-echo "mouse-1: select (drag to resize), mouse-3: delete"))
	     `(10 ,(propertize
		    (concat "  %l  /  %c  /  "
			    (propertize
			     (prettify (format "%i" (point)) "")
			     'face 'mode-line-numbers)

			    (propertize
			     (concat		; WINDOW
			      (replace-regexp-in-string
			       ">" ""
			       (replace-regexp-in-string
				" on.+" ""
				(replace-regexp-in-string
				 "#<window " "#" (format "   %s" (selected-window)))))
			      (when (window-dedicated-p)
				"D")
			      )
			     'face 'mode-line-numbers)

			    "  ")
		    'face 'mode-line-numbers
		    'mouse-face 'mode-line-highlight
		    'help-echo help-echo))))))

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

Martin,

Can you tell me where you think we are with this bug?

Can we please separate out any other bugs/problems that have been encountered in
this thread, such as crashes, and return to the problem of the bug report?  I
thought we were making progress on that, but it's not clear to me where we are
now wrt the problem.

Here's my attempt at a summary - but please help me fill things in, with your
understanding:

You wrote some code which improved things, and I tried various things, the last
of which was this:

(add-hook 'after-make-frame-functions
          (lambda (frame)
            (redirect-frame-focus frame
             (window-frame (minibuffer-window)))))

You mentioned that when you tried redirecting to the minibuffer frame that way
you encountered some problems, but you didn't remember what they were.  I said
that when I instead redirected the frame to itself (which I guess worked for
you), it did not solve the focus problem (for me).

I said that with the above code another problem is introduced, which is that the
current-buffer and selected window are apparently left as " *Minibuf-0*".

Do you have a better idea of where things stand wrt this problem?  Will you be
applying your latest code to Emacs?  Where do you think we should go from here,
to progress a bit and perhaps finish this?

In sum, I would like us to try to refocus on the original problem and see if we
can take stock of what we have learned.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 > Here's my attempt at a summary - but please help me fill things in, with your
 > understanding:
 >
 > You wrote some code which improved things, and I tried various things, the last
 > of which was this:
 >
 > (add-hook 'after-make-frame-functions
 >           (lambda (frame)
 >             (redirect-frame-focus frame
 >              (window-frame (minibuffer-window)))))
 >
 > You mentioned that when you tried redirecting to the minibuffer frame that way
 > you encountered some problems, but you didn't remember what they were.  I said
 > that when I instead redirected the frame to itself (which I guess worked for
 > you), it did not solve the focus problem (for me).
 >
 > I said that with the above code another problem is introduced, which is that the
 > current-buffer and selected window are apparently left as " *Minibuf-0*".
 >
 > Do you have a better idea of where things stand wrt this problem?

IIUC the above is what you wanted to apply for making your code work with
versions <= Emacs 24.1.

 > Will you be
 > applying your latest code to Emacs?

Unless you tell me that you find any problems with it.

 > Where do you think we should go from here,
 > to progress a bit and perhaps finish this?
 >
 > In sum, I would like us to try to refocus on the original problem and see if we
 > can take stock of what we have learned.

I can't say that I have learned much so far.  Most of the focus
redirection stuff still remains a mystery to me.  Personally, I would
never use a separate minibuffer frame for the sole reason that I don't
understand how it works.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[martin rudalics]

 >> I see.  But then where do you see a problem if your function prompts
 >> with the current buffer for killing?
 >
 > In the scenario I described - see my previous descriptions, but here is a
 > summary of what I did (before):
 >
 > C-x C-c, reply "no"
 >
 > C-x k, with the default being *shell* (even though frame *Process List* was on
 > top and had its title bar highlighted).  Reply "yes" to killing the processes.
 >
 > C-x k, wanting to kill *Process List* - see previous descriptions for the
 > problems here.
 >
 > But in the latest test, where I did only the `redirect-*', the default buffer to
 > kill was ALWAYS " *Minibuf-0*".  It's not a problem, in the sense that focus is
 > at least in the minibuffer frame and I can therefore choose not to use the
 > default.  (In my setup, I automatically have the default inserted in the
 > minibuffer, but I can easily remove it.)

I don't know what your C-x k does so I can't comment on it.  The fact
that `call-interactively' calls `other-buffer' when the selected window
is the minibuffer window indicates that such a thing may happen and it
will happen, for example, when I'm in the minibuffer and do M-:.

 >> Do you ever want to kill the minibuffer's buffer?
 >
 > No, never.
 >
 >> If not, your function should provide an
 >> appropriate workaround default just as `call-interactively' does.
 >
 > Well OK, I suppose - I can certainly try to do that.
 >
 > But I have never had to do it before.  Obviously, if the right thing to do is to
 > work around this hiccup then I can and might try to do that.  And as I said:

... as long as you can't tell me how you got into this hiccup ...

 >>>> Or as a workaround I can explicitly select the frame of the
 >>>> buffer I want to kill - e.g., click the title bar of frame *shell*.
 >>>> After I do that, that buffer becomes the default value for C-x k.
 >
 > But the point was that the minibuffer buffer was the (current-buffer) here,
 > suggesting to me that the minibuffer frame (and its buffer) was selected.
 >
 > Is that TRT?  I didn't think so.  I didn't think that just calling `redirect-*'
 > would/should also select the frame and its buffer.  That is why I said this:

Just calling `redirect-*' does not select the frame and its buffer.  But
`yes-or-no-p' does since otherwise you won't be able to type into the
minibuffer - here's the relevant piece in read_minibuf:

   /* Display this minibuffer in the proper window.  */
   Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil);
   Fselect_window (minibuf_window, Qnil);
   XWINDOW (minibuf_window)->hscroll = 0;

 >>>> IOW, it seems that not only is the input focus redirected
 >>>> to the minibuffer frame, but also the current buffer is
 >>>> changed to *Minibuf-0*.  And if I do `M-:
 >>>> (current-buffer)' I do get *Minibuf-0*.  Is it normal for
 >>>> frame-focus redirection to change the current buffer also?
 >>>> That does not seem right to me.
 >
 > None of that has to do with my `C-x k' command, I believe.  AFAIK, I do not
 > select the minibuffer frame or buffer.  I speculated that perhaps the C code for
 > read-from-minibuffer does, but I don't know that.

See above.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

>  > But the point was that the minibuffer buffer was the 
>  > (current-buffer) here, suggesting to me that the minibuffer
>  > frame (and its buffer) was selected.
>  >
>  > Is that TRT?  I didn't think so.  I didn't think that just 
>  > calling `redirect-*' would/should also select the frame and
>  > its buffer.  That is why I said this:
> 
> Just calling `redirect-*' does not select the frame and its 
> buffer.  But `yes-or-no-p' does since otherwise you won't be
> able to type into the minibuffer - here's the relevant piece
> in read_minibuf:
> 
>    /* Display this minibuffer in the proper window.  */
>    Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil);
>    Fselect_window (minibuf_window, Qnil);
>    XWINDOW (minibuf_window)->hscroll = 0;

Well, OK.  But normally, after the input is read the selected window/frame
returns to what it was before the reading.  No?

IOW, yes, it is normal and necessary for yes/no input to be entered in the
minibuffer window, so naturally that window must be selected for the duration of
that user input.

The problem is (apparently) that the minibuffer buffer remains selected after
the reading, i.e., the (current-buffer) is " *Minibuf-0*".  Thus, a subsequent
command such as `C-x k' sees that buffer as the current one.  That has not
happened before - it seems to come as a result of redirecting the frame focus,
but perhaps that is just a catalyst/revealer.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[martin rudalics]

 > Well, OK.  But normally, after the input is read the selected window/frame
 > returns to what it was before the reading.  No?

I don't know.  read_minibuf does (my remarks appear below the code):

   /* Choose the minibuffer window and frame, and take action on them.  */

   choose_minibuf_frame ();

   record_unwind_protect (choose_minibuf_frame_1, Qnil);

I don't understand the last two calls, IMHO one of them seems redundant.

   record_unwind_protect (Fset_window_configuration,
			 Fcurrent_window_configuration (Qnil));

I don't know which frame is selected here in your case.

   /* If the minibuffer window is on a different frame, save that
      frame's configuration too.  */
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
   if (!EQ (mini_frame, selected_frame))
     record_unwind_protect (Fset_window_configuration,
			   Fcurrent_window_configuration (mini_frame));

But this should restore the configuration of your minibuffer frame.  I
don't have the slightest idea whether and how the selected window is
preserved provided it's on another frame.  You could try checking via
`minibuffer-setup-hook' and `minibuffer-exit-hook' but I'm afraid the
latter is executed too early and you're still in the same state of
affairs as in the setup hook.  Are you stuck in the minibuffer window
even when you do `top-level'?

 > The problem is (apparently) that the minibuffer buffer remains selected after
 > the reading, i.e., the (current-buffer) is " *Minibuf-0*".  Thus, a subsequent
 > command such as `C-x k' sees that buffer as the current one.  That has not
 > happened before - it seems to come as a result of redirecting the frame focus,
 > but perhaps that is just a catalyst/revealer.

If this were the case, we'd have a bug.  But the code doesn't indicate that.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

> Are you stuck in the minibuffer window even when you do `top-level'?

I don't know what you mean by "stuck in the minibuffer window.

After the command I am at top level.  And I am in no way stuck in a minibuffer
window.

The problem is that the `current-buffer' is " *Minibuf-0*".  That's all.

>  > The problem is (apparently) that the minibuffer buffer 
>  > remains selected after the reading, i.e., the (current-buffer)
>  > is " *Minibuf-0*".  Thus, a subsequent command such as `C-x k'
>  > sees that buffer as the current one.  That has not
>  > happened before - it seems to come as a result of redirecting
>  > the frame focus, but perhaps that is just a catalyst/revealer.
> 
> If this were the case, we'd have a bug.  But the code doesn't 
> indicate that.

Not sure what "this" you are referring to: "it seems to come as a result..." or
the behavior that "the (current-buffer) is " *Minibuf-0*"."

I do not know what the cause is.  I was only wondering out loud whether it
somehow comes as a result of redirecting the focus.

But what is clear is that (current-buffer) is " *Minibuf-0*".

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[martin rudalics]

 > After the command I am at top level.  And I am in no way stuck in a minibuffer
 > window.
 >
 > The problem is that the `current-buffer' is " *Minibuf-0*".  That's all.

So you mean you are at top level, the selected window is the minibuffer
window, its buffer is current, and you've never seen such behavior.  Is
that a correct description of what you experience?

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

>  > After the command I am at top level.  And I am in no way 
>  > stuck in a minibuffer window.
>  >
>  > The problem is that the `current-buffer' is " 
>  > *Minibuf-0*".  That's all.
> 
> So you mean you are at top level, the selected window is the 
> minibuffer window, its buffer is current, and you've never
> seen such behavior.  Is that a correct description of what you
> experience?

I think we're both probably getting a bit lost in all of the emails, especially
with the lapse of time, different tries of different scenarios, and encountered
side issues (e.g. crashes).  I apologize for contributing to that.

Here's the (current) issue and scenario.  It uses my setup (with untweaked
oneonone.el but also with the other libraries that I use).  The only thing I've
done differently than usual is to evaluate this sexp:

(add-hook 'after-make-frame-functions
          (lambda (frame)
            (redirect-frame-focus frame
             (window-frame (minibuffer-window)))))

I do M-x shell.
Then I do C-x C-c.

The `yes-or-no-p' prompt about active processes appears in the minibuffer.  I
type "no" into the minibuffer.

So far so good.  Things are perfectly normal now, and I am at top level (the
minibuffer has exited normally).

I then do C-x k.

Because my setup automatically inserts the default value (what `M-n' gives),
that buffer-name value is inserted in the minibuffer, waiting for me to hit RET
to accept it or to edit it and then hit RET.

The default buffer name in this case is " *Minibuf-0*".  That is what I have
never seen before.  I.e., without adding that `add-hook' sexp (above), I do not
get this behavior.

But I am not in any way trapped in the minibuffer.  I can edit the buffer name
to kill the buffer I want.  Or I can hit C-g.  And so on.

The only problem is that the value of `(current-buffer)' is " *Minibuf-0*" at
that point.  I know that by testing with `message' etc.  That is why I
hypothesized that something in that frame focus redirection caused the buffer "
*Minibuf-0*" to become selected, i.e., the `current-buffer'.

But you corrected me, pointing out that `yes-or-no-p' does that: it selects the
minibuffer window/buffer.

If I do not do the `add-hook', then I cannot type yes/no to the `yes-or-no-p'
prompt, without first manually selecting the minibuffer frame (e.g. by clicking
its titlebar).  And if I do that then the symptoms are the same as when I use
the `add-hook': after typing "no", if I use C-x k then " *Minibuf-0*" is the
default buffer to kill.

But if (I do not do the `add-hook' and) I do `M-: (yes-or-no-p "Foo? ")' and I
answer "no", then `C-x k' uses another buffer (the one selected before the M-:)
as the default value.  I am not sure why this difference, i.e., why
`yes-or-no-p' does not leave " *Minibuf-0*" as the current buffer in this case.
But it probably has to do with the execution of command `M-:' - IOW, in that
test it is not just `yes-or-no-p' that is involved, but also `M-:'.

So perhaps this is only a problem with (because of) `yes-or-no-p'.  And perhaps
there is nothing that can (or should?) be done about it.  It is anyway a minor
problem compared to the general problem that this bug report is about: loss of
focus to the minibuffer frame.

I hope we are now clear about this `C-x k' default-buffer problem.  Dunno what
can or should be done about it.  It seems (to me, so far) to be a problem with
`yes-or-no-p' (and perhaps some other functions?):

In order to ask its question, `yes-or-no-p' not only redirects input focus to
the minibuffer but it also (apparently) selects the minibuffer's buffer.  And it
apparently leaves that buffer selected, as the `current-buffer'.

You know better than I what, if anything could/should be done to correct this.
Should `yes-or-no-p' use `with-current-buffer' or something, so that it finishes
by selecting again the buffer that was selected when it started?  I'm guessing
yes, but I know nothing about the code.  It seems wrong that it should change
the selected buffer to the minibuffer and leave it so changed.

The above behavior description holds for all Emacs versions I have.  The
`add-hook' solves the unfocused minibuffer frame problem for all versions.

That means also that for Emacs 24 I do not need to use the
`with-temp-buffer-window.el' code you sent.  It is sufficient to use the
`add-hook'.  Dunno whether that helps you decide something for Emacs 24.

Given the info above, do you think that the equivalent of that `add-hook' should
perhaps be built into Emacs?  IOW, is some code correction in order, to do
systematically what the `add-hook' workaround accomplishes?

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[martin rudalics]

 > Here's the (current) issue and scenario.  It uses my setup (with untweaked
 > oneonone.el but also with the other libraries that I use).  The only thing I've
 > done differently than usual is to evaluate this sexp:
 >
 > (add-hook 'after-make-frame-functions
 >           (lambda (frame)
 >             (redirect-frame-focus frame
 >              (window-frame (minibuffer-window)))))
 >
 > I do M-x shell.
 > Then I do C-x C-c.
 >
 > The `yes-or-no-p' prompt about active processes appears in the minibuffer.  I
 > type "no" into the minibuffer.
 >
 > So far so good.  Things are perfectly normal now, and I am at top level (the
 > minibuffer has exited normally).
 >
 > I then do C-x k.
 >
 > Because my setup automatically inserts the default value (what `M-n' gives),

What does M-n do?

 > that buffer-name value is inserted in the minibuffer, waiting for me to hit RET
 > to accept it or to edit it and then hit RET.
 >
 > The default buffer name in this case is " *Minibuf-0*".  That is what I have
 > never seen before.  I.e., without adding that `add-hook' sexp (above), I do not
 > get this behavior.

I understand.  Then we have to look at the command M-n is bound to.

 > But I am not in any way trapped in the minibuffer.  I can edit the buffer name
 > to kill the buffer I want.  Or I can hit C-g.  And so on.

But, apparently, whatever you do, the current buffer is still *Minibuf-0*.

 > The only problem is that the value of `(current-buffer)' is " *Minibuf-0*" at
 > that point.  I know that by testing with `message' etc.  That is why I
 > hypothesized that something in that frame focus redirection caused the buffer "
 > *Minibuf-0*" to become selected, i.e., the `current-buffer'.
 >
 > But you corrected me, pointing out that `yes-or-no-p' does that: it selects the
 > minibuffer window/buffer.

Let me try to correct this again: `yes-or-no-p' selects the minibuffer
window.  `redirect-frame-focus' does not select any window.  I don't
know how this is related to your problem.

 > If I do not do the `add-hook', then I cannot type yes/no to the `yes-or-no-p'
 > prompt, without first manually selecting the minibuffer frame (e.g. by clicking
 > its titlebar).  And if I do that then the symptoms are the same as when I use
 > the `add-hook': after typing "no", if I use C-x k then " *Minibuf-0*" is the
 > default buffer to kill.

... where C-x k is not bound to `kill-buffer' but to another function ...

 > But if (I do not do the `add-hook' and) I do `M-: (yes-or-no-p "Foo? ")' and I
 > answer "no", then `C-x k' uses another buffer (the one selected before the M-:)
 > as the default value.  I am not sure why this difference, i.e., why
 > `yes-or-no-p' does not leave " *Minibuf-0*" as the current buffer in this case.
 > But it probably has to do with the execution of command `M-:' - IOW, in that
 > test it is not just `yes-or-no-p' that is involved, but also `M-:'.

`eval-expression' does consider the minibuffer window selected when it's
called from within the minibuffer.  Doing

C-h f

and then

C-: (selected-window) RET

will print the minibuffer window.

 > So perhaps this is only a problem with (because of) `yes-or-no-p'.  And perhaps
 > there is nothing that can (or should?) be done about it.  It is anyway a minor
 > problem compared to the general problem that this bug report is about: loss of
 > focus to the minibuffer frame.
 >
 > I hope we are now clear about this `C-x k' default-buffer problem.  Dunno what
 > can or should be done about it.  It seems (to me, so far) to be a problem with
 > `yes-or-no-p' (and perhaps some other functions?):
 >
 > In order to ask its question, `yes-or-no-p' not only redirects input focus to
 > the minibuffer but it also (apparently) selects the minibuffer's buffer.  And it
 > apparently leaves that buffer selected, as the `current-buffer'.
 >
 > You know better than I what, if anything could/should be done to correct this.
 > Should `yes-or-no-p' use `with-current-buffer' or something, so that it finishes
 > by selecting again the buffer that was selected when it started?  I'm guessing
 > yes, but I know nothing about the code.  It seems wrong that it should change
 > the selected buffer to the minibuffer and leave it so changed.

The code that does the selection and the restoration is in read_minibuf
which `yes-or-no-p' calls.  As explained earlier, I don't understand
that code well enough in order to tell what to change.

 > The above behavior description holds for all Emacs versions I have.  The
 > `add-hook' solves the unfocused minibuffer frame problem for all versions.
 >
 > That means also that for Emacs 24 I do not need to use the
 > `with-temp-buffer-window.el' code you sent.  It is sufficient to use the
 > `add-hook'.  Dunno whether that helps you decide something for Emacs 24.

The code has to work without any additional setup.

 > Given the info above, do you think that the equivalent of that `add-hook' should
 > perhaps be built into Emacs?  IOW, is some code correction in order, to do
 > systematically what the `add-hook' workaround accomplishes?

I don't know, unfortunately.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'

[Drew Adams]

> What does M-n do?

M-n is standard Emacs in the minibuffer: it retrieves (inserts) the default
value provided to the minibuffer-reading function (e.g. `completing-read').
(And starting with Emacs 23 you can repeat M-n to cycle among multiple default
values.)

>  > The default buffer name in this case is " *Minibuf-0*".  
>  > That is what I have never seen before.  I.e., without adding that
>  > `add-hook' sexp (above), I do not get this behavior.
> 
> I understand.  Then we have to look at the command M-n is bound to.

It inserts the default value.  In this case, the default value is the value of
(current-buffer), as I explained.  The problem/mistake is that with the
`add-hook' the value of (current-buffer) is now buffer " *Minibuf-0*".

>  > But I am not in any way trapped in the minibuffer.  I can 
>  > edit the buffer name to kill the buffer I want.  Or I can hit C-g.
>  > And so on.
> 
> But, apparently, whatever you do, the current buffer is still 
> *Minibuf-0*.

Yes.  (current-buffer) should not be *Minibuf-0*.  (But (current-buffer) is only
the default value, so I can still use `C-x k' here, by ignoring the default.)

>  > The only problem is that the value of `(current-buffer)' 
>  > is " *Minibuf-0*" at that point.  I know that by testing with
>  > `message' etc.  That is why I hypothesized that something in that
>  > frame focus redirection caused the buffer " *Minibuf-0*" to become
>  > selected, i.e., the `current-buffer'.
>  >
>  > But you corrected me, pointing out that `yes-or-no-p' does 
>  > that: it selects the minibuffer window/buffer.
> 
> Let me try to correct this again: `yes-or-no-p' selects the minibuffer
> window.  `redirect-frame-focus' does not select any window.  I don't
> know how this is related to your problem.

That is what I understood. 

>  > If I do not do the `add-hook', then I cannot type yes/no 
>  > to the `yes-or-no-p' prompt, without first manually selecting
>  > the minibuffer frame (e.g. by clicking its titlebar).  And if I do
>  > that then the symptoms are the same as when I use the `add-hook':
>  > after typing "no", if I use C-x k then " *Minibuf-0*" is the
>  > default buffer to kill.
> 
> where C-x k is not bound to `kill-buffer' but to another function

Correct.  Same scenario, still.

>  > But if (I do not do the `add-hook' and) I do `M-: 
>  > (yes-or-no-p "Foo? ")' and I answer "no", then `C-x k' uses
>  > another buffer (the one selected before the M-:) as the default
>  > value.  I am not sure why this difference, i.e., why
>  > `yes-or-no-p' does not leave " *Minibuf-0*" as the current 
>  > buffer in this case.  But it probably has to do with the
>  > execution of command `M-:' - IOW, in that test it is not just
>  > `yes-or-no-p' that is involved, but also `M-:'.
> 
> `eval-expression' does consider the minibuffer window selected when
> it's called from within the minibuffer.  Doing C-h f and then C-:
> (selected-window) RET will print the minibuffer window.

Right (but M-:, not C-:).

>  > You know better than I what, if anything could/should be 
>  > done to correct this.  Should `yes-or-no-p' use
>  > `with-current-buffer' or something, so that it finishes
>  > by selecting again the buffer that was selected when it 
>  > started?  I'm guessing yes, but I know nothing about the code.
>  > It seems wrong that it should change the selected buffer to the
>  > minibuffer and leave it so changed.
> 
> The code that does the selection and the restoration is in 
> read_minibuf which `yes-or-no-p' calls.  As explained earlier, I don't
> understand that code well enough in order to tell what to change.

OK.  I, even less, obviously.

But at any rate, this wrong-buffer problem is minor.  I don't want it to
sidetrack us too much.

The bigger issue is to have code somehow DTRT so that minibuffer interaction
that is coupled with the popup of an informational-only window/frame, keeps the
focus in the minibuffer frame.  IOW, come up with some construct that lets code
identify a particular minibuffer interaction as one that should keep the focus
in the minibuffer frame.  

"Keep" here might mean redirect to the minibuffer if something outside Emacs and
outside the user moves the focus away from it.  And that "outside Emacs and
outside the user" would be key, if we could in fact detect it.  IOW, Emacs code
can only say that some interaction should keep the focus in the minibuffer frame
(or not, depending on what's intended).  Emacs cannot prevent MS Windows or
whatever from changing the focus.  And we would want the user to be able to
change the focus explicitly (during the minibuffer interaction), of course.

>  > The above behavior description holds for all Emacs versions I have.
>  > The `add-hook' solves the unfocused minibuffer frame problem 
>  > for all versions.

Again, I was wrong about that (e.g. *Backtrace* case).  There are some cases
where the minibuffer is active and a frame is popped that is not merely
informational but should in fact receive the input focus.

>  > That means also that for Emacs 24 I do not need to use the
>  > `with-temp-buffer-window.el' code you sent.  It is sufficient to
>  > use the `add-hook'.  Dunno whether that helps you decide something 
>  > for Emacs 24.
> 
> The code has to work without any additional setup.

Of course.  I meant only that perhaps the equivalent of what I did in the hook
might be something to do in general.  I'm now backtracking on that because doing
that systematically is not the panacea that I thought it might be.

>  > Given the info above, do you think that the equivalent of 
>  > that `add-hook' should perhaps be built into Emacs?  IOW, is some
>  > code correction in order, to do systematically what the `add-hook'
>  > workaround accomplishes?
> 
> I don't know, unfortunately.

The answer is no, because I said "systematically", and that is not TRT (e.g.
*Backtrace*).

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

[off-list]:
> I have not been using that `add-hook' in my normal use of 
> Emacs, but I am going to start doing so now, to see if it has 
> any negative effects.  I'll keep you posted if I find any.

No sooner did I try than I ran into problems.

Just `C-x 4 f some-file' is enough to see that this (the `add-hook' to redirect
focus) is not a fix.  After `C-x 4 f some-file', the new frame does not have the
input focus - the minibuffer frame has it (so `C-f' etc. do the wrong thing).

I think this all goes back to the problem of distinguishing a frame that is
popped up only for informational purposes, _during a user interaction/dialog_,
from a frame that is popped up with the intention of using its buffer (as the
`current-buffer').

IOW, the case that we were trying to solve, whether for the popup showing active
processes or the popup showing marked files in Dired, is a case where the frame
is popped up only to ask a question in the minibuffer.  It is only in that case
that the input focus should be directed to the minibuffer.

How to distinguish that case, I don't know.  But it seems like the invariant
should be that whenever the minibuffer is being used for input its frame should
have the focus.

That is the problem that needs solving, I think: how to ensure that all
minibuffer interaction takes place (always) with the minibuffer frame having the
input focus.

I then tried this, instead:

(add-hook 'after-make-frame-functions
          (lambda (frame)
            (when (active-minibuffer-window)
              (redirect-frame-focus frame
                (window-frame (minibuffer-window))))))

But that is no good because the minibuffer is not active quite yet, at the
moment the hook takes effect.  It is apparently the case that FIRST the new
frame is created and THEN the minibuffer is used/activated.

In the *shell* scenario, when I hit `C-x C-c' and try to type "no", the `n'
invokes `View-search-last-regexp-forward' - I get this:

Signaling: (error "No previous View-mode search")
  signal(error ("No previous View-mode search"))
  error("No previous View-mode search")
  view-search(1 nil)
  View-search-last-regexp-forward(1)
  call-interactively(View-search-last-regexp-forward)
  yes-or-no-p("Active processes exist; kill them and exit anyway? ")
  save-buffers-kill-emacs(nil)
  call-interactively(save-buffers-kill-emacs)

That is with Emacs 20, where buffer *Process List* is in View mode, where `n' is
bound to `View-search-last-regexp-forward'.  In Emacs 24.1, I don't get the
error, but the behavior is similar (the `n' is typed into frame *Process List*,
not into the minibuffer frame).

I also tried this:

(add-hook 'minibuffer-setup-hook
          (lambda ()
            (unless (eq (selected-frame)
                        (window-frame (minibuffer-window)))
              (redirect-frame-focus (selected-frame)
                (window-frame (minibuffer-window))))))

But that had the same effect: the `n' of "no" went to the *Process List* frame.
And I added a call to `message' before the `unless', to see what
(selected-frame) was.  And I was surprised to see that it was in fact the
minibuffer frame (so the `unless' became a no-op)  So it seems that the
minibuffer frame was selected, but did not receive input (did not have the
focus).

I then got rid of the `unless' guard, and just redirected systematically, in
`minibuffer-setup-hook', and I still got the same behavior (the typed `n' went
to the *Process List* frame).  Clearly, that just redirected the minibuffer
frame (the selected frame) to itself, whereas what is needed is to redirect the
newly created *Process List* frame's focus to the minibuffer frame.

Finally, knowing that the selected frame is the minibuffer frame, but it does
not have the focus, I tried this:

(add-hook 'after-make-frame-functions
          (lambda (frame)
            (when (eq (selected-frame)
                      (window-frame (minibuffer-window)))
              (redirect-frame-focus frame
                (window-frame (minibuffer-window))))))

And that solves the problem.  IOW, that does just as much good as the systematic
redirection (i.e., without the `when') did, but it does not have the drawback
that each time a frame is popped up it loses the focust to the minibuffer frame.

(The only remaining problem is the other one we discussed, regarding the value
of (current-buffer) after the minibuffer is exited, so that a subsequent `C-x k'
has " *Minibuf-0*" as the default buffer name.)

That's the best thing I've come up with, but perhaps you have a suggestion.
`after-make-frame-functions' seems like the right place to do the deed, because
it knows about the new frame, which is the one whose focus needs to be
redirected.

Again, this all seems to underline the need for a notion/mechanism of defining
or detecting a user dialog that uses the minibuffer while popping up an
informational frame only for the duration of the minibuffer interaction (input).

Anyway, I will use that code (the last above) for a while, to see how it goes.
Hope this info helps a bit.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 > Just `C-x 4 f some-file' is enough to see that this (the `add-hook' to redirect
 > focus) is not a fix.  After `C-x 4 f some-file', the new frame does not have the
 > input focus - the minibuffer frame has it (so `C-f' etc. do the wrong thing).
 >
 > I think this all goes back to the problem of distinguishing a frame that is
 > popped up only for informational purposes, _during a user interaction/dialog_,
 > from a frame that is popped up with the intention of using its buffer (as the
 > `current-buffer').

Yes.

 > IOW, the case that we were trying to solve, whether for the popup showing active
 > processes or the popup showing marked files in Dired, is a case where the frame
 > is popped up only to ask a question in the minibuffer.  It is only in that case
 > that the input focus should be directed to the minibuffer.
 >
 > How to distinguish that case, I don't know.  But it seems like the invariant
 > should be that whenever the minibuffer is being used for input its frame should
 > have the focus.

I don't believe the underlying mechanism for popping up frames ever will
have the necessary knowledge to decide.

 > That is the problem that needs solving, I think: how to ensure that all
 > minibuffer interaction takes place (always) with the minibuffer frame having the
 > input focus.
 >
 > I then tried this, instead:
 >
 > (add-hook 'after-make-frame-functions
 >           (lambda (frame)
 >             (when (active-minibuffer-window)
 >               (redirect-frame-focus frame
 >                 (window-frame (minibuffer-window))))))
 >
 > But that is no good because the minibuffer is not active quite yet, at the
 > moment the hook takes effect.  It is apparently the case that FIRST the new
 > frame is created and THEN the minibuffer is used/activated.

Indeed.

 > I also tried this:
 >
 > (add-hook 'minibuffer-setup-hook
 >           (lambda ()
 >             (unless (eq (selected-frame)
 >                         (window-frame (minibuffer-window)))
 >               (redirect-frame-focus (selected-frame)
 >                 (window-frame (minibuffer-window))))))
 >
 > But that had the same effect: the `n' of "no" went to the *Process List* frame.
 > And I added a call to `message' before the `unless', to see what
 > (selected-frame) was.  And I was surprised to see that it was in fact the
 > minibuffer frame (so the `unless' became a no-op)  So it seems that the
 > minibuffer frame was selected, but did not receive input (did not have the
 > focus).

Yes.  In read_minibuf the

   Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil);
   Fselect_window (minibuf_window, Qnil);

comes before

   Frun_hooks (1, &Qminibuffer_setup_hook);

 > I then got rid of the `unless' guard, and just redirected systematically, in
 > `minibuffer-setup-hook', and I still got the same behavior (the typed `n' went
 > to the *Process List* frame).  Clearly, that just redirected the minibuffer
 > frame (the selected frame) to itself, whereas what is needed is to redirect the
 > newly created *Process List* frame's focus to the minibuffer frame.
 >
 > Finally, knowing that the selected frame is the minibuffer frame, but it does
 > not have the focus, I tried this:
 >
 > (add-hook 'after-make-frame-functions
 >           (lambda (frame)
 >             (when (eq (selected-frame)
 >                       (window-frame (minibuffer-window)))
 >               (redirect-frame-focus frame
 >                 (window-frame (minibuffer-window))))))
 >
 > And that solves the problem.  IOW, that does just as much good as the systematic
 > redirection (i.e., without the `when') did, but it does not have the drawback
 > that each time a frame is popped up it loses the focust to the minibuffer frame.

Using `selected-frame' within `after-make-frame-functions' seems awfully
fragile to me.  IMHO this can't ever work reliably.

 > (The only remaining problem is the other one we discussed, regarding the value
 > of (current-buffer) after the minibuffer is exited, so that a subsequent `C-x k'
 > has " *Minibuf-0*" as the default buffer name.)
 >
 > That's the best thing I've come up with, but perhaps you have a suggestion.
 > `after-make-frame-functions' seems like the right place to do the deed, because
 > it knows about the new frame, which is the one whose focus needs to be
 > redirected.
 >
 > Again, this all seems to underline the need for a notion/mechanism of defining
 > or detecting a user dialog that uses the minibuffer while popping up an
 > informational frame only for the duration of the minibuffer interaction (input).
 >
 > Anyway, I will use that code (the last above) for a while, to see how it goes.
 > Hope this info helps a bit.

Let's see.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

>  > I think this all goes back to the problem of 
>  > distinguishing a frame that is popped up only for
>  > informational purposes, _during a user interaction/dialog_,
>  > from a frame that is popped up with the intention of using 
>  > its buffer (as the `current-buffer').
> 
> Yes.
> 
>  > IOW, the case that we were trying to solve, whether for 
>  > the popup showing active processes or the popup showing
>  > marked files in Dired, is a case where the frame
>  > is popped up only to ask a question in the minibuffer.  It 
>  > is only in that case that the input focus should be
>  > directed to the minibuffer.
>  >
>  > How to distinguish that case, I don't know.  But it seems 
>  > like the invariant should be that whenever the minibuffer
>  > is being used for input its frame should have the focus.
> 
> I don't believe the underlying mechanism for popping up 
> frames ever will have the necessary knowledge to decide.

Agreed.  (I almost want to say "Of course", but I did pose the question.)

My contention from the beginning (i.e., before this thread, in other
discussions) is that we need an explicit notion of a minibuffer dialog that
should keep the focus in the minibuffer, so that code can ensure that popped up
frames do not grab the focus away from the minibuffer during the dialog.  Or if
they do, other than via Emacs code or a user action - e.g. via MS Windows, then
they are properly redirected back.

In terms of implementation it could perhaps be a `with-*<something>'
encapsulation.  A given code context DOES know when it is using a popup window
(which could thus be a popup frame) only to provide information while asking a
minibuffer question, and it can wrap the minibuffer interaction and frame
creation in such an encapsulation.

The encapsulation would redirect any new frames created to the minibuffer for
the duration.  But it would need to allow Emacs code within it the possibility
of redirecting the focus (even using a recursive minibuffer invocation that is,
itself, not so encapsulated?).  And it would of course need to allow the user to
explicitly change the focus.

IOW, it would handle new informational frames the way a standalong *Completions*
frame is handled: when it is displayed its focus is redirected to the minibuffer
frame, but that does not prevent Emacs code or the user from switching the focus
to it during minibuffer activity.  

See the code I sent for my *Completions* frame for an example.  It does this
when it displays *Completions* (the selected-frame):
(redirect-frame-focus (selected-frame) 1on1-minibuffer-frame)

>  > That is the problem that needs solving, I think: how to 
>  > ensure that all minibuffer interaction takes place (always)
>  > with the minibuffer frame having the
>  > input focus.

No, I was wrong about that "(always)" - see below.

>  > I also tried this:
>  >
>  > (add-hook 'minibuffer-setup-hook
>  >           (lambda ()
>  >             (unless (eq (selected-frame)
>  >                         (window-frame (minibuffer-window)))
>  >               (redirect-frame-focus (selected-frame)
>  >                 (window-frame (minibuffer-window))))))
>  >
>  > But that had the same effect: the `n' of "no" went to the 
>  > *Process List* frame.  And I added a call to `message'
>  > before the `unless', to see what (selected-frame) was.
>  > And I was surprised to see that it was in fact the
>  > minibuffer frame (so the `unless' became a no-op)  So it 
>  > seems that the minibuffer frame was selected, but did not
>  > receive input (did not have the focus).
> 
> Yes.  In read_minibuf the
>
>    Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil);
>    Fselect_window (minibuf_window, Qnil);
>
> comes before
>
>    Frun_hooks (1, &Qminibuffer_setup_hook);
> 
>  > Finally, knowing that the selected frame is the minibuffer 
>  > frame, but it does not have the focus, I tried this:
>  >
>  > (add-hook 'after-make-frame-functions
>  >           (lambda (frame)
>  >             (when (eq (selected-frame)
>  >                       (window-frame (minibuffer-window)))
>  >               (redirect-frame-focus frame
>  >                 (window-frame (minibuffer-window))))))
>  >
>  > And that solves the problem.  IOW, that does just as much 
>  > good as the systematic redirection (i.e., without the
>  > `when') did, but it does not have the drawback
>  > that each time a frame is popped up it loses the focus to 
>  > the minibuffer frame.
> 
> Using `selected-frame' within `after-make-frame-functions' 
> seems awfully fragile to me.  IMHO this can't ever work reliably.

I cannot speak to that; you're the expert here.  But do you have a
counter-example, just for the sake of concreteness?  (Not important, just
wondering.)

>  > (The only remaining problem is the other one we discussed, 
>  > regarding the value of (current-buffer) after the
>  > minibuffer is exited, so that a subsequent `C-x k'
>  > has " *Minibuf-0*" as the default buffer name.)
>  >
>  > That's the best thing I've come up with, but perhaps you 
>  > have a suggestion.  `after-make-frame-functions' seems
>  > like the right place to do the deed, because it knows
>  > about the new frame, which is the one whose focus needs
>  > to be redirected.

I want to say "ONLY IT knows..." (among existing hooks), but I am not sure of
that.  IOW, of the hooks I am aware of, this one seems the most pertinent here.

>  > Again, this all seems to underline the need for a 
>  > notion/mechanism of defining or detecting a user dialog

I think you are probably right that "detecting" might be a pipe dream.  What I
really have had in mind is mentioned above: the code would encapsulate a
minibuffer reading that might pop up an informational window, redirecting focus
for any new frames to the minibuffer.

>  > that uses the minibuffer while popping up an informational
>  > frame only for the duration of the minibuffer interaction
>  > (input).

The important point here is "informational...only".

And this is where I need to mention an example of why it is not a solution to do
this redirection systematically, testing only
(when (eq (selected-frame) (window-frame (minibuffer-window))).

A case in point is the debugger.  In my setup *Backtrace* pops up in a
special-display frame.  It is not the case that this buffer is for information
only.  It is truly necessary that *Backtrace* receive the focus.  So this is a
good case where my redirection "fix" does not do the right thing.

>  > Anyway, I will use that code (the last above) for a while, 
>  > to see how it goes.

See previous.  I was mistaken in supposing that doing this systematically would
DTRT.  There are clearly some cases where a frame is popped up during minibuffer
input, and that frame is NOT only for informational purposes but should in fact
receive the input focus.

It is only the code that invokes reading from the minibuffer and pops up the
other window/frame that can know whether the focus should be in that
window/frame or in the minibuffer.

But here's the thing: in the case of windows instead of frames, Emacs DTRT, no?
Emacs distinguishes the case of window *Process List* from window *Backtrace*,
giving the focus to the latter and not to the former.  Why can't we make Emacs
DTRT for frames, just as it does for windows?

I know that MS Windows altering the focus throws a monkey wrench into the mix,
but surely we can find some way to KEEP the focus (i.e. re-focus if necessary)
where Emacs put it (correctly).

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 > My contention from the beginning (i.e., before this thread, in other
 > discussions) is that we need an explicit notion of a minibuffer dialog that
 > should keep the focus in the minibuffer, so that code can ensure that popped up
 > frames do not grab the focus away from the minibuffer during the dialog.  Or if
 > they do, other than via Emacs code or a user action - e.g. via MS Windows, then
 > they are properly redirected back.
 >
 > In terms of implementation it could perhaps be a `with-*<something>'
 > encapsulation.  A given code context DOES know when it is using a popup window
 > (which could thus be a popup frame) only to provide information while asking a
 > minibuffer question, and it can wrap the minibuffer interaction and frame
 > creation in such an encapsulation.
 >
 > The encapsulation would redirect any new frames created to the minibuffer for
 > the duration.  But it would need to allow Emacs code within it the possibility
 > of redirecting the focus (even using a recursive minibuffer invocation that is,
 > itself, not so encapsulated?).  And it would of course need to allow the user to
 > explicitly change the focus.
 >
 > IOW, it would handle new informational frames the way a standalong *Completions*
 > frame is handled: when it is displayed its focus is redirected to the minibuffer
 > frame, but that does not prevent Emacs code or the user from switching the focus
 > to it during minibuffer activity.
 >
 > See the code I sent for my *Completions* frame for an example.  It does this
 > when it displays *Completions* (the selected-frame):
 > (redirect-frame-focus (selected-frame) 1on1-minibuffer-frame)

What you request here is trivial.  read_minibuf has this statement

   if (!EQ (mini_frame, selected_frame))
     Fredirect_frame_focus (selected_frame, mini_frame);

so if the new frame is already selected when this statement is executed,
reading from the minibuffer works out of the box as in my
`with-temp-buffer-window.el' and your *Completions* code examples.

The problem happens in the following scenario:

(1) The application requests (implicitly) to make a new frame.

(2) The application ask to read from the minibuffer with some old frame
     selected.  In this case the statement above does not redirect focus
     because either the old frame is the minibuffer frame or the old
     frame's focus is already redirected to the minibuffer frame.

(3) Emacs eventually selects the new frame in `handle-switch-frame'.

After that, the new frame gets the keystrokes for reading from the
minibuffer but Emacs won't find a redirection in kbd_buffer_get_event.

 >>  > Finally, knowing that the selected frame is the minibuffer
 >>  > frame, but it does not have the focus, I tried this:
 >>  >
 >>  > (add-hook 'after-make-frame-functions
 >>  >           (lambda (frame)
 >>  >             (when (eq (selected-frame)
 >>  >                       (window-frame (minibuffer-window)))
 >>  >               (redirect-frame-focus frame
 >>  >                 (window-frame (minibuffer-window))))))
 >>  >
 >>  > And that solves the problem.  IOW, that does just as much
 >>  > good as the systematic redirection (i.e., without the
 >>  > `when') did, but it does not have the drawback
 >>  > that each time a frame is popped up it loses the focus to
 >>  > the minibuffer frame.
 >>
 >> Using `selected-frame' within `after-make-frame-functions'
 >> seems awfully fragile to me.  IMHO this can't ever work reliably.
 >
 > I cannot speak to that; you're the expert here.  But do you have a
 > counter-example, just for the sake of concreteness?  (Not important, just
 > wondering.)

No and I am no expert here.  In any case the idea of doing

 >>  >             (when (eq (selected-frame)
 >>  >                       (window-frame (minibuffer-window)))

means that when you pop up a new frame when a non-minibuffer frame is
selected you never redirect, while you always redirect when the
minibuffer frame is selected.  This conditioning cannot always work
correctly IMHO.

 >>  > That's the best thing I've come up with, but perhaps you
 >>  > have a suggestion.  `after-make-frame-functions' seems
 >>  > like the right place to do the deed, because it knows
 >>  > about the new frame, which is the one whose focus needs
 >>  > to be redirected.
 >
 > I want to say "ONLY IT knows..." (among existing hooks), but I am not sure of
 > that.  IOW, of the hooks I am aware of, this one seems the most pertinent here.

It knows that a new frame will be constructed.  But it does not know
whether focus shall be redirected.

 >>  > Again, this all seems to underline the need for a
 >>  > notion/mechanism of defining or detecting a user dialog
 >
 > I think you are probably right that "detecting" might be a pipe dream.  What I
 > really have had in mind is mentioned above: the code would encapsulate a
 > minibuffer reading that might pop up an informational window, redirecting focus
 > for any new frames to the minibuffer.

And what you have in mind here should be distinguishable from other
things that pop up frames but do not want the redirection.

 >>  > that uses the minibuffer while popping up an informational
 >>  > frame only for the duration of the minibuffer interaction
 >>  > (input).
 >
 > The important point here is "informational...only".
 >
 > And this is where I need to mention an example of why it is not a solution to do
 > this redirection systematically, testing only
 > (when (eq (selected-frame) (window-frame (minibuffer-window))).
 >
 > A case in point is the debugger.  In my setup *Backtrace* pops up in a
 > special-display frame.  It is not the case that this buffer is for information
 > only.  It is truly necessary that *Backtrace* receive the focus.

Is it?  I never gave it a thought.  But I perfectly understand that when
*Backtrace* pops up you don't want to redirect focus to the minibuffer
frame.

 > So this is a
 > good case where my redirection "fix" does not do the right thing.

If you hardwire redirection in `after-make-frame-functions', you get bad
results in the case where the redirection is not wanted.  What you want
is some clairvoyance in step (1) of my description above whether step
(2) will be performed.  `with-temp-buffer-window' avoids that by asking
the `yes-or-no-p' question in the new frame.  Older application don't
and that's our trouble.

 >>  > Anyway, I will use that code (the last above) for a while,
 >>  > to see how it goes.
 >
 > See previous.  I was mistaken in supposing that doing this systematically would
 > DTRT.  There are clearly some cases where a frame is popped up during minibuffer
 > input, and that frame is NOT only for informational purposes but should in fact
 > receive the input focus.
 >
 > It is only the code that invokes reading from the minibuffer and pops up the
 > other window/frame that can know whether the focus should be in that
 > window/frame or in the minibuffer.

It's not that simple.  The invoking code doesn't care about focus and in
particular not about some frame whose eventually popping up will cause
problems.  It expects the reading from the minibuffer mechanism DTRT.

 > But here's the thing: in the case of windows instead of frames, Emacs DTRT, no?
 > Emacs distinguishes the case of window *Process List* from window *Backtrace*,
 > giving the focus to the latter and not to the former.  Why can't we make Emacs
 > DTRT for frames, just as it does for windows?

For windows on the same frame we can differ between `display-buffer' and
`pop-to-buffer'.  For windows on different frames we have the
complication that the `handle-switch-frame' event triggered by the OS
causes Emacs to select that frame, that is, implicitly replace
`display-buffer' by `pop-to-buffer'.

 > I know that MS Windows altering the focus throws a monkey wrench into the mix,
 > but surely we can find some way to KEEP the focus (i.e. re-focus if necessary)
 > where Emacs put it (correctly).

As far as old code is concerned you probably are overly optimistic.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

> The problem happens in the following scenario:
> 
> (1) The application requests (implicitly) to make a new frame.
> 
> (2) The application ask to read from the minibuffer with some 
>     old frame selected.  In this case the statement above does not 
>     redirect focus because either the old frame is the minibuffer
>     frame or the old frame's focus is already redirected to the
>     minibuffer frame.
> 
> (3) Emacs eventually selects the new frame in `handle-switch-frame'.
> 
> After that, the new frame gets the keystrokes for reading from the
> minibuffer but Emacs won't find a redirection in kbd_buffer_get_event.

Agreed; that is what we have been discussing.

> the idea of doing
> (when (eq (selected-frame)
>           (window-frame (minibuffer-window)))
> 
> means that when you pop up a new frame when a non-minibuffer frame is
> selected you never redirect, while you always redirect when the
> minibuffer frame is selected.  This conditioning cannot always work
> correctly IMHO.

Which is what I said in my last message.  It must not be done systematically.  I
gave the counter-example of a *Backtrace* frame.

It is only the code that is calling for such a user dialog that knows that that
is what is being called for.  By "such a user dialog", again, I mean (a) the
display of a buffer for information only, i.e., one that does not need the input
focus, and (b) request of user input with the previous buffer remaining current
and the minibuffer having the input focus.

That is the use case that is problematic.  It is the case where the above
systematic "fix" is inappropriate.  There might be other such use cases, but it
is the only one I have encountered.  And I have encountered it in several
different places (e.g., Dired *Marked Files* popup, *Process List* popup).

My suggestion is, again, that we try to come up with a construct that covers
this use case, and then use it in the appropriate places: places where we do (a)
+ (b).

On the other hand, if you know of a way to _detect_ such an intention on the
part of the developer, i.e., somehow _detect_ whether the displayed buffer
should have input focus, then I'm all ears.

I don't expect that to be possible, which is why I propose that the developer
make the intention explicit by using a new construct (e.g. a macro) that takes
care of this.

The construct would display the informational buffer and redirect its input
focus to a standalone minibuffer, if there is one.  If there is no standalone
minibuffer frame, then that part could be a no-op, AFAICT.  Something like this:

(with-unfocused-buffer-displayed BUFFER &body BODY)

where BUFFER is displayed for information only, and where BODY would include the
call(s) that read from the minibuffer.

The current buffer would remain what it was beforehand, and _if_ BUFFER gets
displayed in its own frame and _if_ there is a standalone minibuffer frame,
_then_ the focus for BUFFER's frame gets automatically redirected to the
minibuffer frame.  If those conditions do not hold then there is no special
handling needed - the construct can essentially be a no-op in that case
(AFAICT).

How something like this would be implemented I'm not sure.  When the redirection
would need to take place, to DTRT, I'm not sure.  Perhaps it would need to be
done more than once.

But an important further requirement is that nothing should prevent Emacs code
in BODY or called from within BODY from switching the input focus to BUFFER's
frame.  Likewise, nothing should prevent the user from explicitly switching the
focus to BUFFER's frame.

The only switching of focus to BUFFER's frame that this construct would be
trying to prevent would be something that comes from neither a user action nor
the Emacs code - in particular, MS Windows auto-focussing a newly created frame.

Again, I don't know the "how".  But (so far) I'm convinced that this has to be
an explicit Emacs construct: there needs to be some way for a Lisp programmer to
communicate the intention that BUFFER is not intended to have the input focus
during BODY (unless that is done by the user or by code within BODY).

I do not expect that the problematic use case we've been discussing can be
detected and dealt with correctly in an automatic way.  If the programmer
intention cannot be made explicit then there is no way to know what TRT is.

It's problematic enough even with the intention communicated, in the sense that
we need to allow users and Emacs code to give focus to BUFFER's frame if they
want to.  IOW, even if we _know_ that initially BUFFER's frame should not be
focused, it is hard enough to prevent or undo focusing by MS Windows while still
allowing users and Emacs to focus BUFFER.

>  >>  > That's the best thing I've come up with, but perhaps you
>  >>  > have a suggestion.  `after-make-frame-functions' seems
>  >>  > like the right place to do the deed, because it knows
>  >>  > about the new frame, which is the one whose focus needs
>  >>  > to be redirected.
>  >
>  > I want to say "ONLY IT knows..." (among existing hooks), but I am not
>  > sure of that.  IOW, of the hooks I am aware of, this one seems the 
>  > most pertinent here.
> 
> It knows that a new frame will be constructed.  But it does not know
> whether focus shall be redirected.

That's the point of providing programmers with a construct to express that
intention explicitly: "This buffer's frame, if it is displayed in its own frame,
should not receive the focus."

>  >>  > Again, this all seems to underline the need for a
>  >>  > notion/mechanism of defining or detecting a user dialog
>  >
>  > I think you are probably right that "detecting" might be a 
>  > pipe dream.  What I really have had in mind is mentioned above:
>  > the code would encapsulate a minibuffer reading that might
>  > pop up an informational window,

By "might pop up" I meant that _if_ informational BUFFER is popped up in its own
frame, _then_ the intention is that that frame not receive the input focus.

>  > redirecting focus for any new frames to the minibuffer.
> 
> And what you have in mind here should be distinguishable from other
> things that pop up frames but do not want the redirection.

Not sure I follow you.  Are you referring to the equivalent of possibly nested
`with-unfocused-buffer-displayed' calls?

Here's the thing.  I don't know whether we can come up with something that is
100% reliable.  But the important thing, I think, is to have _some_ programmatic
translation of the programmer intention that this BUFFER be shown without giving
it the input focus.

Today there is no way for a programmer to indicate that.  S?he might not
_expect_ that the focus would be grabbed away from a minibuffer frame and given
to a new frame, but that lack of expectation today is mainly based on
inexperience with a standalone minibuffer and MS Windows.

What's needed is some way to reinforce the programmer's natural expectation that
the user can in fact type input into the minibuffer even when the informational
buffer gets displayed.

No one would naturally expect that not to be the case, but it can be the case,
unfortunately.  So the idea is to somehow support the natural expectation and
take away the possibility (or reduce the probability) of MS Windows interfering
with what should be a simple user dialog.

>  >>  > that uses the minibuffer while popping up an informational
>  >>  > frame only for the duration of the minibuffer interaction
>  >>  > (input).
>  >
>  > The important point here is "informational...only".
>  >
>  > And this is where I need to mention an example of why it 
>  > is not a solution to do this redirection systematically, testing only
>  > (when (eq (selected-frame) (window-frame (minibuffer-window))).
>  >
>  > A case in point is the debugger.  In my setup *Backtrace* 
>  > pops up in a special-display frame.  It is not the case that this 
>  > buffer is for information only.  It is truly necessary that
>  > *Backtrace* receive the focus.
> 
> Is it?  I never gave it a thought.

Yes, it seems to be necessary.  The proof being that when I applied my partly
misguided "fix" systematically the *Backtrace* frame lost the focus to the
minibuffer frame and I could not use it.  I had to click the *Backtrace* frame
to give it back the focus.

> But I perfectly understand that when *Backtrace* pops up you
> don't want to redirect focus to the minibuffer frame.

Correct.  *Backtrace* is not popped up for info only.  It is popped up for
interacting with the user.  It is supposed to have the input focus, even if it
is popped during a minibuffer interaction.

Note that this is not really an example of what I meant above by Emacs code
within BODY being able to switch focus to BUFFER, because *Backtrace* would not
be invoked using `with-unfocused-buffer-displayed'.  It is not the intention
that it be displayed for info only.

But it is an example of why systematically redirecting the focus to the
minibuffer frame from any new frame that pops up when the minibuffer is active
is not TRT.

>  > So this is a good case where my redirection "fix" does not do
>  > the right thing.
> 
> If you hardwire redirection in `after-make-frame-functions', 
> you get bad results in the case where the redirection is not wanted.

Correct.  That is what I was saying too.  Systematic or hard-wire is not
appropriate.

The first lesson (for me) was learning that it can only be appropriate when the
minibuffer is active.  The second lesson was that even when the minibuffer is
active it might not be appropriate.

In the end, it is only the programmer who knows whether some buffer that is
popped up should be denied the input focus.

> What you want is some clairvoyance in step (1) of my description
> above whether step (2) will be performed.

No, I don't think so.  I don't believe in such clairvoyance (but I'm open to
being convinced).  Instead, I believe in the programmer stating that the buffer
is not intended to have the focus.  (But that nothing should prevent Emacs or
the user from giving it the focus at some point.)

> `with-temp-buffer-window' avoids that by asking the `yes-or-no-p'
> question in the new frame.

The issue at stake is the case of a standalone minibuffer.  I don't see any
problem if there is no standalone minibuffer frame.

With a standalone minibuffer frame, the proper behavior is for the minibuffer
frame to be used for all minibuffer activity.  Anything else is less than
desirable, even if it might be acceptable if no better solution could be found
in some case.

A user of a standalone minibuffer looks there for all echo-area output and all
minibuffer input.  That is one of the reasons for using a standalone minibuffer:
a single place where all Q & A with the user takes place.

Well, nearly all.  Yes, there are some times where things like `read-event' are
used instead of the minibuffer.  But let's not get pedantic; this is about use
of the minibuffer and echo area.  A standalone minibuffer offers the advantage
of always looking to the same place on the screen for user I/O.

> Older application don't and that's our trouble.

That's one problem.  Admittedly, that can be looked at as a nice-to-have, and I
might be the only person who cares much about that.

The other potential trouble is the need to show an informational buffer that
does not necessarily correspond to what you have defined for
`with-temp-buffer-window'.

To be clear, I do not know whether such a need exists much in practice.  But it
looks to me like your macro and the related code you sent make additional
assumptions about the buffer that is popped up that constrain it more than what
I was describing abstractly for the hypothetical
`with-unfocused-buffer-displayed'.

The buffer in the case of `with-temp-buffer-window' starts out from scratch (it
must be empty), etc.  In a nutshell, your construct assumes that the buffer
itself is temporary, whereas the only real need for our problematic use case is
that the buffer's _display_, in a separate frame, be temporary.

IOW, I think your solution is more constraining/limited and doesn't really
address the general problem, which is that of displaying _any_ buffer for only
informational use (at least initially, allowing for user/code to intentionally
switch focus to it).  And AFAIK the problem we are trying to solve occurs only
when such a buffer appears in its own frame.

Your solution certainly helps for things like *Process List* and *Marked Files*.
But the characterization of the problem is, logically, in terms of a buffer that
is displayed temporarily during a minibuffer dialog, in its own frame, and whose
frame should not have the input focus in that context.

Am I wrong about that?

Don't get me wrong.  I think your code (the little that I've tried using it) is
a definite improvement for the problem cases we've actually encountered, which
are in fact not only temporary displays of a buffer but also displays of a
temporary buffer.

I'm just saying that I think the problem of MS Windows giving the focus to a new
frame that gets popped during a minibuffer interaction, where that new frame
should not have the focus, i.e., where its buffer is shown only for information,
is more general than the show-a-temporary-buffer case you have treated.

At least that's what I think so far.  You'll tell me if I'm wrong.

>  > It is only the code that invokes reading from the minibuffer
>  > and pops up the other window/frame that can know whether the
>  > focus should be in that window/frame or in the minibuffer.
> 
> It's not that simple. The invoking code doesn't care about focus

It does care.  Maybe what you mean is that it does not expect the focus to be
messed with by MS Windows.

Typically, such code simply does not expect (take into account) a scenario where
the user (a) has a standalone minibuffer frame, (b) has the buffer in question
be popped up in its own frame, and (c) is on MS Windows, which steals the input
focus and gives it to the new frame.

But the code does expect the minibuffer to have the focus, and it knows that the
buffer is shown only for informational purposes, i.e., the buffer does not need
(and should not have) the input focus.

The code does not, today, explicitly express that intention/care, because
outside of the problematic case of (a), (b), and (c), which today is not that
common, there is no need to express and handle that intention.  IOW it cares,
but its cares are already taken care of automatically in most cases.

> and in particular not about some frame whose eventually popping
> up will cause problems.  It expects the reading from the minibuffer
> mechanism DTRT.

Precisely.  And except for the problematic case, there has never been any need
for the programmer to make clear the fact (intention) that the buffer is
informational only.

You have encapsulated precisely that intention in your code.  But you have gone
beyond that and expressed the additional intention that the buffer be temporary.

That's fine, but it is less general: there are (at least logically) problematic
cases that it does not solve, namely, popping up an existing, non-temporary
buffer temporarily during a minibuffer query of the user.

>  > But here's the thing: in the case of windows instead of 
>  > frames, Emacs DTRT, no?  Emacs distinguishes the case of
>  > window *Process List* from window *Backtrace*,
>  > giving the focus to the latter and not to the former.  Why 
>  > can't we make Emacs DTRT for frames, just as it does for windows?

And your code in fact does make the distinction between *Process List* and
*Backtrace*, which proves my point here.  But your code makes the distinction
based on *Process List* being a temporary buffer (which it is), and not on it
being a buffer that is displayed temporarily in its own frame.

The latter distinction is I think the right one, and which would be good to
handle.  That is where MS Windows's automatic focusing leads to a problem.

The problematic case is (a) standalone minibuffer (b) popped-up buffer in its
own frame, (c) that frame being new, and (d) the OS giving the new frame the
input focus.

> For windows on the same frame we can differ between 
> `display-buffer' and `pop-to-buffer'.  For windows on different
> frames we have the complication that the `handle-switch-frame'
> event triggered by the OS causes Emacs to select that frame,
> that is, implicitly replace `display-buffer' by `pop-to-buffer'.

Yes, that is one way to put it.

>  > I know that MS Windows altering the focus throws a monkey 
>  > wrench into the mix, but surely we can find some way to KEEP
>  > the focus (i.e. re-focus if necessary) where Emacs put it
>  > (correctly).
> 
> As far as old code is concerned you probably are overly optimistic.

OK, let's say that that is a nice-to-have, and move on.

The first step is your code, which handles a subset of the problematic cases for
new Emacs releases.  Very good.

The second step, I think, would be something similar, but not limited to
temporary buffers.  Some way for a programmer to express the intention of
displaying a buffer (temporary or not) only for informational purposes during a
minibuffer interaction.

And I think that for that more general case, there is a problem to be handled
only when (a) there is a standalone minibuffer frame, (b) the buffer is popped
up in its own frame.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes'

[Drew Adams]

Martin,

I tried loading your code in Emacs 24.1 from my .emacs.

Please remind me - was it supposed to work with Emacs 24.1 or just with later
builds?

Anyway, with 24.1 I immediately ran into this problem: `q' in *Help* did not
remove the frame.  It just substituted the previously current buffer in that
frame.

IOW, the *Help* frame is apparently no longer special-display as it should be.

HTH.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes'

[martin rudalics]

 > I tried loading your code in Emacs 24.1 from my .emacs.
 >
 > Please remind me - was it supposed to work with Emacs 24.1 or just with later
 > builds?

At least with Emacs 24.1 but it should work with earlier versions too.

 > Anyway, with 24.1 I immediately ran into this problem: `q' in *Help* did not
 > remove the frame.  It just substituted the previously current buffer in that
 > frame.

Do you mean the frame did show another buffer before?  Anyway, that's a
different issue.  The code is supposed only for testing with the three
functions `recover-file', `save-buffers-kill-emacs' and
`dired-mark-pop-up'.  It's possible that some of my changes also affect
quitting *Help* windows and the like.  Tell me the value of the *Help*
window's `quit-restore' parameter.

 > IOW, the *Help* frame is apparently no longer special-display as it should be.

It still is and should call `frame-auto-hide-function'.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes'

[Drew Adams]

>  > Anyway, with 24.1 I immediately ran into this problem: `q' 
>  > in *Help* did not remove the frame.  It just substituted the
>  > previously current buffer in that frame.
> 
> Do you mean the frame did show another buffer before?  

No, never.  What it substituted in the *Help* frame was a buffer that was
previously selected elsewhere (it was never displayed in the *Help* frame).

> Anyway, that's a different issue.

Yes, I imagine so.  But I thought you might like to know about it.  Without
loading your code I do not have that problem: buffer *Help* is never replaced in
its frame by any other buffer.  It is a special-display buffer.

> The code is supposed only for testing with the three
> functions `recover-file', `save-buffers-kill-emacs' and
> `dired-mark-pop-up'.  It's possible that some of my changes 
> also affect quitting *Help* windows and the like.

> Tell me the value of the *Help*
> window's `quit-restore' parameter.

Before loading your code there is no such parameter present.
Likewise after loading it: no such parameter.

This is the code that defines the *Help* frame parameters:

(add-to-list
  'special-display-buffer-names
  (list "*Help*" '1on1-display-*Help*-frame
        (list (cons 'background-color 1on1-help-frame-background)
              (cons 'mouse-color 1on1-help-frame-mouse+cursor-color)
              (cons 'cursor-color 1on1-help-frame-mouse+cursor-color)
              '(height . 40))))

>  > IOW, the *Help* frame is apparently no longer 
>  > special-display as it should be.
> 
> It still is and should call `frame-auto-hide-function'.

No idea what that means.  It clearly does not behave like a special-display
frame: its frame is not dedicated.

FWIW, (special-display-p "*Help*") returns this:

(1on1-display-*Help*-frame
 ((background-color . "Thistle")
  (mouse-color . "Blue Violet")
  (cursor-color . "Blue Violet")
  (height . 40)))

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes'

[Drew Adams]

> > Anyway, that's a different issue.
> 
> Yes, I imagine so.  But I thought you might like to know 
> about it.  Without loading your code I do not have that
> problem: buffer *Help* is never replaced in its frame by
> any other buffer.  It is a special-display buffer.

In case it helps you in investigating that (other) bug:

This problem is not specific to *Help*.  After I load your code all
special-display is broken.  It does not matter how the purported special-display
frame is created (e.g. by matching `special-display-regexps' or using a
special-display function as in the case of *Help*).

Buffers that without your code are special-display, hence are in dedicated
frames, no longer have dedicated frames after loading your code.

HTH.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes'

[martin rudalics]

 > In case it helps you in investigating that (other) bug:
 >
 > This problem is not specific to *Help*.  After I load your code all
 > special-display is broken.  It does not matter how the purported special-display
 > frame is created (e.g. by matching `special-display-regexps' or using a
 > special-display function as in the case of *Help*).
 >
 > Buffers that without your code are special-display, hence are in dedicated
 > frames, no longer have dedicated frames after loading your code.
 >
 > HTH.

No.  If, with emacs -Q, I do

(progn
   (load ".../with-temp-buffer-window.el")
   (setq special-display-buffer-names '("*Process List*"))
   (display-buffer (get-buffer-create "*Process List*")))

I get the buffer *Process List* on a separate frame, in a strongly
dedicated window and with a `quit-restore' window parameter as

((quit-restore frame frame #<window 3 on *scratch*> #<buffer *Process List*>))

If I do `quit-window' in that window, the frame is iconified.  Tested
with Emacs 24.1 release and the latest trunk version I was able to
build.  If you get different results, there's nothing I can do.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes'

[Drew Adams]

> If, with emacs -Q, I do
> (progn
>    (load ".../with-temp-buffer-window.el")
>    (setq special-display-buffer-names '("*Process List*"))
>    (display-buffer (get-buffer-create "*Process List*")))
> 
> I get the buffer *Process List* on a separate frame, in a strongly
> dedicated window

I do too (following that recipe from emacs -Q), the dedicatedness being judged
by trying to do C-x b in it and getting this error message:

 switch-to-buffer: Cannot switch buffers in a dedicated window

> and with a `quit-restore' window parameter as
> 
> ((quit-restore frame frame #<window 3 on *scratch*> #<buffer 
> *Process List*>))

No, there is still no `quit-restore' parameter, according to `frame-parameters'.

> If I do `quit-window' in that window, the frame is iconified.

Same here.  This is with Emacs 24.1.

> Tested with Emacs 24.1 release and the latest trunk version I
> was able to build.  If you get different results, there's nothing I can do.

HTH.  This test does not involve a standalone minibuffer or other things that
are in my setup.  But at least you can see that parameter `quit-restore' is
missing.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes'

[martin rudalics]

 >> If, with emacs -Q, I do
 >> (progn
 >>    (load ".../with-temp-buffer-window.el")
 >>    (setq special-display-buffer-names '("*Process List*"))
 >>    (display-buffer (get-buffer-create "*Process List*")))
 >>
 >> I get the buffer *Process List* on a separate frame, in a strongly
 >> dedicated window
 >
 > I do too (following that recipe from emacs -Q), the dedicatedness being judged
 > by trying to do C-x b in it and getting this error message:
 >
 >  switch-to-buffer: Cannot switch buffers in a dedicated window

QED

 >> and with a `quit-restore' window parameter as
 >>
 >> ((quit-restore frame frame #<window 3 on *scratch*> #<buffer
 >> *Process List*>))
 >
 > No, there is still no `quit-restore' parameter, according to `frame-parameters'.
 >
 >> If I do `quit-window' in that window, the frame is iconified.
 >
 > Same here.  This is with Emacs 24.1.
 >
 >> Tested with Emacs 24.1 release and the latest trunk version I
 >> was able to build.  If you get different results, there's nothing I can do.
 >
 > HTH.  This test does not involve a standalone minibuffer or other things that
 > are in my setup.  But at least you can see that parameter `quit-restore' is
 > missing.

You cannot see that it is not missing.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes'

[martin rudalics]

 > (window-parameters) returns nil.  In every window I've tried so far.  Let me
 > know if there is some particular test you want me to make.

In your previous reply you wrote:

 >> If, with emacs -Q, I do
 >> (progn
 >>    (load ".../with-temp-buffer-window.el")
 >>    (setq special-display-buffer-names '("*Process List*"))
 >>    (display-buffer (get-buffer-create "*Process List*")))
 >>
 >> I get the buffer *Process List* on a separate frame, in a strongly
 >> dedicated window
 >
 > I do too (following that recipe from emacs -Q), the dedicatedness being judged
 > by trying to do C-x b in it and getting this error message:
 >
 >  switch-to-buffer: Cannot switch buffers in a dedicated window
 >
 >> and with a `quit-restore' window parameter as
 >>
 >> ((quit-restore frame frame #<window 3 on *scratch*> #<buffer
 >> *Process List*>))
 >
 > No, there is still no `quit-restore' parameter, according to `frame-parameters'.
 >
 >> If I do `quit-window' in that window, the frame is iconified.
 >
 > Same here.  This is with Emacs 24.1.
 >
 >> Tested with Emacs 24.1 release and the latest trunk version I
 >> was able to build.  If you get different results, there's nothing I can do.
 >
 > HTH.  This test does not involve a standalone minibuffer or other things that
 > are in my setup.  But at least you can see that parameter `quit-restore' is
 > missing.

So according to that reply, special display works on your system, the
window gets dedicated and the frame iconified.  You insisted on the
absence of a value for the `quit-restore' window parameter but maybe you
can have another look once you manage how to find it.  Sections 28.16
and 28.24 of the Elisp manual might help you in this regard.

So the only remaining issue is the familiar one: Go through your setup
and check why the window does not get dedicated and the `quit-restore'
window parameter is not assigned.

 > Clear enough now?

Judge by yourself.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes'

[Drew Adams]

With the emacs -Q scenario, (window-parameters) shows:

((quit-restore frame frame #<window 3 on *Messages*>
               #<buffer *Process List*>))

> So the only remaining issue is the familiar one: Go through your setup
> and check why the window does not get dedicated and the `quit-restore'
> window parameter is not assigned.

That will unfortunately take a while.  And again, it is not just _this_ window
that is not dedicated.  _No_ windows are dedicated after I load your code.

I will try to narrow things down when I get some time.  Perhaps you can look
from your side, since your code that breaks special display is very small, and
especially since you have a good understanding of how it changes things.

In addition to, or as an alternative to, trying to narrow my setup (lots of
code), I will try narrowing your code, evaluating only pieces of it to see if I
can determine what the culprit part is.

Any advice wrt narrowing your code?  I am unfamiliar with it and how its parts
might relate to each other, so any such exercise on my part is pretty much
blind, unless you have some guidance to offer.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibufferfocuswhenitcalls`list-processes'

[Drew Adams]

FWIW, even without loading your code, with my setup, (window-parameters) always
returns nil.  I will need to dig further to find out why.

Perhaps you can help by telling me what vanilla Emacs code normally changes
things so that the value returned is non-nil.  IOW, what parts of the Emacs code
should be setting this up correctly?  That might help me narrow things down to
find what code I have that is counteracting that correct setup.

I note that in Emacs 23 also (windows-parameters) returns nil for me.  (And the
function apparently does not exist in Emacs 22.)

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

OK, here is a recipe from emacs -Q.

runemacs.exe  -Q -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"

You will need to download those two libraries from the wiki:
http://www.emacswiki.org/emacs/download/hexrgb.el
http://www.emacswiki.org/emacs-en/download/oneonone.el

After that, evaluating (window-parameters) in any window (AFAICT) returns nil.

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 > OK, here is a recipe from emacs -Q.
 >
 > runemacs.exe  -Q -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"
 >
 > You will need to download those two libraries from the wiki:
 > http://www.emacswiki.org/emacs/download/hexrgb.el
 > http://www.emacswiki.org/emacs-en/download/oneonone.el

Not this time.  Please try to come up with a self-contained, reasonably
small test case.

 > After that, evaluating (window-parameters) in any window (AFAICT) returns nil.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

> Please try to come up with a self-contained, 
> reasonably small test case.
> 
>  > After that, evaluating (window-parameters) in any window 
>  > (AFAICT) returns nil.

Digging further I found the problem in my code, which was preventing
(window-parameters) from returning non-nil, and also apparently preventing
special-display buffers from having dedicated windows.  The problem was not due
to your code.

FYI -

I have code that redefines `special-display-popup-frame' (only for Emacs 24+)
just so that the frame is fit to the buffer contents.  The latest version I had
was based on a vanilla Emacs snapshot that was old - it did not have a call to
`display-buffer-record-window'.

With that code updated now per the latest Emacs 24 sources, `window-parameters'
does not always return nil, and special-display buffers seem to have dedicated
windows as they should.

So I think this brings some closure.  I do hope you will merge your code into
Emacs.  If there is something additional you would like me to test, let me know.
This will be a big improvement, for me at least.  Thank you for your efforts.

---

BTW: Do you not think that there should be a call to `raise-frame' in `s-d-p-f'
before returning the WINDOW in the case where ARGS is a list (FUNCTION .
FN-ARGS)?

Should it not _always_ be the case that `special-display-popup-frame' pops up
the buffer in a frame, i.e., ensures that its display is clearly visible?

Even if the buffer is already displayed somewhere, shouldn't a frame that it is
displayed in be raised?  In particular, the frame that is the `window-frame' of
the window returned by FUNCTION applied to its args?

---

NOTE: If the frame fitting did not need to be done in two different cases (ARGS
with FUNCTION and otherwise), hence in two different places in the
`special-display-popup-frame' code, then I might just use `defadvice'.  Or if
`s-d-p-f' provided a hook in those two places then I would just do the frame
fitting on that hook.  I do not especially _like_ redefinining vanilla
functions...

I do not need to redefine `s-d-p-f' in prior Emacs versions.  That is presumably
because I already have frame-fitting on existing hooks.  Something in the
vanilla changes for Emacs 24 made it so that frame fitting was no longer
occurring in all cases, which led me to redefine `s-d-p-f'.  I'm not sure which
hooks were sufficient before.  I use, e.g., `after-make-frame-functions' and
`temp-buffer-show-hook'.

I also redefine `switch-to-buffer' so that if the selected window is dedicated
(`window-dedicated-p') then it uses another window, regardless of argument
FORCE-SAME-WINDOW.  (If it is not dedicated then the vanilla `s-to-b' code is
invoked.)

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 > BTW: Do you not think that there should be a call to `raise-frame' in `s-d-p-f'
 > before returning the WINDOW in the case where ARGS is a list (FUNCTION .
 > FN-ARGS)?
 >
 > Should it not _always_ be the case that `special-display-popup-frame' pops up
 > the buffer in a frame, i.e., ensures that its display is clearly visible?

Its doc-string says: "If ARGS is a list whose car is a symbol, use (car
ARGS) as a function to do the work."  I suppose that "do the work" means
that function is entirely responsible for doing what you want.  In any
other case, `special-display-popup-frame' should do what you want.

 > Even if the buffer is already displayed somewhere, shouldn't a frame that it is
 > displayed in be raised?

`special-display-popup-frame' does that when it finds a window
displaying the buffer.

 > In particular, the frame that is the `window-frame' of
 > the window returned by FUNCTION applied to its args?

I suppose FUNCTION should be held responsible for raising the frame if
needed.

 > NOTE: If the frame fitting did not need to be done in two different cases (ARGS
 > with FUNCTION and otherwise), hence in two different places in the
 > `special-display-popup-frame' code, then I might just use `defadvice'.  Or if
 > `s-d-p-f' provided a hook in those two places then I would just do the frame
 > fitting on that hook.  I do not especially _like_ redefinining vanilla
 > functions...
 >
 > I do not need to redefine `s-d-p-f' in prior Emacs versions.  That is presumably
 > because I already have frame-fitting on existing hooks.  Something in the
 > vanilla changes for Emacs 24 made it so that frame fitting was no longer
 > occurring in all cases, which led me to redefine `s-d-p-f'.  I'm not sure which
 > hooks were sufficient before.  I use, e.g., `after-make-frame-functions' and
 > `temp-buffer-show-hook'.
 >
 > I also redefine `switch-to-buffer' so that if the selected window is dedicated
 > (`window-dedicated-p') then it uses another window, regardless of argument
 > FORCE-SAME-WINDOW.  (If it is not dedicated then the vanilla `s-to-b' code is
 > invoked.)

I don't understand why you insist on using, advising, or redefining
`special-display-popup-frame'.  Customizing `display-buffer-base-action'
should be all you want.

BTW: With with-temp-buffer-window.el it's possible to customize
`temp-buffer-resize-frames' and automatically resize temporary frames.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

>  > Should it not _always_ be the case that 
>  > `special-display-popup-frame' pops up the buffer in a frame,
>  > i.e., ensures that its display is clearly visible?
> 
> Its doc-string says...

Yes, I know what the doc string says.  I raised a question about the design: the
desired behavior.  The doc string would then follow from whatever was decided
about the behavior.

> I suppose FUNCTION should be held responsible for raising the frame if
> needed.

That's just the question I raised - should it?  That is the current design
(hence the doc string).  But is it the best approach?  Dunno.

In that case, `s-d-p-f' gets completely replaced and adds nothing to the party.
It does not necessarily pop up a frame showing the buffer.  The FUNCTION passed
as (car ARGS) is presumed to "do the work".  But "the work" has no meaning, not
even a suggested meaning - FUNCTION might well not raise the frame or even
display the buffer.

That's OK (it's one approach).  But is it reasonable to suppose that there are
many (any?) use cases where you would not want the frame raised?

To be clear: I do not have a problem with the current approach (and I've now
changed my version, likewise, to not raise (or fit) the frame in that case).

But if we keep that design then it might be clearer to state what "the work" is
generally expected to be, i.e., that it typically means displaying the buffer
and raising its frame.  E.g.:

  If ARGS is a list whose car is a symbol then use (car ARGS) as a
  function to do the work: display the buffer and raise its frame.
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Pass it BUFFER as first argument, and (cdr ARGS) as the rest of
  the arguments.

(See also bug #8853 wrt the last phrase - this regression is still not fixed.)

> I don't understand why you insist on using, advising, or redefining
> `special-display-popup-frame'.  Customizing
> `display-buffer-base-action' should be all you want.

What part of must-work-with-releases-other-than-just-24 did you not get?

You add a new knob, such as `display-buffer-base-action', and you think that
that takes care of everything.  Maybe it does for Emacs 24, but the knob does
not even exist prior to 24.  You are concerned only with the latest Emacs
release.  I, like many (most?) users, am not.

> BTW: With with-temp-buffer-window.el it's possible to customize
> `temp-buffer-resize-frames' and automatically resize temporary frames.

OK, good to know.  My need is not just for temporary frames (whatever that term
might mean), and it is generally not only for Emacs 24+.  But that is definitely
good to know.

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 >> I don't understand why you insist on using, advising, or redefining
 >> `special-display-popup-frame'.  Customizing
 >> `display-buffer-base-action' should be all you want.
 >
 > What part of must-work-with-releases-other-than-just-24 did you not get?
 >
 > You add a new knob, such as `display-buffer-base-action', and you think that
 > that takes care of everything.  Maybe it does for Emacs 24, but the knob does
 > not even exist prior to 24.  You are concerned only with the latest Emacs
 > release.  I, like many (most?) users, am not.

Changing `special-display-popup-frame' for >= 24.2 would not affect its
behavior with < 24.2.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

>  >> > I do not especially _like_ redefinining vanilla functions...
>  >>
>  >> I don't understand why you insist on using, advising, or 
>  >> redefining `special-display-popup-frame'.  Customizing
>  >> `display-buffer-base-action' should be all you want.
>  >
>  > What part of must-work-with-releases-other-than-just-24 
>  > did you not get?
> 
> Changing `special-display-popup-frame' for >= 24.2 would not 
> affect its behavior with < 24.2.

Fair enough.  I could provide a separate solution for >= 24.2.
Agreed.  And I'd be glad to learn how.

Perhaps I will provide a separate 24.2+ solution, once we have 24.2.  By that
time, based on past experience, it's quite possible that Emacs Dev will have
changed things in this area once again - perhaps even radically (again).  But
I'm certainly open to finding a solution that does not require redefining
`special-display-popup-frame'.

However:

1. `display-buffer-base-action' is a user option.  Users can set it to anything,
including things that do not do what my redefinition of `s-d-p-f' does, which is
to invoke `fit-frame'.  Advising me to customize `display-buffer-base-action'
does not speak to providing such functionality in a library for other users.

2. I do not yet understand `display-buffer-base-action' enough to know _how_ it
might be changed to DTRT here. [*]

3. Wrt #2, in particular, redefining `s-d-p-f' affects only those places in
Emacs that call `s-d-p-f', in particular, special-display stuff.  IIUC,
`display-buffer-base-action' is general and affects _all_ calls (and only calls)
to `display-buffer'.  How to make it affect only what `s-d-p-f' affects?

4. Wrt #2 & #3: Please let me know precisely how you think I could, now (e.g.,
for recent Emacs 24 builds plus your code, which I hope you will merge soon),
use `display-buffer-base-action' to get the effect of my redefinition of
`s-d-p-f'.

I'm open to your suggestion, but so far it is not concrete enough for me to see
how `display-buffer-base-action' might replace redefining `s-d-p-f', even for
Emacs >= 24.2.  What is no doubt obvious to you is not at all clear to me.


---

[*] FWIW, the `display-buffer-base-action' doc string is not very helpful:

 "It should be a cons cell (FUNCTION . ALIST), where FUNCTION is a
  function or a list of functions.  Each function should accept two
  arguments: a buffer to display and an alist similar to ALIST."

What does "similar" to ALIST mean here?  Plus, all the doc tells us is the
_form_ of the option value, not what the value means or how it is used.  Yes, it
sends us off to the doc for `display-buffer', but that is a labyrinthine jungle.

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 >> Changing `special-display-popup-frame' for >= 24.2 would not
 >> affect its behavior with < 24.2.
 >
 > Fair enough.  I could provide a separate solution for >= 24.2.

For > 24.2 (since yesterday).

 > Agreed.  And I'd be glad to learn how.
 >
 > Perhaps I will provide a separate 24.2+ solution, once we have 24.2.  By that
 > time, based on past experience, it's quite possible that Emacs Dev will have
 > changed things in this area once again - perhaps even radically (again).  But
 > I'm certainly open to finding a solution that does not require redefining
 > `special-display-popup-frame'.
 >
 > However:
 >
 > 1. `display-buffer-base-action' is a user option.  Users can set it to anything,
 > including things that do not do what my redefinition of `s-d-p-f' does, which is
 > to invoke `fit-frame'.  Advising me to customize `display-buffer-base-action'
 > does not speak to providing such functionality in a library for other users.

I said that "customizing `display-buffer-base-action' should be all you
want" because I didn't know that you want to provide that "functionality
in a library for other users'.  In such case you probably want to write
some function derived from your advised, redefined
`special-display-popup-frame', include it in that library and tell
people to call that function by customizing their `display-buffer-alist'
appropriately.

 > 2. I do not yet understand `display-buffer-base-action' enough to know _how_ it
 > might be changed to DTRT here. [*]
 >
 > 3. Wrt #2, in particular, redefining `s-d-p-f' affects only those places in
 > Emacs that call `s-d-p-f', in particular, special-display stuff.  IIUC,
 > `display-buffer-base-action' is general and affects _all_ calls (and only calls)
 > to `display-buffer'.  How to make it affect only what `s-d-p-f' affects?
 >
 > 4. Wrt #2 & #3: Please let me know precisely how you think I could, now (e.g.,
 > for recent Emacs 24 builds plus your code, which I hope you will merge soon),
 > use `display-buffer-base-action' to get the effect of my redefinition of
 > `s-d-p-f'.
 >
 > I'm open to your suggestion, but so far it is not concrete enough for me to see
 > how `display-buffer-base-action' might replace redefining `s-d-p-f', even for
 > Emacs >= 24.2.  What is no doubt obvious to you is not at all clear to me.

It's not obvious to me and I have only a rudimentary solution where I
set `display-buffer-base-action' to a function that always splits the
selected window.  And I do the remaining tweaks by customizing
`display-buffer-alist' in some rudimentary manner too.  As long as we
don't have any feedback from users who start experimenting with this,
there won't be much progress indeed.  In particular if they insist on
tweaking the behavior of `special-display-popup-frame' instead ...

 > [*] FWIW, the `display-buffer-base-action' doc string is not very helpful:
 >
 >  "It should be a cons cell (FUNCTION . ALIST), where FUNCTION is a
 >   function or a list of functions.  Each function should accept two
 >   arguments: a buffer to display and an alist similar to ALIST."
 >
 > What does "similar" to ALIST mean here?  Plus, all the doc tells us is the
 > _form_ of the option value, not what the value means or how it is used.  Yes, it
 > sends us off to the doc for `display-buffer', but that is a labyrinthine jungle.

It looks slightly circular indeed.  But I believe that you should be
able to easily digest the two alist values that currently do have a
special meaning (`inhibit-same-window' and `reusable-frames').  The main
advantage of ALIST is that in your library you can call `display-buffer'
with some special-purpose alist elements and have the function specified
via `display-buffer-alist' recognize these values.

This means that you can get any special behavior when and where you (or
your users) want it, while providing standard behavior for those who do
not.  With Emacs 23, you could specify special behavior only via
`special-display-frame-alist' and the special case entries of
`special-display-buffer-names' and `special-display-regexps' in some
very restricted manner - use the same window, a window on the same
frame, or a new frame with some predefined properties.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

> The main advantage of ALIST is that in your library you can call 
> `display-buffer' with some special-purpose alist elements and
> have the function specified via `display-buffer-alist' recognize
> these values.

This, I suspect, is a fundamental misunderstanding behind this change (and some
other changes in Emacs over the last few years).  Let me politely suggest that
such changes are misguided if the designers think that this is always the way to
go and the answer to everything.

In particular, wanting to deprecate and replace, rather than supplement,
previous constructs, is a mistake, IMHO.  Farther down the road I might see the
light and change my mind, but that is my honest point of view at present.

As you know, I am no expert on this stuff - I barely understand the new
approach, certainly so wrt details.  I have some experience with parts of the
"old" approach, and I've seen some of the pain you've gone through to try to
enable the new to handle some of the straightforward cases of the old.  It has
not always been so simple, has it?

You've succeeded, AFAICT, but it has not been obvious.  Granted, part of the
difficulty is that you were not familiar with some of the "old" (use cases, for
example).  Still, it is not clear to me that the new is a reasonable,
straightforward replacement for the "old".

Here's the misunderstanding, as I see it:

"You can call `display-buffer' with some special-purpose alist elements..."
misses the point.  It is not just that "you can" but that "you MUST" (if you
intend this as a replacement rather than an addition).

What you've provided is fine for specific places where `display-buffer' is
called and you want to give those calls a particular behavior.  It is not ideal
AFAICT for a package/user that wants to provide/obtain a particular class of
behavior across all calls of `display-buffer'.

That is what the various "old" user options provide: easy to turn on/off classes
of behavior that affect all `display-buffer' calls.  As opposed to "customizing"
individual `display-buffer' calls (which requires access to modify those calls).
That is the power (as well as the limitation) of dynamically scoped global
variables: they can affect behavior deep down, with just a flip of the switch.
 
> This means that you can get any special behavior when and 
> where you (or your users) want it, while providing standard
> behavior for those who do not.

"You can get" -> "You MUST define".  You must have available the "when and
where" times and locations, and you must control/customize them.  You cannot so
simply/easily get a special behavior across all such "when and where" at once.

To be clear, I do not say that one _cannot_ do with the new what one can do with
the "old".  But it does not seem so easy to do - so far.  We cannot even seem to
get a straightforward "migration table" added to the doc, that clearly tells you
how to move from "old" to new.

It is not really up to me to prove that the new cannot (or cannot easily) do the
job, even if I believed that.  It is up to those providing the new to show that
it can - IF they intend to deprecate & replace the "old".  Hand waving and
repeating that "you can" do anything you like with the new is not very
persuasive.  Yes, this is Lisp: you can do nearly anything.  But that is not
much help, I'm afraid.  It just doesn't cut the mustard.

Consider that we users are not so bright, and we need someone to show us the way
step by step.  IOW, apply the same logic that we ask of users reporting bugs:
think of the reader as a six-year old who asks for a bit of hand-holding.
Believe me, that will not hurt, and even the explainer can end up learning
something now and then from the teaching.

> With Emacs 23, you could specify special behavior only via
> `special-display-frame-alist' and the special case entries of
> `special-display-buffer-names' and `special-display-regexps' in some
> very restricted manner - use the same window, a window on the same
> frame, or a new frame with some predefined properties.

Fair enough.  The new is more fine-grained and apparently more general.  I can
see and appreciate that.  But those particular "very restricted" special cases
are important use cases - at least for me.  For me, the "old" does the job quite
well - the "very restricted" job it was intended to do.

I am not arguing against the new.  Not at all.

Wanting to jump on board the new, I'm still waiting to see how best to get the
same effects as the "old" using the new.  I'm sure I will get there eventually.
And I'm guessing that there might be some additional unforeseen hiccups for
Emacs Dev that will require still more changes to the new to simulate some
aspects of the "old".  That's OK, and to be expected.

I will say that I am very grateful for your interest and efforts in _getting
this right_.  It would have been all too easy for someone enthused about his new
approach to just throw up his hands and say: it solves all the problems; you are
on your own to figure out how.  Instead, you have spent time trying to
understand and solve the problems raised.  Bravo, and thank you, for that.

Please understand that I am not opposed to the work you have done in making
`display-buffer' (and windows etc.) more coherent, logical, and controllable.
Quite the contrary.  I defended your work when some wanted to simplify parts and
throw some of it overboard.  It seemed to me that you were approaching things
carefully and with an open mind.  You were listening to problems raised and took
them seriously.

IMHO, it is not appropriate now to deprecate the "old", and it might never be.
If the "old" is now no more than a shorthand for a subset of what the new
provides, it can usefully be kept as just such: a shorthand, easy way to get
that subset.

If it turns out - based on _lots_ of user experience and some time - that the
"old" is not so convenient as the new, then the new will replace it organically,
naturally.  Then, and only then, should we deprecate the old: when it truly is
no longer serving any purpose, when it truly has become old.

Thank you for the new, and please do not be in any hurry to force it on users as
a replacement for the "old".  If it is better, sufficient, and easier to use,
users will naturally adopt it with enthusiasm.  Users are not stupid, even if
they are more ignorant than the designers wrt the new, esp. when it is first
made available.

bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 > As you know, I am no expert on this stuff - I barely understand the new
 > approach, certainly so wrt details.  I have some experience with parts of the
 > "old" approach, and I've seen some of the pain you've gone through to try to
 > enable the new to handle some of the straightforward cases of the old.  It has
 > not always been so simple, has it?

You are mistaken here.  The "new" approach was _entirely_ coded by Chong
based on ideas by Stefan.

 > You've succeeded, AFAICT, but it has not been obvious.  Granted, part of the
 > difficulty is that you were not familiar with some of the "old" (use cases, for
 > example).  Still, it is not clear to me that the new is a reasonable,
 > straightforward replacement for the "old".
 >
 > Here's the misunderstanding, as I see it:
 >
 > "You can call `display-buffer' with some special-purpose alist elements..."
 > misses the point.  It is not just that "you can" but that "you MUST" (if you
 > intend this as a replacement rather than an addition).

As you know very well the old approach is still supported.  And I intend
"this" as an enhancement rather than a replacement or an addition.

 > What you've provided is fine for specific places where `display-buffer' is
 > called and you

Who's "you" here?

 > want to give those calls a particular behavior.  It is not ideal
 > AFAICT for a package/user that wants to provide/obtain a particular class of
 > behavior across all calls of `display-buffer'.

The new approach is superior because it allows packages to specify the
behavior they consider most suited and it allows the user to override
that.  This distinction was not clear in the old approach where a user's
customizations could be deliberately turned off by packages that
temporarily bound these options to nil.

 > That is what the various "old" user options provide: easy to turn on/off classes
 > of behavior that affect all `display-buffer' calls.

These confer to `display-buffer-base-action' in the new approach.  A
package binding this variable is a package I would remove immediately.

 > As opposed to "customizing"
 > individual `display-buffer' calls (which requires access to modify those calls).

I miss you here.

 > That is the power (as well as the limitation) of dynamically scoped global
 > variables: they can affect behavior deep down, with just a flip of the switch.

`display-buffer-base-action' provides that switch.

 > "You can get" -> "You MUST define".  You must have available the "when and
 > where" times and locations, and you must control/customize them.  You cannot so
 > simply/easily get a special behavior across all such "when and where" at once.

In which regard does what you write here differ from earlier versions of
Emacs?

 > To be clear, I do not say that one _cannot_ do with the new what one can do with
 > the "old".  But it does not seem so easy to do - so far.  We cannot even seem to
 > get a straightforward "migration table" added to the doc, that clearly tells you
 > how to move from "old" to new.

This is partially true.  For example, I'd never explain how a package
can override a user's customizations.

 > It is not really up to me to prove that the new cannot (or cannot easily) do the
 > job, even if I believed that.  It is up to those providing the new to show that
 > it can - IF they intend to deprecate & replace the "old".  Hand waving and
 > repeating that "you can" do anything you like with the new is not very
 > persuasive.  Yes, this is Lisp: you can do nearly anything.  But that is not
 > much help, I'm afraid.  It just doesn't cut the mustard.
 >
 > Consider that we users are not so bright, and we need someone to show us the way
 > step by step.  IOW, apply the same logic that we ask of users reporting bugs:
 > think of the reader as a six-year old who asks for a bit of hand-holding.
 > Believe me, that will not hurt, and even the explainer can end up learning
 > something now and then from the teaching.

Users who ask will get the appropriate answer.  Unfortunately,
deprecating options seems the only way to get them do that.  And in this
regard, I consider myself a user just like you.

 > Fair enough.  The new is more fine-grained and apparently more general.  I can
 > see and appreciate that.  But those particular "very restricted" special cases
 > are important use cases - at least for me.  For me, the "old" does the job quite
 > well - the "very restricted" job it was intended to do.

For some users it was bad karma that applications were allowed to
overrule them in these important use cases.

martin

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

Coming back to an earlier part of this thread.  I have some news.

I found today that the code you sent does not help in at least one situation.  I
presume that's because it deals only with temporary buffers, but I'm not sure.
The buffer popped up in a separate frame is *Completions*.  By "does not help" I
mean that it makes no difference in this case whether I load your code or not.

Anyway, the scenario involves using my one-on-one stuff with a vanilla Emacs
call to `completing-read' or `completing-read-multiple'.

[I discovered this because the latter (`c-r-m') does not use anything particular
in Icicles, so `customize-face' (via `read-face-name') just calls vanilla
`completing-read-multiple' even in Icicle mode.]

M-x customize-face b TAB

then, trying to type more chars raises an error saying that *Completions* is
read-only (IOW, the *Completions* frame was somehow given the input focus).

I looked into the problem a little more closely.

None of the hacks I had tried previously with `1on1-fit-minibuffer-frame' took
care of this problem: neither guarding the minibuffer frame-fitting, using

(eq last-event-frame (window-frame (minibuffer-window)))

nor adding explicit redirection to the minibuffer frame at the end of
`1on1-fit-minibuffer-frame'.

It turns out that the problem was 3-fold.  That is, there were three places in
the code of `1on1-fit-minibuffer-frame' that caused the problem: each was
_alone_ capable of causing the problem, so all three needed to be fixed.  Here
they are.

1. This was one of the guards of the body of `1on1-fit-minibuffer-frame':

(save-selected-window
  (select-window (minibuffer-window))
  (one-window-p nil 'selected-frame))

The call to `save-selected-window' somehow gave the focus to the *Completions*
frame.  The solution was to change `save-selected-window' to
`save-window-excursion' here.  I don't know why, but I'm hoping you will.

2. This was called near the beginning of the `1on1-fit-minibuffer-frame' body:

(let* ((frame (save-selected-window
                (select-window (minibuffer-window))
                (selected-frame)))

The fix here too was to use `save-window-excursion' instead of
`save-selected-window'.

3. At the end of the `1on1-fit-minibuffer-frame' body there is this call:

(1on1-set-minibuffer-frame-top/bottom)

The code for that function is this:

(defun 1on1-set-minibuffer-frame-top/bottom ()
  (when 1on1-minibuffer-frame
    (condition-case nil
        (if (fboundp 'redisplay)
	    (redisplay t)
	  (force-mode-line-update t))
      (error nil)) ; Ignore errors from, e.g., killed buffers.
    (modify-frame-parameters
     1on1-minibuffer-frame
     `((top ,@ (or 1on1-minibuffer-frame-top/bottom
                   (- (* 2 (frame-char-height
                             1on1-minibuffer-frame)))))))))

Here the problem was the call to `redisplay'.  I changed (foundp 'redisplay) to
just nil to fix things - `force-mode-line-update' works without changing the
focus.

`redisplay' is defined in C code.  I do not know why it causes a problem here
(why would redisplay change the input focus?), and I don't know what the proper
solution might be, except to just use `force-mode-line-update' as I was already
doing in older Emacs versions (which do not have `redisplay').

Do you have an idea about this?  Does any of this make sense to you?

Each of these fixes is needed for `1on1-fit-minibuffer-frame'.  Reverting any of
them brings back the problem (giving *Completions* the focus).  I do not
understand any of these fixes (why they work), and I am certainly not claiming
anything about them or about the problem, which I do not understand.  I am only
saying that together these changes fix the problem I encountered.

But if you can explain things I will be glad to learn.

Thx/HTH - Drew

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 > It turns out that the problem was 3-fold.  That is, there were three places in
 > the code of `1on1-fit-minibuffer-frame' that caused the problem: each was
 > _alone_ capable of causing the problem, so all three needed to be fixed.  Here
 > they are.
 >
 > 1. This was one of the guards of the body of `1on1-fit-minibuffer-frame':
 >
 > (save-selected-window
 >   (select-window (minibuffer-window))
 >   (one-window-p nil 'selected-frame))

Any reason why you don't use

(one-window-p nil (window-frame (minibuffer-window)))

here?

 > The call to `save-selected-window' somehow gave the focus to the *Completions*
 > frame.  The solution was to change `save-selected-window' to
 > `save-window-excursion' here.  I don't know why, but I'm hoping you will.

You mean that `save-select-window' can redirect focus and not direct it
back to where it was before calling it?  If this is the case, please
check whether it happens in Emacs 23 as well and file a bug report
(without referencing `1on1-fit-minibuffer-frame', if possible).

 > 2. This was called near the beginning of the `1on1-fit-minibuffer-frame' body:
 >
 > (let* ((frame (save-selected-window
 >                 (select-window (minibuffer-window))
 >                 (selected-frame)))

Do you mean

(window-frame (minibuffer-window))

here?

 > The fix here too was to use `save-window-excursion' instead of
 > `save-selected-window'.

Same as above.

 > 3. At the end of the `1on1-fit-minibuffer-frame' body there is this call:
 >
 > (1on1-set-minibuffer-frame-top/bottom)
 >
 > The code for that function is this:
 >
 > (defun 1on1-set-minibuffer-frame-top/bottom ()
 >   (when 1on1-minibuffer-frame
 >     (condition-case nil
 >         (if (fboundp 'redisplay)
 > 	    (redisplay t)
 > 	  (force-mode-line-update t))
 >       (error nil)) ; Ignore errors from, e.g., killed buffers.
 >     (modify-frame-parameters
 >      1on1-minibuffer-frame
 >      `((top ,@ (or 1on1-minibuffer-frame-top/bottom
 >                    (- (* 2 (frame-char-height
 >                              1on1-minibuffer-frame)))))))))
 >
 > Here the problem was the call to `redisplay'.  I changed (foundp 'redisplay) to
 > just nil to fix things - `force-mode-line-update' works without changing the
 > focus.
 >
 > `redisplay' is defined in C code.  I do not know why it causes a problem here
 > (why would redisplay change the input focus?), and I don't know what the proper
 > solution might be, except to just use `force-mode-line-update' as I was already
 > doing in older Emacs versions (which do not have `redisplay').
 >
 > Do you have an idea about this?  Does any of this make sense to you?

No.  Can't you distill a simple test case?  `redisplay' shouldn't care
about frame focus either.

 > Each of these fixes is needed for `1on1-fit-minibuffer-frame'.  Reverting any of
 > them brings back the problem (giving *Completions* the focus).  I do not
 > understand any of these fixes (why they work), and I am certainly not claiming
 > anything about them or about the problem, which I do not understand.  I am only
 > saying that together these changes fix the problem I encountered.
 >
 > But if you can explain things I will be glad to learn.

I can't explain any of these.  In the past, I tried to make most window
functions work on any window/frame to work independently from the
selected window.  Earlier, selecting a window must have been a very
simple procedure.  Nowadays, this incurs so many side-effects in the
window/frame/display area that you should try to avoid `select-window'
wherever possible.

martin

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

>  > (save-selected-window
>  >   (select-window (minibuffer-window))
>  >   (one-window-p nil 'selected-frame))
> 
> Any reason why you don't use
> (one-window-p nil (window-frame (minibuffer-window)))
> here?

The doc for `one-window-p', for Emacs < 24, says this:

 "If ALL-FRAMES is neither nil nor t, count only the selected frame."

To me, that says that the frame must be _selected_.  It says that it makes no
difference if the non-nil & non-t value is itself a frame: the SELECTED frame is
used even if you pass a different frame as arg.

The Emacs 24 doc string says something _very_ different - something that accords
with your suggestion.  It says that a value that is a _frame_ means:

 "consider all windows on that frame only."

Here, "that frame" is presumably the frame passed as argument.

However, I wonder if that is correct.  The _code_ itself is unchanged from Emacs
20 through Emacs 24.  Yet the doc string says something very different suddenly.

I see nothing in the `one-window-p' code that deals with a frame value, or a
`visible' value for that matter.  Perhaps these special cases are handled by one
of the functions it calls?

Can you explain?  Is the Emacs 24 behavior actually different from before, or is
it just the doc that is different?  Is the Emacs 24 doc string correct for 24?
Is the 24 doc string perhaps correct also for older releases?  (I see nothing in
NEWS about a behavior change.)

If your suggestion is appropriate, including for older releases, then I'll be
glad to adopt it.  Please let me know.

Note: I have this comment in the code just before the call to `one-window-p'.  I
do not recall the issue, but the comment has been there for quite a while:

;; We should be able to use just (one-window-p),
;; but an Emacs bug means we need this:
(one-window-p nil 'selected-frame)))

Does that ring a bell?  Even if that bug has since been fixed, I will presumably
need to keep that, for older releases.  Just wondering if you recall anything
about that bug.

>  > The call to `save-selected-window' somehow gave the focus 
>  > to the *Completions* frame.  The solution was to change
>  > `save-selected-window' to `save-window-excursion' here.
>  > I don't know why, but I'm hoping you will.
> 
> You mean that `save-select[ed]-window' can redirect focus and not 
> direct it back to where it was before calling it?

That's certainly what it seems like.  And there is definitely a difference here
wrt what `save-window-excursion' does (that function DTRT here).  Perhaps this
info gives you a starting point for investigating.

> If this is the case, please check whether it happens in Emacs 23
> as well and file a bug report (without referencing
> `1on1-fit-minibuffer-frame', if possible).

Yes, AFAICT the behavior is the same in all Emacs versions.

Do you have a suggestion for a simpler test?  If so, perhaps you can test it.

>  > 2. This was called near the beginning of the 
>  >    `1on1-fit-minibuffer-frame' body:
>  >
>  > (let* ((frame (save-selected-window
>  >                 (select-window (minibuffer-window))
>  >                 (selected-frame)))
> 
> Do you mean (window-frame (minibuffer-window)) here?

I suppose so.  _Should_ that make a difference?

Certainly that is lighter weight than `save-window-excursion', and it seems to
work OK so far.  Thanks for the suggestion.  Please let me know about the other
occurrence (above) - I would like to change that also, if your suggestion will
work there as well (for all Emacs versions).

>  > 3. At the end of the `1on1-fit-minibuffer-frame' body 
>  > there is this call:
>  > (1on1-set-minibuffer-frame-top/bottom)
>  >
>  > The code for that function is this:
>  >
>  > (defun 1on1-set-minibuffer-frame-top/bottom ()
>  >   (when 1on1-minibuffer-frame
>  >     (condition-case nil
>  >         (if (fboundp 'redisplay)
>  > 	    (redisplay t)
>  > 	  (force-mode-line-update t))
>  >       (error nil)) ; Ignore errors from, e.g., killed buffers.
>  >     (modify-frame-parameters
>  >      1on1-minibuffer-frame
>  >      `((top ,@ (or 1on1-minibuffer-frame-top/bottom
>  >                    (- (* 2 (frame-char-height
>  >                              1on1-minibuffer-frame)))))))))
>  >
>  > Here the problem was the call to `redisplay'.  I changed 
>  > (foundp 'redisplay) to just nil to fix things -
>  > `force-mode-line-update' works without changing the focus.
>  >
>  > `redisplay' is defined in C code.  I do not know why it 
>  > causes a problem here (why would redisplay change the input
>  > focus?), and I don't know what the proper solution might be,
>  > except to just use `force-mode-line-update' as I was already
>  > doing in older Emacs versions (which do not have `redisplay').
>  >
>  > Do you have an idea about this?  Does any of this make 
>  > sense to you?
> 
> No.  Can't you distill a simple test case?  `redisplay' shouldn't care
> about frame focus either.

You are saying the same thing I am.  Can you distill a simpler test case?

>  > Each of these fixes is needed for 
>  > `1on1-fit-minibuffer-frame'.  Reverting any of
>  > them brings back the problem (giving *Completions* the 
>  > focus).  I do not understand any of these fixes (why they work),
>  > and I am certainly not claiming anything about them or about
>  > the problem, which I do not understand.  I am only
>  > saying that together these changes fix the problem I encountered.
>  >
>  > But if you can explain things I will be glad to learn.
> 
> I can't explain any of these.  In the past, I tried to make 
> most window functions work on any window/frame to work independently
> from the selected window.  Earlier, selecting a window must have
> been a very simple procedure.  Nowadays, this incurs so many
> side-effects in the window/frame/display area that you should
> try to avoid `select-window' wherever possible.

You seem to be saying that Emacs has introduced bugs, and nothing more.  OK, so
I hear the admonition to avoid `select-window' wherever possible.  That's a
sorry state, though.  You seem to be saying that things that used to work, and
work simply, are now so bugged or complicated that all we can advise is to avoid
using `select-window'.

Anyway, my updated code seems to take care of the problem I encountered.

I would like to know about `one-window-p', however.  Is the Emacs 24 doc string
wrong?  The code is identical to the code for Emacs 20.7, but suddenly we have a
very different behavior description.  Is the new description correct for Emacs
24 plus older releases?  That would be good news (just an old-doc bug).  For the
moment, the situation is not clear.

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 >> Any reason why you don't use
 >> (one-window-p nil (window-frame (minibuffer-window)))
 >> here?
 >
 > The doc for `one-window-p', for Emacs < 24, says this:
 >
 >  "If ALL-FRAMES is neither nil nor t, count only the selected frame."
[...]

IIUC `one-window-p' calls `next-window' ever since with the ALL-FRAMES
argument unchanged and `next-window' has its traditional interpretation
of that argument.  So it seems that the old doc-string was inaccurate in
this regard.  But why you don't you check for yourself?  With Emacs 22

(progn
   (setq old-frame (selected-frame))
   (setq new-frame (make-frame))
   (select-frame new-frame)
   (split-window)
   (select-frame old-frame)
   (one-window-p nil new-frame))

gets me nil as expected.

 > Note: I have this comment in the code just before the call to `one-window-p'.  I
 > do not recall the issue, but the comment has been there for quite a while:
 >
 > ;; We should be able to use just (one-window-p),
 > ;; but an Emacs bug means we need this:
 > (one-window-p nil 'selected-frame)))
 >
 > Does that ring a bell?

No.

 > Even if that bug has since been fixed, I will presumably
 > need to keep that, for older releases.  Just wondering if you recall anything
 > about that bug.

All I can say is that for me `one-window-p' is much too hard to
understand.  I wouldn't use it.  Can't you compare the results of
`frame-first-window' and `minibuffer-window' instead?

 >> You mean that `save-select[ed]-window' can redirect focus and not
 >> direct it back to where it was before calling it?
 >
 > That's certainly what it seems like.  And there is definitely a difference here
 > wrt what `save-window-excursion' does (that function DTRT here).  Perhaps this
 > info gives you a starting point for investigating.

Hardly.  Neither of these should affect focus.

 >> If this is the case, please check whether it happens in Emacs 23
 >> as well and file a bug report (without referencing
 >> `1on1-fit-minibuffer-frame', if possible).
 >
 > Yes, AFAICT the behavior is the same in all Emacs versions.
 >
 > Do you have a suggestion for a simpler test?  If so, perhaps you can test it.

No idea.

 >>  > 2. This was called near the beginning of the
 >>  >    `1on1-fit-minibuffer-frame' body:
 >>  >
 >>  > (let* ((frame (save-selected-window
 >>  >                 (select-window (minibuffer-window))
 >>  >                 (selected-frame)))
 >>
 >> Do you mean (window-frame (minibuffer-window)) here?
 >
 > I suppose so.  _Should_ that make a difference?

Apparently it does make a difference in your case.

 >> No.  Can't you distill a simple test case?  `redisplay' shouldn't care
 >> about frame focus either.
 >
 > You are saying the same thing I am.  Can you distill a simpler test case?

No.  All I can say is that manually selecting the `minibuffer-window'
seems harmful.

 > You seem to be saying that Emacs has introduced bugs, and nothing more.

Where did I say that?  IIUC all Emacs version behave the same wrt your
scenario.

 >  OK, so
 > I hear the admonition to avoid `select-window' wherever possible.  That's a
 > sorry state, though.  You seem to be saying that things that used to work, and
 > work simply, are now so bugged or complicated that all we can advise is to avoid
 > using `select-window'.

Selecting a window or a frame for the sole purpose to retrieve or
compare a value related to that window is plain overkill given that
`select-window' also selects a frame, makes a buffer current ...

 > I would like to know about `one-window-p', however.  Is the Emacs 24 doc string
 > wrong?  The code is identical to the code for Emacs 20.7, but suddenly we have a
 > very different behavior description.  Is the new description correct for Emacs
 > 24 plus older releases?  That would be good news (just an old-doc bug).  For the
 > moment, the situation is not clear.

I think it was a bug in the old doc-string.

martin

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

> All I can say is that for me `one-window-p' is much too hard to
> understand.  I wouldn't use it.  Can't you compare the results of
> `frame-first-window' and `minibuffer-window' instead?

Is that sure to DTRT?  If so, fine.  I am not familiar with
`frame-first-window'.  It was certainly not obvious to me that if those two are
eq then the frame can only be showing a minibuffer window (no other windows).

`f-f-w' is written in C, and its definition has changed somewhat over Emacs
releases.   But if I pass a frame parameter then I guess the different
definitions should amount to the same thing.  I'll give that a try.

>  >> You mean that `save-select[ed]-window' can redirect focus
>  >> and not direct it back to where it was before calling it?
>  >
>  > That's certainly what it seems like.  And there is 
>  > definitely a difference here wrt what `save-window-excursion'
>  > does (that function DTRT here).  Perhaps this
>  > info gives you a starting point for investigating.
> 
> Hardly.  Neither of these should affect focus.

What can I say?  `save-selected-window' sure seems to.

>  >> If this is the case, please check whether it happens in
>  >> Emacs 23 as well and file a bug report (without referencing
>  >> `1on1-fit-minibuffer-frame', if possible).
>  >
>  > Yes, AFAICT the behavior is the same in all Emacs versions.
>  >
>  > Do you have a suggestion for a simpler test?  If so, 
>  > perhaps you can test it.
> 
> No idea.

Too bad.

>  >>  > (let* ((frame (save-selected-window
>  >>  >                 (select-window (minibuffer-window))
>  >>  >                 (selected-frame)))
>  >>
>  >> Do you mean (window-frame (minibuffer-window)) here?
>  >
>  > I suppose so.  _Should_ that make a difference?
> 
> Apparently it does make a difference in your case.
>
>  >> No.  Can't you distill a simple test case?  `redisplay' 
>  >> shouldn't care about frame focus either.
>  >
>  > You are saying the same thing I am.  Can you distill a 
>  > simpler test case?
> 
> No.  All I can say is that manually selecting the
> `minibuffer-window' seems harmful.

FWIW, I have not encountered any bugs selecting it (whatever you might mean by
"manually"), aside from the `save-selected-window' bug reported here.

>  > You seem to be saying that Emacs has introduced bugs, and 
>  > nothing more.
> 
> Where did I say that?

In the text you snipped, just before that sentence of mine:

>> I can't explain any of these.  In the past, I tried to
>> make most window functions work on any window/frame to
>> work independently from the selected window.  Earlier,
>> selecting a window must have been a very simple procedure.
>>  Nowadays, this incurs so many side-effects in the
>> window/frame/display area that you should
>> try to avoid `select-window' wherever possible.

And by "nothing more" I meant no more explanation: your "I can't explain any of
these".

> IIUC all Emacs version behave the same wrt your
> scenario.

Correct.  It is you who suggested that selecting a window used to be simpler
than now, and that now it has "many" side effects - so much so that you advise
people to avoid `select-window'.  My finding was that the `save-selected-window'
changes-the-focus bug is present in all Emacs releases (20 through 24).

>  > OK, so I hear the admonition to avoid `select-window'
>  > wherever possible.  That's a sorry state, though.
>  > You seem to be saying that things that used to work, and
>  > work simply, are now so bugged or complicated that all we 
>  > can advise is to avoid using `select-window'.
> 
> Selecting a window or a frame for the sole purpose to retrieve or
> compare a value related to that window is plain overkill given that
> `select-window' also selects a frame, makes a buffer current ...

Agreed 100%.  That's why I welcome your suggestions of simpler code to
accomplish that.

It was not obvious to me that `frame-first-window' could be used to test for
only-one-window-ness, or that the doc prior to Emacs 24 for `one-window-p' was
not correct wrt a frame argument.  Your simplifications are welcome, but they
were far from obvious, to me.

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 >> All I can say is that for me `one-window-p' is much too hard to
 >> understand.  I wouldn't use it.  Can't you compare the results of
 >> `frame-first-window' and `minibuffer-window' instead?
 >
 > Is that sure to DTRT?  If so, fine.  I am not familiar with
 > `frame-first-window'.  It was certainly not obvious to me that if those two are
 > eq then the frame can only be showing a minibuffer window (no other windows).
 >
 > `f-f-w' is written in C, and its definition has changed somewhat over Emacs
 > releases.   But if I pass a frame parameter

... frame argument, I suppose ...

 > then I guess the different
 > definitions should amount to the same thing.  I'll give that a try.

 >> Hardly.  Neither of these should affect focus.
 >
 > What can I say?  `save-selected-window' sure seems to.

What can I say?  `select-window' ends up calling somewhere
do_switch_frame which has

#ifdef HAVE_WINDOW_SYSTEM
   if (track && FRAME_WINDOW_P (XFRAME (frame)))
     {
       Lisp_Object focus, xfocus;

       xfocus = x_get_focus_frame (XFRAME (frame));
       if (FRAMEP (xfocus))
	{
	  focus = FRAME_FOCUS_FRAME (XFRAME (xfocus));
	  if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
	    Fredirect_frame_focus (xfocus, frame);
	}
     }
#endif /* HAVE_X_WINDOWS */

which _apparently_ directs focus away from one of your frames when it's
called for the first time and does not direct focus back to that frame
when it's called for the second time.  If you (like me) do not
understand why and how such a thing happens, you maybe understand why
I propose to side-step `select-window' in the first place.

 >> No.  All I can say is that manually selecting the
 >> `minibuffer-window' seems harmful.
 >
 > FWIW, I have not encountered any bugs selecting it

Maybe because in all other cases you explicitly wanted to select it (not
just temporarily/implicitly).

 > (whatever you might mean by
 > "manually"),

By "manually" I mean that you "explicitly" select it.  I always leave it
to Emacs to select the minibuffer window.

 >>  > You seem to be saying that Emacs has introduced bugs, and
 >>  > nothing more.
 >>
 >> Where did I say that?
 >
 > In the text you snipped, just before that sentence of mine:
 >
 >>> I can't explain any of these.  In the past, I tried to
 >>> make most window functions work on any window/frame to
 >>> work independently from the selected window.  Earlier,
 >>> selecting a window must have been a very simple procedure.
 >>>  Nowadays, this incurs so many side-effects in the
 >>> window/frame/display area that you should
 >>> try to avoid `select-window' wherever possible.
 >
 > And by "nothing more" I meant no more explanation: your "I can't explain any of
 > these".

The fact that I can't explain something means just that: I'm too silly
to comprehend what's going on - but not that Emacs has introduced any
bugs.  Meanwhile Emacs has to interact with too many different operating
systems and window managers, in particular when multiple frames are
involved.

 >> IIUC all Emacs version behave the same wrt your
 >> scenario.
 >
 > Correct.  It is you who suggested that selecting a window used to be simpler
 > than now,

... because people working with a different OS want Emacs to DTRT on
their OS and selecting a window which implicitly selects a frame had to
cope with their needs ...

 > and that now it has "many" side effects - so much so that you advise
 > people to avoid `select-window'.  My finding was that the `save-selected-window'
 > changes-the-focus bug is present in all Emacs releases (20 through 24).

... and to solve this we probably have to add another twist as soon as
someone is able to understand and resolve this particular issue ...

 > It was not obvious to me that `frame-first-window' could be used to test for
 > only-one-window-ness, or that the doc prior to Emacs 24 for `one-window-p' was
 > not correct wrt a frame argument.  Your simplifications are welcome, but they
 > were far from obvious, to me.

To me as well.  I tried to find out which function was present in early
Emacsen and whether it could DTRT (in principle).

martin

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

FYI -

I had updated my version of `special-display-popup-frame' to fit the latest
Emacs 24 definition of it.  (All my version tries to do differently is fit the
popped up frame to its buffer, nothing more.)

It turns out that in making that update I dropped this sexp from my original
definition of the function - the sexp is not in the vanilla Emacs definition:

  (set-window-buffer window buffer)

I have now added that back, because the code does not work without it.  The
problem was that the frame popped up did not show the BUFFER.  It showed another
buffer.

I mention this in case it might also be needed for the vanilla code (?), or in
case it might point to a bug somewhere.  You understand these things better than
I, Martin.  Perhaps you will understand just what is going on.

Below is the full definition I am using, which works fine now, (just as before
Emacs 24).  You don't care about the code that fits the frame, but I show the
full definition, just in case it helps you understand better why I might need to
explicitly `set-window-buffer' and the vanilla code apparently does not need to
do that (?).

If you learn something from this, or if you can tell me what I'm not
understanding, please let me know.  Thx.

(defun special-display-popup-frame (buffer &optional args)
  "Pop up a frame displaying BUFFER.  Return its window.
If BUFFER is already displayed in a visible or iconified frame then
raise that frame.  Otherwise, display BUFFER in a new frame.

Optional argument ARGS is a list specifying additional information.

If ARGS is an alist, use it as a list of frame parameters.  If these
parameters contain (same-window . t) then display BUFFER in the
selected window.  If they contain (same-frame . t) then display BUFFER
in a window of the selected frame.

If ARGS is a list whose car is a symbol then use (car ARGS) as a
function to do the work: display the buffer and raise its frame.  Pass
it BUFFER as first argument, and (cdr ARGS) as the rest of the
arguments."
  (if (and args (symbolp (car args)))
      (apply (car args) buffer (cdr args))
    (let ((window  (get-buffer-window buffer 0)))
      (or
       ;; If we have a window already, make it visible.
       (and window
            (let ((frame  (window-frame window)))
              (make-frame-visible frame)
              (raise-frame frame)
              (when (fboundp 'display-buffer-record-window) ; Emacs 24+
                (display-buffer-record-window 'reuse window buffer))
              (when (fboundp 'fit-frame) (fit-frame frame))
              window))                  ; Return the window.
       ;; Reuse the selected window if the caller requested it.
       (and (cdr (assq 'same-window args))
            (condition-case nil ; Try Emacs 24 `switch-to-buffer' first.
                (progn (switch-to-buffer buffer nil t) (selected-window))
              (error            ; Try again, with old `switch-to-buffer'.
               (condition-case nil
                   (progn (switch-to-buffer buffer) (selected-window))
                 (error nil)))))
       ;; Stay on the same frame if requested.
       (and (or (cdr (assq 'same-frame args))  (cdr (assq 'same-window args)))
            (let ((pop-up-windows                t)
                  (pop-up-frames                 nil)
                  (special-display-buffer-names  ())
                  (special-display-regexps       ()))
              (display-buffer buffer)))
       ;; If no window yet, make one in a new frame.
       ;; `make-frame' creates the frame before the buffer is shown in it,
       ;; so do not call `fit-frame' until we can select the buffer's window.
       (let* ((make-frame-functions
               (delq 'fit-frame after-make-frame-functions))
              (frame
               (with-current-buffer buffer
                 (make-frame (append args special-display-frame-alist))))
              (window (frame-selected-window frame)))

         ;; *** IS THIS NOT NEEDED ALSO FOR VANILLA EMACS?  WHY NOT? ***
         (set-window-buffer window buffer)

         (set-window-dedicated-p window t)
         (when (fboundp 'display-buffer-record-window) ; Emacs 24+
           (display-buffer-record-window 'frame window buffer))
         ;; Now call `fit-frame', with WINDOW selected.
         (with-selected-window window (fit-frame))
         window)))))   ; Return the window.

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'

[Drew Adams]

Sorry, that should be:

 (save-selected-window window (select-window window) (fit-frame))

Probably doesn't matter for Emacs 24 (either seems to work OK here), but
`with-selected-window' is not defined for older Emacs versions.

>          (with-selected-window window (fit-frame))

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 > FWIW, even without loading your code, with my setup, (window-parameters) always
 > returns nil.  I will need to dig further to find out why.
 >
 > Perhaps you can help by telling me what vanilla Emacs code normally changes
 > things so that the value returned is non-nil.

`display-buffer-record-window'

 > IOW, what parts of the Emacs code
 > should be setting this up correctly?  That might help me narrow things down to
 > find what code I have that is counteracting that correct setup.

The doc-string of `special-display-function' tells what should be done.
The code of `special-display-popup-frame' shows how this can be done.

 > I note that in Emacs 23 also (windows-parameters) returns nil for me.  (And the
 > function apparently does not exist in Emacs 22.)

`display-buffer-record-window' has been introduced in Emacs 24.1.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibufferfocuswhenitcalls`list-processes'

[Drew Adams]

>  > Perhaps you can help by telling me what vanilla Emacs code 
>  > normally changes things so that the value [of (windows-parameters)]
>  > returned is non-nil.
> 
> `display-buffer-record-window'
> 
>  > I note that in Emacs 23 also (windows-parameters) returns nil for me.
> 
> `display-buffer-record-window' has been introduced in Emacs 24.1.

How does that make sense?  If `display-buffer-record-window' is what makes
`windows-parameters' return non-nil, and `windows-parameters' existed back in
Emacs 23, and `display-buffer-record-window' did not exist in Emacs 23, then
`windows-parameters' would have always returned nil in Emacs 23, no?

Why would it exist back then if it always returned nil?  Does/did it have side
effects or something?  And its doc even in Emacs 23 says that it returns a list
of elements of form (PARAMETER . VALUE).

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibufferfocuswhenitcalls`list-processes'

[martin rudalics]

 >>  > Perhaps you can help by telling me what vanilla Emacs code
 >>  > normally changes things so that the value [of (windows-parameters)]
 >>  > returned is non-nil.
 >>
 >> `display-buffer-record-window'
 >>
 >>  > I note that in Emacs 23 also (windows-parameters) returns nil for me.
 >>
 >> `display-buffer-record-window' has been introduced in Emacs 24.1.
 >
 > How does that make sense?  If `display-buffer-record-window' is what makes
 > `windows-parameters'

... with vanilla Emacs code ...

 > return non-nil, and `windows-parameters' existed back in
 > Emacs 23, and `display-buffer-record-window' did not exist in Emacs 23, then
 > `windows-parameters' would have always returned nil in Emacs 23, no?

It would have always returned nil in a vanilla Emacs 23.

 > Why would it exist back then if it always returned nil?

For a user or an application to store values in it.

 > Does/did it have side
 > effects or something?

Not to my knowledge.

 > And its doc even in Emacs 23 says that it returns a list
 > of elements of form (PARAMETER . VALUE).

nil is an empty list of elements of form (PARAMETER . VALUE)

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes'

[martin rudalics]

 > I will try to narrow things down when I get some time.  Perhaps you can look
 > from your side, since your code that breaks special display is very small, and
 > especially since you have a good understanding of how it changes things.

As the example with emacs -Q demonstrates, my code does not break special
display.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls`list-processes'

[Drew Adams]

>  > I will try to narrow things down when I get some time.  
>  > Perhaps you can look from your side, since your code that
>  > breaks special display is very small, and especially since
>  > you have a good understanding of how it changes things.
> 
> As the example with emacs -Q demonstrates, my code does not 
> break special display.

No need to be defensive.  I was clear in saying that it breaks special display
for my setup.  That some example with emacs -Q might not be broken does not
invalidate the fact that with my setup plus your code it is broken.

By "it is broken" I mean that buffers that should have dedicated windows
(because they are defined to be special display) do not: other buffers replace
them in their windows.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes'

[martin rudalics]

 >> Tell me the value of the *Help*
 >> window's `quit-restore' parameter.
 >
 > Before loading your code there is no such parameter present.
 > Likewise after loading it: no such parameter.

Whenever I call `display-buffer', the window used has the `quit-restore'
parameter set.  If it doesn't on your system, I don't know.

 >>  > IOW, the *Help* frame is apparently no longer
 >>  > special-display as it should be.
 >>
 >> It still is and should call `frame-auto-hide-function'.
 >
 > No idea what that means.

`frame-auto-hide-function' is the function called to automatically hide
frames.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes'

[Drew Adams]

>  >> Tell me the value of the *Help*
>  >> window's `quit-restore' parameter.
>  >
>  > Before loading your code there is no such parameter present.
>  > Likewise after loading it: no such parameter.
> 
> Whenever I call `display-buffer', the window used has the 
> `quit-restore' parameter set.  If it doesn't on your system,
> I don't know.

I don't know either.  I've never seen that frame parameter.

This has nothing specially to do with the *Help* frame.  When I do
(frame-parameters) in ANY frame I do not see a parameter named `quit-restore'.

Am I missing something?  Is this parameter not returned via `frame-parameters'
or something?

>  >>  > IOW, the *Help* frame is apparently no longer
>  >>  > special-display as it should be.
>  >>
>  >> It still is and should call `frame-auto-hide-function'.
>  >
>  > No idea what that means.
> 
> `frame-auto-hide-function' is the function called to 
> automatically hide frames.

What I don't understand is your statement "It still is".  From appearances it is
not special-display, in the sense that its frame does not seem to be dedicated.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes'

[martin rudalics]

 >>  >> Tell me the value of the *Help*
 >>  >> window's `quit-restore' parameter.
        ^^^^^^

 >>  >
 >>  > Before loading your code there is no such parameter present.
 >>  > Likewise after loading it: no such parameter.
 >>
 >> Whenever I call `display-buffer', the window used has the
                                          ^^^^^^

 >> `quit-restore' parameter set.  If it doesn't on your system,
 >> I don't know.
 >
 > I don't know either.  I've never seen that frame parameter.
 >
 > This has nothing specially to do with the *Help* frame.  When I do
 > (frame-parameters) in ANY frame I do not see a parameter named `quit-restore'.
 >
 > Am I missing something?  Is this parameter not returned via `frame-parameters'
 > or something?

It's returned via `window-parameters'.

 >
 >>  >>  > IOW, the *Help* frame is apparently no longer
 >>  >>  > special-display as it should be.
 >>  >>
 >>  >> It still is and should call `frame-auto-hide-function'.
 >>  >
 >>  > No idea what that means.
 >>
 >> `frame-auto-hide-function' is the function called to
 >> automatically hide frames.
 >
 > What I don't understand is your statement "It still is".  From appearances it is
 > not special-display, in the sense that its frame does not seem to be dedicated.

The notion "dedicated frame" is an aberration of the Elisp manual.
Emacs code nowhere supports such a notion.  What "appearances" have to
do with dedicatedness is beyond my imagination.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes'

[Drew Adams]

>  > This has nothing specially to do with the *Help* frame.  When I do
>  > (frame-parameters) in ANY frame I do not see a parameter 
>  > named `quit-restore'.
>  >
>  > Am I missing something?  Is this parameter not returned 
>  > via `frame-parameters' or something?
> 
> It's returned via `window-parameters'.

(window-parameters) returns nil.  In every window I've tried so far.  Let me
know if there is some particular test you want me to make.

>  >>  >>  > IOW, the *Help* frame is apparently no longer
>  >>  >>  > special-display as it should be.
>  >>  >>
>  >>  >> It still is and should call `frame-auto-hide-function'.
>  >>  >
>  >>  > No idea what that means.
>  >>
>  >> `frame-auto-hide-function' is the function called to
>  >> automatically hide frames.
>  >
>  > What I don't understand is your statement "It still is".  
>  > From appearances it is not special-display, in the sense that its
>  > frame does not seem to be dedicated.
> 
> The notion "dedicated frame" is an aberration of the Elisp manual.
> Emacs code nowhere supports such a notion.

If you want to describe the phenomenon in more accurate terms, please do so.  I
simply meant, as should have been clear from the context, that _the window in
which the buffer is displayed_ does not seem to be dedicated.  Since the frame
is a one-window frame, I spoke informally of its _frame_ not seeming to be
dedicated.

I'm all for being more precise in the language if you think it helps our
communication.  Feel free to express things more precisely and I will try to
follow your lead.

But let's not try to be pedantic to no good end.  I think you know full well
what I was saying, no?  The buffer was replaced in its window by another buffer.

> What "appearances" have to do with dedicatedness is beyond my imagination.

Substitute "behavior" for "appearances", if you like.  I think you understand
what I am saying.

The point is that it should not be possible for another buffer to take the place
of a special-display buffer in its window.  The window should be dedicated.  And
that is not what I am seeing (after loading your code).

Everywhere that a buffer (in my setup) would normally be special-display, hence
its window would be dedicated, it is not so after I load your code.  No buffer
that should be special-display is so, in the sense that no buffer's window is
dedicated, as shown by the buffer being replaced in that window by another.

That last phrase is, as should have been obvious, what I meant by "from
appearances".  And I only added "from appearances" because you are apparently
(from appearances ;-)) insisting that the buffer _is_ special-display.

If it is in fact special-display, in some sense that I am not familiar with,
then at least _from appearances_, with my understanding of special-display, it
is not.  And by that I mean that it does not appear to behave as a
special-display buffer should behave wrt having a dedicated window: its window
does not seem to be dedicated.

Clear enough now?

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 > It is only the code that is calling for such a user dialog that knows that that
 > is what is being called for.  By "such a user dialog", again, I mean (a) the
 > display of a buffer for information only, i.e., one that does not need the input
 > focus, and (b) request of user input with the previous buffer remaining current
 > and the minibuffer having the input focus.
 >
 > That is the use case that is problematic.  It is the case where the above
 > systematic "fix" is inappropriate.  There might be other such use cases, but it
 > is the only one I have encountered.  And I have encountered it in several
 > different places (e.g., Dired *Marked Files* popup, *Process List* popup).
 >
 > My suggestion is, again, that we try to come up with a construct that covers
 > this use case, and then use it in the appropriate places: places where we do (a)
 > + (b).

Users who want to pop up a frame with a minibuffer almost certainly want
to supply their input right in the frame where the informational buffer
is displayed.  So there is a use case where the informational buffer
must be made current.  Also, when the new frame is popped up and
`handle-switch-frame' switches to it, the informational buffer is made
current anyway.  So we'll have a hard time preserving the "with the
previous buffer remaining current" requirement throughout the dialog.

 > On the other hand, if you know of a way to _detect_ such an intention on the
 > part of the developer, i.e., somehow _detect_ whether the displayed buffer
 > should have input focus, then I'm all ears.

You know that buffers don't have input focus - only frames do, so please
keep this distinction alive here.  I think we agree that developers
leave it to us users to decide whether the buffer is shown in a new or
an existing frame.  For a use case where the frame of the displayed
buffer should have input focus see the `pop-up-frames' non-nil case.

 > I don't expect that to be possible, which is why I propose that the developer
 > make the intention explicit by using a new construct (e.g. a macro) that takes
 > care of this.
 >
 > The construct would display the informational buffer and redirect its input
 > focus to a standalone minibuffer, if there is one.  If there is no standalone
 > minibuffer frame, then that part could be a no-op, AFAICT.

We would at least have to make this optional.  Users might want to
prefer standalone buffers for most of their input but prefer answering
the dialogs we talk about here in a minibuffer frame with the list of
files being displayed in the same frame.  The new option, let's call it
`always-redirect-input-to-standalone-minibuffer-frame', if non-nil,
could be used by your construct.

 > Something like this:
 >
 > (with-unfocused-buffer-displayed BUFFER &body BODY)
 >
 > where BUFFER is displayed for information only, and where BODY would include the
 > call(s) that read from the minibuffer.
 >
 > The current buffer would remain what it was beforehand, and _if_ BUFFER gets
 > displayed in its own frame and _if_ there is a standalone minibuffer frame,
 > _then_ the focus for BUFFER's frame gets automatically redirected to the
 > minibuffer frame.

In my experience, this requirement is met if the construct requests
input with BUFFER's window temporarily selected and BUFFER temporarily
current.  Or am I missing something?

 > If those conditions do not hold then there is no special
 > handling needed - the construct can essentially be a no-op in that case
 > (AFAICT).
 >
 > How something like this would be implemented I'm not sure.  When the redirection
 > would need to take place, to DTRT, I'm not sure.  Perhaps it would need to be
 > done more than once.
 >
 > But an important further requirement is that nothing should prevent Emacs code
 > in BODY or called from within BODY from switching the input focus to BUFFER's
 > frame.

I don't understand what BODY should contain.  Would this macro be
responsible for displaying BUFFER?

 > Likewise, nothing should prevent the user from explicitly switching the
 > focus to BUFFER's frame.

This is part of the `yes-or-no-p' dialog, nothing within the scope of
the construct you propose.

 > The only switching of focus to BUFFER's frame that this construct would be
 > trying to prevent would be something that comes from neither a user action nor
 > the Emacs code - in particular, MS Windows auto-focussing a newly created frame.

And the only way of "trying to prevent" I can think of is to redirect
focus by requesting input from BUFFER's frame.

 > Again, I don't know the "how".  But (so far) I'm convinced that this has to be
 > an explicit Emacs construct: there needs to be some way for a Lisp programmer to
 > communicate the intention that BUFFER is not intended to have the input focus

... BUFFER's frame ...

 > during BODY (unless that is done by the user or by code within BODY).

... during the subsequent reading from the minibuffer.  BODY has
terminated long ago at that time I suppose.

 > I do not expect that the problematic use case we've been discussing can be
 > detected and dealt with correctly in an automatic way.  If the programmer
 > intention

Who is the programmer here?

 > cannot be made explicit then there is no way to know what TRT is.

First we have to separate application from user in a clear way.

 > It's problematic enough even with the intention communicated, in the sense that
 > we need to allow users and Emacs code to give focus to BUFFER's frame if they
 > want to.  IOW, even if we _know_ that initially BUFFER's frame should not be
 > focused, it is hard enough to prevent or undo focusing by MS Windows while still
 > allowing users and Emacs to focus BUFFER.

Yes.

 > That's the point of providing programmers with a construct to express that
 > intention explicitly: "This buffer's frame, if it is displayed in its own frame,
 > should not receive the focus."

Let's be realistic, programmers won't care.  We can only provide a
construct that's convenient enough and has been tested in a few model
cases like the ones we know of.

 > By "might pop up" I meant that _if_ informational BUFFER is popped up in its own

minibuffer-less

 > frame, _then_ the intention is that that frame not receive the input focus.
 >
 >>  > redirecting focus for any new frames to the minibuffer.
 >>
 >> And what you have in mind here should be distinguishable from other
 >> things that pop up frames but do not want the redirection.
 >
 > Not sure I follow you.  Are you referring to the equivalent of possibly nested
 > `with-unfocused-buffer-displayed' calls?

I refer to the case where a minibuffer-equipped frame is popped up.

 > Here's the thing.  I don't know whether we can come up with something that is
 > 100% reliable.  But the important thing, I think, is to have _some_ programmatic
 > translation of the programmer intention that this BUFFER be shown without giving
 > it the input focus.
 >
 > Today there is no way for a programmer to indicate that.  S?he might not
 > _expect_ that the focus would be grabbed away from a minibuffer frame and given
 > to a new frame, but that lack of expectation today is mainly based on
 > inexperience with a standalone minibuffer and MS Windows.
 >
 > What's needed is some way to reinforce the programmer's natural expectation that
 > the user can in fact type input into the minibuffer even when the informational
 > buffer gets displayed.
 >
 > No one would naturally expect that not to be the case, but it can be the case,
 > unfortunately.  So the idea is to somehow support the natural expectation and
 > take away the possibility (or reduce the probability) of MS Windows interfering
 > with what should be a simple user dialog.

OK.  If you think that the way with-temp-buffer-window.el handles it is
not enough, tell me what you would do instead.

 >> What you want is some clairvoyance in step (1) of my description
 >> above whether step (2) will be performed.
 >
 > No, I don't think so.  I don't believe in such clairvoyance (but I'm open to
 > being convinced).  Instead, I believe in the programmer stating that the buffer
 > is not intended to have the focus.  (But that nothing should prevent Emacs or
 > the user from giving it the focus at some point.)

Why don't you code the macro you have in mind so we can discuss it?

 >> `with-temp-buffer-window' avoids that by asking the `yes-or-no-p'
 >> question in the new frame.
 >
 > The issue at stake is the case of a standalone minibuffer.  I don't see any
 > problem if there is no standalone minibuffer frame.
 >
 > With a standalone minibuffer frame, the proper behavior is for the minibuffer
 > frame to be used for all minibuffer activity.  Anything else is less than
 > desirable, even if it might be acceptable if no better solution could be found
 > in some case.
 >
 > A user of a standalone minibuffer looks there for all echo-area output and all
 > minibuffer input.  That is one of the reasons for using a standalone minibuffer:
 > a single place where all Q & A with the user takes place.
 >
 > Well, nearly all.  Yes, there are some times where things like `read-event' are
 > used instead of the minibuffer.  But let's not get pedantic; this is about use
 > of the minibuffer and echo area.  A standalone minibuffer offers the advantage
 > of always looking to the same place on the screen for user I/O.

So let's use an option like
`always-redirect-input-to-standalone-minibuffer-frame' and you propose a
macro that does what you mean based on that option (I'm afraid I do not
understand well what you think that macro's BODY should do).

 > The other potential trouble is the need to show an informational buffer that
 > does not necessarily correspond to what you have defined for
 > `with-temp-buffer-window'.

So you think it's too restrictive?

 > To be clear, I do not know whether such a need exists much in practice.  But it
 > looks to me like your macro and the related code you sent make additional
 > assumptions about the buffer that is popped up that constrain it more than what
 > I was describing abstractly for the hypothetical
 > `with-unfocused-buffer-displayed'.

It's a substitute for `with-output-to-temp-buffer' with an additional
function that can be used to replace the return value of the former.

 > The buffer in the case of `with-temp-buffer-window' starts out from scratch (it
 > must be empty), etc.  In a nutshell, your construct assumes that the buffer
 > itself is temporary, whereas the only real need for our problematic use case is
 > that the buffer's _display_, in a separate frame, be temporary.

The buffer need not be temporary.  But in order for quitting to get rid
of the frame, the buffer must be killed.

 > IOW, I think your solution is more constraining/limited and doesn't really
 > address the general problem, which is that of displaying _any_ buffer for only
 > informational use (at least initially, allowing for user/code to intentionally
 > switch focus to it).  And AFAIK the problem we are trying to solve occurs only
 > when such a buffer appears in its own frame.
 >
 > Your solution certainly helps for things like *Process List* and *Marked Files*.
 > But the characterization of the problem is, logically, in terms of a buffer that
 > is displayed temporarily during a minibuffer dialog, in its own frame, and whose
 > frame should not have the input focus in that context.
 >
 > Am I wrong about that?

If you came up with a macro that (approximately) does what you
want/need, I probably could answer that question.

 > Don't get me wrong.  I think your code (the little that I've tried using it) is
 > a definite improvement for the problem cases we've actually encountered, which
 > are in fact not only temporary displays of a buffer but also displays of a
 > temporary buffer.
 >
 > I'm just saying that I think the problem of MS Windows giving the focus to a new
 > frame that gets popped during a minibuffer interaction, where that new frame
 > should not have the focus, i.e., where its buffer is shown only for information,
 > is more general than the show-a-temporary-buffer case you have treated.
 >
 > At least that's what I think so far.  You'll tell me if I'm wrong.

You might be right.

 >> It's not that simple. The invoking code doesn't care about focus
 >
 > It does care.  Maybe what you mean is that it does not expect the focus to be
 > messed with by MS Windows.

The invoking code does not care.  It expects `display-buffer' and
`yes-or-no-p' to take care of this.

 > Typically, such code simply does not expect (take into account) a scenario where
 > the user (a) has a standalone minibuffer frame, (b) has the buffer in question
 > be popped up in its own frame, and (c) is on MS Windows, which steals the input
 > focus and gives it to the new frame.
 >
 > But the code does expect the minibuffer to have the focus, and it knows that the
 > buffer is shown only for informational purposes, i.e., the buffer does not need
 > (and should not have) the input focus.

Once more - the code expects the underlying mechanism to handle that.

 > The code does not, today, explicitly express that intention/care, because
 > outside of the problematic case of (a), (b), and (c), which today is not that
 > common, there is no need to express and handle that intention.  IOW it cares,
 > but its cares are already taken care of automatically in most cases.
 >
 >> and in particular not about some frame whose eventually popping
 >> up will cause problems.  It expects the reading from the minibuffer
 >> mechanism DTRT.
 >
 > Precisely.  And except for the problematic case, there has never been any need
 > for the programmer to make clear the fact (intention) that the buffer is
 > informational only.
 >
 > You have encapsulated precisely that intention in your code.  But you have gone
 > beyond that and expressed the additional intention that the buffer be temporary.

So write a `with-buffer-window' doing things in a non-temporary fashion.
The problem is that removing the frame without killing the buffer will
be impossible unless we provide yet another option.

 > And your code in fact does make the distinction between *Process List* and
 > *Backtrace*, which proves my point here.  But your code makes the distinction
 > based on *Process List* being a temporary buffer (which it is), and not on it
 > being a buffer that is displayed temporarily in its own frame.
 >
 > The latter distinction is I think the right one, and which would be good to
 > handle.  That is where MS Windows's automatic focusing leads to a problem.
 >
 > The problematic case is (a) standalone minibuffer (b) popped-up buffer in its
 > own frame, (c) that frame being new, and (d) the OS giving the new frame the
 > input focus.

You still have to tell me how to remove that frame when you're done.

 > The second step, I think, would be something similar, but not limited to
 > temporary buffers.  Some way for a programmer to express the intention of
 > displaying a buffer (temporary or not) only for informational purposes during a
 > minibuffer interaction.
 >
 > And I think that for that more general case, there is a problem to be handled
 > only when (a) there is a standalone minibuffer frame, (b) the buffer is popped
 > up in its own frame.

Write the macro and we'll see further.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

> Users who want to pop up a frame with a minibuffer almost 
> certainly want to supply their input right in the frame where the 
> informational buffer is displayed.  So there is a use case where
> the informational buffer must be made current.

Again, AFAIK there is no problem if the user does not use a standalone
minibuffer.  A user with a standalone minibuffer is the problematic use case,
and the only one I am really concerned about.  AFAIK, whatever exists already
is, I assume, OK for other use cases.

So what you say here about such use cases ("users who want to pop up a frame
with a minibuffer") is irrelevant to the discussion, or at least to my part of
it.  If you think there is also a problem for such cases, fine, but I cannot
speak to that.  I am interested in the case that I reported, i.e., for users
with a standalone minibuffer frame.

> Also, when the new frame is popped up and
> `handle-switch-frame' switches to it, the informational buffer is made
> current anyway.  So we'll have a hard time preserving the "with the
> previous buffer remaining current" requirement throughout the dialog.

Which is why I have been saying that it will need to be about restoring focus to
the minibuffer, rather than preventing focus from leaving it.  We've already
been around this barn a couple times now, no?  MS Windows presumably takes the
focus away, and there is apparently nothing we can do to prevent that.  So
what's needed is to try to put the focus back where it belongs, if that happens.

>  > On the other hand, if you know of a way to _detect_ such 
>  > an intention on the part of the developer, i.e., somehow _detect_
>  > whether the displayed buffer should have input focus, then
>  > I'm all ears.
> 
> ... I think we agree that developers leave it to us users to decide
> whether the buffer is shown in a new or an existing frame.

Yes, but I don't see how that is relevant here.  The point is that a developer
would have some way to indicate the _intention_ that the minibuffer retain the
focus.

Where and how the informational buffer is displayed should be taken into
consideration in _defining_ the macro or whatever that developers would use.
But the developer would not be concerned with where or how the buffer is
displayed.  All the developer would need to communicate is the intention that
the minibuffer have the focus.

> For a use case where the frame of the displayed
> buffer should have input focus see the `pop-up-frames' non-nil case.

Dunno what that means.  That seems irrelevant here.  In particular, I use that
case (non-nil p-u-f), and I can tell you that there are cases (e.g. *Backtrace*)
where the buffer that is popped up in its own frame should have the input focus,
and there are cases (e.g. *Process List*) where it should not.

>  > I don't expect that to be possible, which is why I propose 
>  > that the developer make the intention explicit by using a new
>  > construct (e.g. a macro) that takes care of this.
>  >
>  > The construct would display the informational buffer and 
>  > redirect its input focus to a standalone minibuffer, if
>  > there is one.  If there is no standalone minibuffer frame,
>  > then that part could be a no-op, AFAICT.
> 
> We would at least have to make this optional.  Users might want to
> prefer standalone buffers for most of their input 

I really do not follow you, sorry.  Are you talking about minibuffer input?

I am talking _only_ about the case of users who have a standalone minibuffer
frame.  That is the problematic case that we have (I think) been discussing from
the beginning.

> but prefer answering the dialogs we talk about here in a minibuffer 
> frame with the list of files being displayed in the same frame.

Sorry, I am quite lost.  What "list of files"?

Here's a wild guess (ignore, if it is wrong and does not save us time): You are
introducing something new, which is the possibility that a user with a
standalone minibuffer frame might, in some situations, NOT want minibuffer input
and echo-area messages to take place in the standalone minibuffer frame.

Is that it?  If so, I would respectfully request that we drop that like a hot
potato.  There is zero request for such a feature AFAIK.  I know of no such user
- do you?

If you are interested in that and convinced that there is demand for it, you can
always pursue it as an option after this bug gets fixed.

I have no objection to the creation of such a new feature, but let's first solve
the problem encountered.

> The new option, let's call it
> `always-redirect-input-to-standalone-minibuffer-frame', if non-nil,
> could be used by your construct.

No, please.  What I am describing is not about _always_ redirecting input focus
to a standalone minibuffer frame.  The *Backtrace* example speaks to why that is
not appropriate.

It is about redirecting (retaining/restoring, really) input focus to that frame
ONLY for _minibuffer_ input.

In sum, it is about respecting the standalone minibuffer.  If a user creates a
standalone minibuffer frame then s?he does not want other minibuffers created on
other frames.

>  > Something like this:
>  > (with-unfocused-buffer-displayed BUFFER &body BODY)
>  >
>  > where BUFFER is displayed for information only, and where 
>  > BODY would include the call(s) that read from the minibuffer.
>  >
>  > The current buffer would remain what it was beforehand, 
>  > and _if_ BUFFER gets displayed in its own frame and _if_
>  > there is a standalone minibuffer frame, _then_ the focus
>  > for BUFFER's frame gets automatically redirected to the
>  > minibuffer frame.
> 
> In my experience, this requirement is met if the construct requests
> input with BUFFER's window temporarily selected and BUFFER 
> temporarily current.  Or am I missing something?

Sorry, I don't know what that means.  Perhaps give an example of what you mean
by temporarily selected and current?

>  > If those conditions do not hold then there is no special
>  > handling needed - the construct can essentially be a no-op 
>  > in that case (AFAICT).
>  >
>  > How something like this would be implemented I'm not sure. 
>  > When the redirection would need to take place, to DTRT,
>  > I'm not sure.  Perhaps it would need to be done more than once.
>  >
>  > But an important further requirement is that nothing 
>  > should prevent Emacs code in BODY or called from within
>  > BODY from switching the input focus to BUFFER's frame.
> 
> I don't understand what BODY should contain.  Would this macro be
> responsible for displaying BUFFER?

No, not as I was conceiving it.  I suppose that would be a possibility, but I
expect it is better to keep buffer display out of it.  That's why I said things
like "_if_ BUFFER gets displayed in its own frame".

What I had in mind was that the macro would be responsible only for making sure
that minibuffer input gets (re-)directed to the minibuffer frame.  And that goes
for any code in BODY, including code that might pop up BUFFER.

IOW, display of BUFFER would come (if it came) from BODY.

But again, I'm just thinking out loud.  And it's probable that you see things
that I do not.

>  > Likewise, nothing should prevent the user from explicitly 
>  > switching the focus to BUFFER's frame.
> 
> This is part of the `yes-or-no-p' dialog, nothing within the scope 
> of the construct you propose.

Can you elaborate?  I don't follow.

All that I am saying is that we try to provide some kind of a construct that
says:

1. Evaluate BODY.

2. But while doing that, _if_ BUFFER gets displayed, then ensure that its
minibufer input (if the minibuffer is used) is directed to the standalone
minibuffer frame.

IOW, the use of this construct distinguishes the *Process List* case from the
*Backtrace* case: The construct would be used for display of *Process List*,
since we do not want that buffer to get the input focus.  The construct would
not be used for the *Backtrace* case.

But I'm open to other suggestions.

>  > The only switching of focus to BUFFER's frame that this 
>  > construct would be trying to prevent would be something
>  > that comes from neither a user action nor
>  > the Emacs code - in particular, MS Windows auto-focussing 
>  > a newly created frame.
> 
> And the only way of "trying to prevent" I can think of is to
> redirect focus by requesting input from BUFFER's frame.

That's not a solution at all.  Again, we're talking about minibuffer input,
i.e., input with the minibuffer active, and input that is intended to be read in
the minibuffer.  The aim is to get the focus moved to the minibuffer frame.

I am not looking for the creation of minibuffers on other frames.  I am looking
for a fix to the problem that the minibuffer frame is not getting (or
retaining?) the focus it needs when minibuffer input is called for.

>  > Again, I don't know the "how".  But (so far) I'm convinced 
>  > that this has to be an explicit Emacs construct: there needs
>  > to be some way for a Lisp programmer to communicate the
>  > intention that BUFFER is not intended to have the input focus
> 
> ... BUFFER's frame ...

Yes.

>  > during BODY (unless that is done by the user or by code 
>  > within BODY).
> 
> ... during the subsequent reading from the minibuffer.  BODY has
> terminated long ago at that time I suppose.

No.  Again, during reading from the minibuffer it is quite possible for a user
to interact with other buffers and their frames.  I gave the example of
*Completions*.  The user can hit a key or use the mouse to change the input
focus temporarily to another frame - any frame.

When the user does that s?he is executing code within BODY.  It is code that
reads from the minibuffer, but also code that implements any commands bound to
keys or mouse actions that the user uses during that minibuffer dialog.  That's
all I meant.

>  > I do not expect that the problematic use case we've been 
>  > discussing can be detected and dealt with correctly in an
>  > automatic way.  If the programmer intention
> 
> Who is the programmer here?

The person who writes the code that reads from the minibuffer, code that might
or might not be wrapped in the new macro, i.e., that might or might not want to
stipulate that BUFFER is not to receive the input focus.

>  > cannot be made explicit then there is no way to know what TRT is.
> 
> First we have to separate application from user in a clear way.

(?)
 
>  > It's problematic enough even with the intention 
>  > communicated, in the sense that we need to allow users
>  > and Emacs code to give focus to BUFFER's frame if they
>  > want to.  IOW, even if we _know_ that initially BUFFER's 
>  > frame should not be focused, it is hard enough to
>  > prevent or undo focusing by MS Windows while still
>  > allowing users and Emacs to focus BUFFER.
> 
> Yes.
> 
>  > That's the point of providing programmers with a construct 
>  > to express that intention explicitly: "This buffer's frame,
>  > if it is displayed in its own frame, should not receive
>  > the focus."
> 
> Let's be realistic, programmers won't care.

As one programmer, I care.

But I agree that it will be difficult to get programmers to be sensitive to the
possibility that some users have a standalone minibuffer and some OS's might
steal focus and give it to new frames that are popped up.

This is nothing new - Emacs developers tend not to even consider the non-nil
`pop-up-frames' case (or its Emacs 24+ equivalent) when they implement a new
feature.  For a poster-child example, see bug #12139.

But if things start to work better, more seamlessly, for Emacs with frames and a
standalone minibuffer, then maybe more users will opt for that.  And that will
perhaps mean that more programmers will naturally think to test such use cases
as well.  I can only continue to hope.

> We can only provide a construct that's convenient enough
> and has been tested in a few model cases like the ones
> we know of.

Agreed.  My description is vague not because I want the moon but because I don't
know what the implementation might look like.  If I get something that is better
I'll be happy, even if it is not perfect.

>  > By "might pop up" I meant that _if_ informational BUFFER 
>  > is popped up in its own
> 
> minibuffer-less

Of course.  We are only talking about the case where there is a standalone
minibuffer frame.  That is THE minibuffer - THE place where users look for input
queries and output messages.  All other frames are minibuffer-less.  Or they
should be.

Not being able to use the standalone minibuffer in some context, and having to
use another minibuffer somewhere else, would be a degraded mode, just a
workaround.  Better than nothing, perhaps (perhaps), but it does not respect the
standalone minibuffer or the user who called for it.

>  > frame, _then_ the intention is that that frame not receive 
>  > the input focus.
>  >
>  >>  > redirecting focus for any new frames to the minibuffer.
>  >>
>  >> And what you have in mind here should be distinguishable 
>  >> from other things that pop up frames but do not want
>  >> the redirection.
>  >
>  > Not sure I follow you.  Are you referring to the 
>  > equivalent of possibly nested
>  > `with-unfocused-buffer-displayed' calls?
> 
> I refer to the case where a minibuffer-equipped frame is popped up.

I'd rather you didn't.  Let's not bring in new things.

The problem is that the minibuffer is not getting the focus it needs.

There is no request for some additional, proxy minibuffer to appear somewhere
else.  That's not TRT.

You have a perfectly good, brand new car that runs fine.  You can drive it
everywhere except that there is one bridge that is broken near your home.  You
just cannot get home by car using that bridge.

What is offered as help is for you to wait at the washed-out bridge for a
helicopter that comes once a day and can take you across the river.  That's a
temporary workaround, and it might be welcome, but it is not a real solution.
The solution that is needed is for the bridge to be fixed.

>  > Here's the thing.  I don't know whether we can come up 
>  > with something that is 100% reliable.  But the important
>  > thing, I think, is to have _some_ programmatic
>  > translation of the programmer intention that this BUFFER 
>  > be shown without giving it the input focus.
>  >
>  > Today there is no way for a programmer to indicate that.  
>  > S?he might not _expect_ that the focus would be grabbed
>  > away from a minibuffer frame and given to a new frame,
>  > but that lack of expectation today is mainly based on
>  > inexperience with a standalone minibuffer and MS Windows.
>  >
>  > What's needed is some way to reinforce the programmer's 
>  > natural expectation that the user can in fact type input
>  > into the minibuffer even when the informational
>  > buffer gets displayed.
>  >
>  > No one would naturally expect that not to be the case,
>  > but it can be the case, unfortunately.  So the idea is
>  > to somehow support the natural expectation and take away
>  > the possibility (or reduce the probability) of 
>  > MS Windows interfering with what should be a simple user
>  > dialog.
> 
> OK.  If you think that the way with-temp-buffer-window.el 
> handles it is not enough, tell me what you would do instead.

I don't know.  The only problems I am aware of for `w-t-b-w.el' are these:

1. Loss of special-displayness (a separate problem, but important if we're
talking about `w-t-b-w.el' as it stands now).

2. The fact that it limits itself to display of temporary buffers, whereas the
actual problem has to do with the temporary display of buffers.

Unless I'm missing something, it does not have the problem (from my point of
view) that the frame popped up has its own minibuffer.  And that's good.  I
mention this because you keep mentioning that as a possibility.  I'm glad that
`w-t-b-w.el' does not make that happen.  

When I use `w-t-b-w.el' with the *Process List* thing it correctly prompts for
the answer in the minibuffer frame.  Dunno whether that is just because that is
a `yes-or-no-p' thing or whether the problem does not exist in general.  After
the special-display bug is fixed I'll try to use `w-t-b-w.el' more, to see.

Anyway, if `w-t-b-w.el' has no other problems than #2, and if #1 is fixed, then
I can certainly live with it.  And I will appreciate it!  Ideally I would like
something that I can also use with other Emacs versions, but as I said, that's
just a nice-to-have.

So I would say that if anything I've said suggests to you that you might be able
to improve `w-t-b-w.el' so that it handles an arbitrary buffer and not just a
temporary buffer, that would be great.  If not, then let's at least get
`w-t-b-w.el' into Emacs (after fixing the special-display bug).  That will be a
big improvement and much appreciated, by me at least.

Can you fix the special-display bug, so that I will be able to use `w-t-b-w.el'
more, to let you know if I encounter other problems?

And as far as you know, is the fact that the minibuffer frame is still used (as
it should be) due only to the fact that `yes-or-no-p' is used, or can I expect
that the minibuffer frame will be used in general?

>  >> What you want is some clairvoyance in step (1) of my description
>  >> above whether step (2) will be performed.
>  >
>  > No, I don't think so.  I don't believe in such 
>  > clairvoyance (but I'm open to being convinced).
>  > Instead, I believe in the programmer stating that the
>  > buffer is not intended to have the focus.  (But that
>  > nothing should prevent Emacs or the user from giving
>  > it the focus at some point.)
> 
> Why don't you code the macro you have in mind so we can discuss it?

I'm afraid I cannot help here.

>  >> `with-temp-buffer-window' avoids that by asking the
>  >> `yes-or-no-p' question in the new frame.

Dunno why I (or was it you?) said that.  I see the question in the minibuffer
frame, not the new frame.  Which is TRT.

>  > The issue at stake is the case of a standalone minibuffer. 
>  > I don't see any problem if there is no standalone
>  > minibuffer frame.
>  >
>  > With a standalone minibuffer frame, the proper behavior
>  > is for the minibuffer frame to be used for all minibuffer
>  > activity.  Anything else is less than desirable, even if
>  > it might be acceptable if no better solution could be
>  > found in some case.
>  >
>  > A user of a standalone minibuffer looks there for all 
>  > echo-area output and all minibuffer input.  That is one
>  > of the reasons for using a standalone minibuffer:
>  > a single place where all Q & A with the user takes place.
>  >
>  > Well, nearly all.  Yes, there are some times where things 
>  > like `read-event' are used instead of the minibuffer.
>  > But let's not get pedantic; this is about use of the
>  > minibuffer and echo area.  A standalone minibuffer 
>  > offers the advantage of always looking to the same place
>  > on the screen for user I/O.
> 
> So let's use an option like
> `always-redirect-input-to-standalone-minibuffer-frame'
> and you propose a macro that does what you mean

I'm afraid I cannot come up with the macro.  I was hoping that my description of
what would be good might inspire you. ;-)

> based on that option (I'm afraid I do not
> understand well what you think that macro's BODY should do).

I know I was vague, but I do not know what needs to be done in terms of
implementation.  If my description, including above, doesn't help, forget about
this enhancement.

>  > The other potential trouble is the need to show an 
>  > informational buffer that does not necessarily correspond
>  > to what you have defined for `with-temp-buffer-window'.
> 
> So you think it's too restrictive?

Yes, it is more restrictive than the actual problem encountered.  As I said, it
might suffice in practice, but there is nothing in the problem description that
requires that the buffer itself be temporary.

Yes, *Process List* and *Marked Files* are temporary.  But there is no reason to
suppose that we will never want to temporarily display some non-temporary buffer
without giving it the input focus.

>  > To be clear, I do not know whether such a need exists much 
>  > in practice.  But it looks to me like your macro and the
>  > related code you sent make additional assumptions about
>  > the buffer that is popped up that constrain it more than
>  > what I was describing abstractly for the hypothetical
>  > `with-unfocused-buffer-displayed'.
> 
> It's a substitute for `with-output-to-temp-buffer' with an 
> additional function that can be used to replace the return
> value of the former.

That's great.  I have no objection to it.  I was just saying that it corresponds
to a set of use cases that is a subset of the use cases where the input-focus
switch (by MS Windows) will present a problem.

>  > The buffer in the case of `with-temp-buffer-window' starts 
>  > out from scratch (it must be empty), etc.  In a nutshell,
>  > your construct assumes that the buffer itself is temporary,
>  > whereas the only real need for our problematic use case is
>  > that the buffer's _display_, in a separate frame, be temporary.
> 
> The buffer need not be temporary.  But in order for quitting 
> to get rid of the frame, the buffer must be killed.

In that, it is temporary.  Also in the fact (IIUC) that it is empty/emptied to
start with.

>  > IOW, I think your solution is more constraining/limited 
>  > and doesn't really address the general problem, which
>  > is that of displaying _any_ buffer for only
>  > informational use (at least initially, allowing for 
>  > user/code to intentionally switch focus to it).  And
>  > AFAIK the problem we are trying to solve occurs only
>  > when such a buffer appears in its own frame.
>  >
>  > Your solution certainly helps for things like *Process 
>  > List* and *Marked Files*.  But the characterization of
>  > the problem is, logically, in terms of a buffer that
>  > is displayed temporarily during a minibuffer dialog, in 
>  > its own frame, and whose frame should not have the input
>  > focus in that context.
>  >
>  > Am I wrong about that?
> 
> If you came up with a macro that (approximately) does what you
> want/need, I probably could answer that question.
> 
>  > Don't get me wrong.  I think your code (the little that 
>  > I've tried using it) is a definite improvement for the
>  > problem cases we've actually encountered, which
>  > are in fact not only temporary displays of a buffer but 
>  > also displays of a temporary buffer.
>  >
>  > I'm just saying that I think the problem of MS Windows 
>  > giving the focus to a new frame that gets popped during
>  > a minibuffer interaction, where that new frame should
>  > not have the focus, i.e., where its buffer is shown 
>  > only for information, is more general than the
>  > show-a-temporary-buffer case you have treated.
>  >
>  > At least that's what I think so far.  You'll tell me if I'm 
>  > wrong.
> 
> You might be right.

Let's move one step at a time.  I can't really help with coming up with the
macro that I imagine vaguely.  And you are having difficulty seeing what I'm
getting at, which might well be an indication that I am mixed up a bit.

Why don't you try to fix the special-display bug in your code, and then I'll use
it a bit more to see if I encounter other problems.  If not, then it would be
good if you added it to Emacs.  After that, we can always discuss any further
enhancements or other improvements, in a different thread or off list.

I think that most of what I've tried to say you understand, so if in the future
you do see a possibility of generalizing the fix etc. then you might want to do
so.  I cannot really expect more than to make myself understood so that you can
keep the wish in mind.

>  >> It's not that simple. The invoking code doesn't care about focus
>  >
>  > It does care.  Maybe what you mean is that it does not 
>  > expect the focus to be messed with by MS Windows.
> 
> The invoking code does not care.  It expects `display-buffer' and
> `yes-or-no-p' to take care of this.

In the general case it is not `yes-or-no-p'.

But OK, I think we are saying the same thing, using different words.

>  > Typically, such code simply does not expect (take into 
>  > account) a scenario where the user (a) has a standalone
>  > minibuffer frame, (b) has the buffer in question
>  > be popped up in its own frame, and (c) is on MS Windows, 
>  > which steals the input focus and gives it to the new frame.
>  >
>  > But the code does expect the minibuffer to have the focus, 
>  > and it knows that the buffer is shown only for informational
>  > purposes, i.e., the buffer does not need
>  > (and should not have) the input focus.
> 
> Once more - the code expects the underlying mechanism to handle that.

If you agree with the last paragraph I wrote, then fine.  I think we are saying
the same thing.  I certainly agree that the invoking code should not have to
care about setting/changing focus.  By "it cares" I meant only that it cares
that the minibuffer have the focus - it expects that.   It does not care/want to
have to manage the focus itself.  It "expects the underlying mechanism to handle
that."

The code's intention that the minibuffer receive the input is not something that
programmers should have to express.  But I see no way around that if MS Windows
gets in the middle and moves the focus around.  But if you can make sure that
there is no need to express such an intention in the code explicitly, so much
the better.

I was expecting that such expression would enable us to DTRT wrt focus
redirection, e.g. to distinguish the *Process List* case from the *Backtrace*
case.  But if that's not necessary, good.

>  > The code does not, today, explicitly express that 
>  > intention/care, because outside of the problematic case
>  > of (a), (b), and (c), which today is not that common,
>  > there is no need to express and handle that intention.
>  > IOW it cares, but its cares are already taken care of
>  > automatically in most cases.
>  >
>  >> and in particular not about some frame whose eventually
>  >> popping up will cause problems.  It expects the reading
>  >> from the minibuffer mechanism DTRT.
>  >
>  > Precisely.  And except for the problematic case, there has 
>  > never been any need for the programmer to make clear the
>  > fact (intention) that the buffer is informational only.
>  >
>  > You have encapsulated precisely that intention in your 
>  > code.  But you have gone beyond that and expressed the
>  > additional intention that the buffer be temporary.
> 
> So write a `with-buffer-window' doing things in a 
> non-temporary fashion.

See above.

> The problem is that removing the frame without killing
> the buffer will be impossible unless we provide yet another
> option.

Maybe it's good that we talk about this more general case later.  I don't want
the ideal to become the enemy of the good.  I would like to see your current
solution applied to Emacs before we get too far afield.

>  > And your code in fact does make the distinction between 
>  > *Process List* and *Backtrace*, which proves my point here.
>  > But your code makes the distinction based on *Process List*
>  > being a temporary buffer (which it is), and not on it
>  > being a buffer that is displayed temporarily in its own frame.
>  >
>  > The latter distinction is I think the right one, and which 
>  > would be good to handle.  That is where MS Windows's
>  > automatic focusing leads to a problem.
>  >
>  > The problematic case is (a) standalone minibuffer (b) 
>  > popped-up buffer in its own frame, (c) that frame being
>  > new, and (d) the OS giving the new frame the input focus.
> 
> You still have to tell me how to remove that frame when you're done.

The informational frame?  I'd vote for `delete-frame', at least for my own use.
We might want to provide ways for the caller and/or the user to control both
what to do with the frame/window and what to do with the buffer.  But maybe
`frame-auto-hide-function' would make sense here?

Anyway, let's talk about this later.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 >>  > Something like this:
 >>  > (with-unfocused-buffer-displayed BUFFER &body BODY)
 >>  >
 >>  > where BUFFER is displayed for information only, and where
 >>  > BODY would include the call(s) that read from the minibuffer.
 >>  >
 >>  > The current buffer would remain what it was beforehand,
 >>  > and _if_ BUFFER gets displayed in its own frame and _if_
 >>  > there is a standalone minibuffer frame, _then_ the focus
 >>  > for BUFFER's frame gets automatically redirected to the
 >>  > minibuffer frame.
 >>
 >> In my experience, this requirement is met if the construct requests
 >> input with BUFFER's window temporarily selected and BUFFER
 >> temporarily current.  Or am I missing something?
 >
 > Sorry, I don't know what that means.  Perhaps give an example of what you mean
 > by temporarily selected and current?

Temporarily selected means selected via `with-selected-window' and
temporarily current means `with-current-buffer'.

 >>  > handling needed - the construct can essentially be a no-op
 >>  > in that case (AFAICT).
 >>  >
 >>  > How something like this would be implemented I'm not sure.
 >>  > When the redirection would need to take place, to DTRT,
 >>  > I'm not sure.  Perhaps it would need to be done more than once.
 >>  >
 >>  > But an important further requirement is that nothing
 >>  > should prevent Emacs code in BODY or called from within
 >>  > BODY from switching the input focus to BUFFER's frame.
 >>
 >> I don't understand what BODY should contain.  Would this macro be
 >> responsible for displaying BUFFER?
 >
 > No, not as I was conceiving it.  I suppose that would be a possibility, but I
 > expect it is better to keep buffer display out of it.  That's why I said things
 > like "_if_ BUFFER gets displayed in its own frame".
 >
 > What I had in mind was that the macro would be responsible only for making sure
 > that minibuffer input gets (re-)directed to the minibuffer frame.  And that goes
 > for any code in BODY, including code that might pop up BUFFER.
 >
 > IOW, display of BUFFER would come (if it came) from BODY.
 >
 > But again, I'm just thinking out loud.  And it's probable that you see things
 > that I do not.

No.  Just that I don't have the slightest idea how to write a macro that
modifies the behavior of a `yes-or-no-p' dialog it calls.  read_minibuf
and the code for handling keyboard events do the redirecting.

 >>  > Likewise, nothing should prevent the user from explicitly
 >>  > switching the focus to BUFFER's frame.
 >>
 >> This is part of the `yes-or-no-p' dialog, nothing within the scope
 >> of the construct you propose.
 >
 > Can you elaborate?  I don't follow.

IIUC you want to modify the behavior of `yes-or-no-p' to redirect frame
focus in your sense.

 > No.  Again, during reading from the minibuffer it is quite possible for a user
 > to interact with other buffers and their frames.  I gave the example of
 > *Completions*.  The user can hit a key or use the mouse to change the input
 > focus temporarily to another frame - any frame.
 >
 > When the user does that s?he is executing code within BODY.  It is code that
 > reads from the minibuffer, but also code that implements any commands bound to
 > keys or mouse actions that the user uses during that minibuffer dialog.  That's
 > all I meant.

I'm afraid this gets too complicated for me.  You have to find someone
who understands such scenarios better than me.

 >>  > I do not expect that the problematic use case we've been
 >>  > discussing can be detected and dealt with correctly in an
 >>  > automatic way.  If the programmer intention
 >>
 >> Who is the programmer here?
 >
 > The person who writes the code that reads from the minibuffer, code that might
 > or might not be wrapped in the new macro, i.e., that might or might not want to
 > stipulate that BUFFER is not to receive the input focus.

The person who writes that code expects `yes-or-no-p' DTRT.

 >> I refer to the case where a minibuffer-equipped frame is popped up.
 >
 > I'd rather you didn't.  Let's not bring in new things.

Users with non-nil `pop-up-frames' who don't use minibuffer-only frames
do get a minibuffer-equipped frame popped up.  You can ignore them, I
can't.  And a user who excludes BUFFER from the list of specially
displayed buffers does a perfectly valid thing and can expect Emacs to
handle it as it currently does.

 > I don't know.  The only problems I am aware of for `w-t-b-w.el' are these:
 >
 > 1. Loss of special-displayness (a separate problem, but important if we're
 > talking about `w-t-b-w.el' as it stands now).
 >
 > 2. The fact that it limits itself to display of temporary buffers, whereas the
 > actual problem has to do with the temporary display of buffers.

Because I can safely kill a temporary buffer and remove its frame when
I'm done with the dialog.

 > And as far as you know, is the fact that the minibuffer frame is still used (as
 > it should be) due only to the fact that `yes-or-no-p' is used, or can I expect
 > that the minibuffer frame will be used in general?

Due to the fact that `yes-or-no-p' is called in a special way - with the
new window selected.

 >>  >> `with-temp-buffer-window' avoids that by asking the
 >>  >> `yes-or-no-p' question in the new frame.
 >
 > Dunno why I (or was it you?) said that.  I see the question in the minibuffer
 > frame, not the new frame.  Which is TRT.

To "see the question in the minibuffer frame" I ask it in the new frame.

 > Yes, it is more restrictive than the actual problem encountered.  As I said, it
 > might suffice in practice, but there is nothing in the problem description that
 > requires that the buffer itself be temporary.

I have to kill the buffer to remove the frame.  And I have to remove the
frame because you complained that `save-window-excursion' cannot remove
a popped up frame.  And I can't kill a non-temporary buffer.

 >> The invoking code does not care.  It expects `display-buffer' and
 >> `yes-or-no-p' to take care of this.
 >
 > In the general case it is not `yes-or-no-p'.

It can do anything that reads from the minibuffer.

 > The informational frame?  I'd vote for `delete-frame', at least for my own use.
 > We might want to provide ways for the caller and/or the user to control both
 > what to do with the frame/window and what to do with the buffer.  But maybe
 > `frame-auto-hide-function' would make sense here?

If we use `frame-auto-hide-function', the caller does not have to kill
the buffer and there's no need to make this construct work for temporary
buffers only.

 > Anyway, let's talk about this later.

It's your choice.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

>  >>  > Something like this:
>  >>  > (with-unfocused-buffer-displayed BUFFER &body BODY)
>  >>  >
>  >>  > where BUFFER is displayed for information only, and where
>  >>  > BODY would include the call(s) that read from the minibuffer.
>  >>  >
>  >>  > The current buffer would remain what it was beforehand,
>  >>  > and _if_ BUFFER gets displayed in its own frame and _if_
>  >>  > there is a standalone minibuffer frame, _then_ the focus
>  >>  > for BUFFER's frame gets automatically redirected to the
>  >>  > minibuffer frame.
>  >>
>  >> In my experience, this requirement is met if the construct requests
>  >> input with BUFFER's window temporarily selected and BUFFER
>  >> temporarily current.  Or am I missing something?
>  >
>  > Sorry, I don't know what that means.  Perhaps give an 
>  > example of what you mean by temporarily selected and current?
> 
> Temporarily selected means selected via `with-selected-window' and
> temporarily current means `with-current-buffer'.

OK, but I still don't see what you are trying to say, or why.

You seem to be saying that if BUFFER is selected/current, and if input is read
somewhere (where?) - then what?  The focus gets automatically redirected to the
minibuffer frame?

This is not about reading input with BUFFER selected/current.  The idea is to
have the _previously_ selected buffer be selected/current, while input is read
from the minibuffer.  The idea is not to make BUFFER selected/current, but just
to display it.

Beyond that, that sentence of mine was shorthand.  It (apparently) is not enough
that the focus be redirected once, at some point, to the minibuffer frame.  It
needs to either remain there (somehow preventing MS Windows from moving it away)
or be put back there (after MS Windows moves it to BUFFER's frame).  IOW, even
if redirection is happening now as it should, it is not sufficient if, after
that redirection to the minibuffer, the OS changes the focus again (to the new
frame).

>  >>  > handling needed - the construct can essentially be a no-op
>  >>  > in that case (AFAICT).
>  >>  >
>  >>  > How something like this would be implemented I'm not sure.
>  >>  > When the redirection would need to take place, to DTRT,
>  >>  > I'm not sure.  Perhaps it would need to be done more than once.
>  >>  >
>  >>  > But an important further requirement is that nothing
>  >>  > should prevent Emacs code in BODY or called from within
>  >>  > BODY from switching the input focus to BUFFER's frame.
>  >>
>  >> I don't understand what BODY should contain.  Would this macro be
>  >> responsible for displaying BUFFER?
>  >
>  > No, not as I was conceiving it.  I suppose that would be a 
>  > possibility, but I expect it is better to keep buffer display out of it.  
>  > That's why I said things like "_if_ BUFFER gets displayed in its own
frame".
>  >
>  > What I had in mind was that the macro would be responsible 
>  > only for making sure that minibuffer input gets (re-)directed to the
>  > minibuffer frame.  And that goes for any code in BODY, including code
>  > that might pop up BUFFER.
>  >
>  > IOW, display of BUFFER would come (if it came) from BODY.
>  >
>  > But again, I'm just thinking out loud.  And it's probable 
>  > that you see things that I do not.
> 
> No.  Just that I don't have the slightest idea how to write a 
> macro that modifies the behavior of a `yes-or-no-p' dialog it calls.  
> read_minibuf and the code for handling keyboard events do the redirecting.
> 
>  >>  > Likewise, nothing should prevent the user from explicitly
>  >>  > switching the focus to BUFFER's frame.
>  >>
>  >> This is part of the `yes-or-no-p' dialog, nothing within the scope
>  >> of the construct you propose.
>  >
>  > Can you elaborate?  I don't follow.
> 
> IIUC you want to modify the behavior of `yes-or-no-p' to 
> redirect frame focus in your sense.

I don't know why you mention `yes-or-no-p'.  This is about reading from the
minibuffer, in general.

I don't want or not want to modify `yes-or-no-p' or `read-from-minibuffer'.  I'm
just saying that if the problem is that we want to display BUFFER, and it gets
displayed in a new frame, and we want to read from the minibuffer, then we do
not want, for that minibuffer reading, the input focus to be in BUFFER's frame.

I spoke of redirecting, but it might take more than that or doing that more than
once, if the OS switches focus after redirection to the minibuffer.

>  > No.  Again, during reading from the minibuffer it is quite 
>  > possible for a user to interact with other buffers and their frames.
>  > I gave the example of *Completions*.  The user can hit a key or use
>  > the mouse to change the input focus temporarily to another frame -
>  > any frame.
>  >
>  > When the user does that s?he is executing code within 
>  > BODY.  It is code that reads from the minibuffer, but also code
>  > that implements any commands bound to keys or mouse actions that
>  > the user uses during that minibuffer dialog.  That's
>  > all I meant.
> 
> I'm afraid this gets too complicated for me.  You have to find someone
> who understands such scenarios better than me.

The scenario is as simple as your clicking a special-display (hence dedicated,
separate frame) *Completions* frame during minibuffer input.  That changes the
focus to *Completions*.  But that doesn't mean that you cannot switch back to
the minibuffer frame again.

The only point here is that whatever is done to fix the problem should not in
any way prevent a user from clicking *Completions* and thus switching the focus
there.

Or any other frame, besides *Completions*.  You should be able to click another
frame, type some text there, then click the minibuffer frame and finish entering
the input text it wants to read.  IOW, minibuffer interaction is not modal; it
does not (should not) prevent you from interacting with other parts of Emacs,
including typing into other frames.

This was in response to your statement that we wanted to _always_ have the focus
on the minibuffer frame.  Yes, when reading from the minibuffer is initiated,
the minibuffer frame should get the focus.  But the user (or Emacs) should not
be prevented from switching the focus to another frame.

All that we are trying to prevent or remedy is the focus switching to another
(new) frame by the OS.  We should not be preventing either Emacs or the user
from switching focus to another frame, just because the minibuffer is active.

That is the only point I was trying to make here.

>  >>  > I do not expect that the problematic use case we've been
>  >>  > discussing can be detected and dealt with correctly in an
>  >>  > automatic way.  If the programmer intention
>  >>
>  >> Who is the programmer here?
>  >
>  > The person who writes the code that reads from the minibuffer,
>  > code that might or might not be wrapped in the new macro, i.e.,
>  > that might or might not want to stipulate that BUFFER is not to
>  > receive the input focus.
> 
> The person who writes that code expects `yes-or-no-p' DTRT.

Agreed.

>  >> I refer to the case where a minibuffer-equipped frame is 
>  >> popped up.
>  >
>  > I'd rather you didn't.  Let's not bring in new things.
> 
> Users with non-nil `pop-up-frames' who don't use minibuffer-only
> frames do get a minibuffer-equipped frame popped up.

Of course they do.  But is there a problem for them?  Has any problem similar to
the one reported for this bug been identified for those different use cases?

This bug is about a problem that arises (with MS Windows) when you do have a
standalone minibuffer frame.  That's all.

> You can ignore them, I can't.

No one is asking you to ignore them.  If you see a related problem for other use
cases, by all means, try to address that problem at the same time.  I have not
heard of such a problem, so to me bringing up that use case seems irrelevant.

I care about _this_ bug being fixed.  But that does not mean that I want to
prevent you from fixing other bugs.  I haven't heard of any such problem without
a standalone minibuffer, however.

> And a user who excludes BUFFER from the list of specially
> displayed buffers does a perfectly valid thing and can expect Emacs to
> handle it as it currently does.

OK by me.  I have no argument against that.  I don't see how it's related, but
it's fine by me.

>  > I don't know.  The only problems I am aware of for 
>  > `w-t-b-w.el' are these:
>  >
>  > 1. Loss of special-displayness (a separate problem, but 
>  > important if we're talking about `w-t-b-w.el' as it stands now).
>  >
>  > 2. The fact that it limits itself to display of temporary 
>  > buffers, whereas the actual problem has to do with the temporary
>  > display of buffers.
> 
> Because I can safely kill a temporary buffer and remove its frame when
> I'm done with the dialog.

OK.  I've already agreed that that is a good thing.  I'm in favor of your
proposed fix.

I was just pointing out that there can be cases of MS Windows messing things up
that your fix won't solve, namely, temporary display of a non-temporary buffer,
a buffer that you do not want input to be focused to.

>  > And as far as you know, is the fact that the minibuffer 
>  > frame is still used (as it should be) due only to the fact that
>  > `yes-or-no-p' is used, or can I expect
>  > that the minibuffer frame will be used in general?
> 
> Due to the fact that `yes-or-no-p' is called in a special way 
> - with the new window selected.
> 
>  >>  >> `with-temp-buffer-window' avoids that by asking the
>  >>  >> `yes-or-no-p' question in the new frame.
>  >
>  > Dunno why I (or was it you?) said that.  I see the 
>  > question in the minibuffer frame, not the new frame.
>  > Which is TRT.
> 
> To "see the question in the minibuffer frame" I ask it in the 
> new frame.

OK.  That was worth clarifying.  I wasn't understanding that.  I see the
question in the minibuffer frame, and I type the answer there.  My impression
was that the minibuffer frame had the focus.

I did not know where you were asking the question.  By that, I assume you mean
that the new frame is selected (and has the focus?) when you invoke
`yes-or-no-p'.  Is that right?

Just for my info, why does it matter where `yes-or-no-p' is invoked?  _Should_
it matter, or is it just a fact that we must live with that it does matter?

>  > Yes, it is more restrictive than the actual problem encountered.
>  > As I said, it might suffice in practice, but there is nothing in the 
>  > problem description that requires that the buffer itself be temporary.
> 
> I have to kill the buffer to remove the frame.

I don't understand why, but probably I don't need to understand everything.  Why
doesn't `delete-frame' do what you need?

> And I have to remove the frame because you complained that
> `save-window-excursion' cannot remove a popped up frame.

Hm.  I don't recall that at all, but I believe you that I did.  Was that in some
other thread?

> And I can't kill a non-temporary buffer.

>  > The informational frame?  I'd vote for `delete-frame', at 
>  > least for my own use.  We might want to provide ways for the
>  > caller and/or the user to control both what to do with the
>  > frame/window and what to do with the buffer.  But maybe
>  > `frame-auto-hide-function' would make sense here?
> 
> If we use `frame-auto-hide-function', the caller does not have to kill
> the buffer and there's no need to make this construct work 
> for temporary buffers only.

That sounds good to me.  Perhaps I'm missing something.  I don't want to steer
you down the wrong path, but what you say here sounds good to me.

If the more general case can be handled, then the more restrictive case
(temporary buffer, not just temporary display) could presumably be handled also,
as a subcase, no?  Or even if not as a subcase, as a separate case.

IOW, if possible it would be good to have both possibilities, so a programmer
could get the right behavior for a given context: If s?he wants that buffer to
be temporary, then call a construct that treats it as such (killing it).  If
s?he wants that buffer not to be temporary and only its display to be temporary
then call a construct that does that instead.

>  > Anyway, let's talk about this later.
> 
> It's your choice.

Can we have both possibilities?

If not, let's get the temporary-buffer one first.  IOW, I think you have that
case almost nailed - there is just the special-display/dedicatedness that does
not work yet.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 > You seem to be saying that if BUFFER is selected/current, and if input is read
 > somewhere (where?) - then what?  The focus gets automatically redirected to the
 > minibuffer frame?

A BUFFER is not selected, only a window or a frame is.  I say that when
a window on a minibuffer-less frame is selected and its buffer is
current at the time a `yes-or-no-p' question is asked, focus for reading
input from the minibuffer gets redirected to a minibuffer-equipped
frame.

 > This is not about reading input with BUFFER selected/current.  The idea is to
 > have the _previously_ selected buffer be selected/current, while input is read
 > from the minibuffer.  The idea is not to make BUFFER selected/current, but just
 > to display it.

I don't talk about ideas.  I talk about the current implementation of
dialogs that read text from the minibuffer.

 > Beyond that, that sentence of mine was shorthand.  It (apparently) is not enough
 > that the focus be redirected once, at some point, to the minibuffer frame.  It
 > needs to either remain there (somehow preventing MS Windows from moving it away)
 > or be put back there (after MS Windows moves it to BUFFER's frame).

Focus redirection is done by Emacs.  MS Windows won't redirect focus.

 > IOW, even
 > if redirection is happening now as it should, it is not sufficient if, after
 > that redirection to the minibuffer, the OS changes the focus again (to the new
 > frame).

Any redirection is permanent for a frame until it's explicitly changed
by Emacs.

 >> IIUC you want to modify the behavior of `yes-or-no-p' to
 >> redirect frame focus in your sense.
 >
 > I don't know why you mention `yes-or-no-p'.  This is about reading from the
 > minibuffer, in general.
 >
 > I don't want or not want to modify `yes-or-no-p' or `read-from-minibuffer'.  I'm
 > just saying that if the problem is that we want to display BUFFER, and it gets
 > displayed in a new frame, and we want to read from the minibuffer, then we do
 > not want, for that minibuffer reading, the input focus to be in BUFFER's frame.

Above you say that

 > It (apparently) is not enough
 > that the focus be redirected once, at some point, to the minibuffer frame.

so you want to modify `yes-or-no-p' or `read-from-minibuffer'.

 > Yes, when reading from the minibuffer is initiated,
 > the minibuffer frame should get the focus.  But the user (or Emacs) should not
 > be prevented from switching the focus to another frame.
 >
 > All that we are trying to prevent or remedy is the focus switching to another
 > (new) frame by the OS.  We should not be preventing either Emacs or the user
 > from switching focus to another frame, just because the minibuffer is active.
 >
 > That is the only point I was trying to make here.

And my point is that beyond the initial redirection the mechanism
reading keyboard events is responsible for providing such behavior.

 > I did not know where you were asking the question.  By that, I assume you mean
 > that the new frame is selected (and has the focus?) when you invoke
 > `yes-or-no-p'.  Is that right?

I temporarily select the new frame when I invoke `yes-or-no-p'.  The new
frame will be selected again by `handle-switch-frame' if and when Emacs
is notified by the OS.

 > Just for my info, why does it matter where `yes-or-no-p' is invoked?  _Should_
 > it matter, or is it just a fact that we must live with that it does matter?

It does matter if and when the selected frame does not have a minibuffer
and I want to redirect focus to a minibuffer frame.

 >>  > Yes, it is more restrictive than the actual problem encountered.
 >>  > As I said, it might suffice in practice, but there is nothing in the
 >>  > problem description that requires that the buffer itself be temporary.
 >>
 >> I have to kill the buffer to remove the frame.
 >
 > I don't understand why, but probably I don't need to understand everything.  Why
 > doesn't `delete-frame' do what you need?

Because the window is "quit" when the user is done with the dialog.
`quit-window' deletes the frame only if the buffer is killed or
`frame-auto-hide-function' takes over.

 >> And I have to remove the frame because you complained that
 >> `save-window-excursion' cannot remove a popped up frame.
 >
 > Hm.  I don't recall that at all, but I believe you that I did.  Was that in some
 > other thread?

In the thread on the behavior of `dired-mark-pop-up' IIRC.

 >> If we use `frame-auto-hide-function', the caller does not have to kill
 >> the buffer and there's no need to make this construct work
 >> for temporary buffers only.
 >
 > That sounds good to me.  Perhaps I'm missing something.  I don't want to steer
 > you down the wrong path, but what you say here sounds good to me.
 >
 > If the more general case can be handled, then the more restrictive case
 > (temporary buffer, not just temporary display) could presumably be handled also,
 > as a subcase, no?  Or even if not as a subcase, as a separate case.
 >
 > IOW, if possible it would be good to have both possibilities, so a programmer
 > could get the right behavior for a given context: If s?he wants that buffer to
 > be temporary, then call a construct that treats it as such (killing it).  If
 > s?he wants that buffer not to be temporary and only its display to be temporary
 > then call a construct that does that instead.
 >
 >>  > Anyway, let's talk about this later.
 >>
 >> It's your choice.
 >
 > Can we have both possibilities?
 >
 > If not, let's get the temporary-buffer one first.  IOW, I think you have that
 > case almost nailed - there is just the special-display/dedicatedness that does
 > not work yet.

Then have a look at what happens there.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

>  >>  > there is nothing in the problem description that
>  >>  > requires that the buffer itself be temporary.
>  >>
>  >> I have to kill the buffer to remove the frame.
>  >
>  > Why doesn't `delete-frame' do what you need?
> 
> Because the window is "quit" when the user is done with the dialog.
> `quit-window' deletes the frame only if the buffer is killed or
> `frame-auto-hide-function' takes over.

You don't say why `delete-frame' would not do what you need.  You say that
`quit-window' needs to have the buffer killed (or ... `f-a-h-f'...) for it to
delete the frame.

What requires you to use `quit-window' and not `delete-frame'?  Just asking, to
understand.

>  > Can we have both possibilities?
>  >
>  > If not, let's get the temporary-buffer one first.  IOW, I 
>  > think you have that case almost nailed - there is just the 
>  > special-display/dedicatedness that does not work yet.
> 
> Then have a look at what happens there.

I don't know what you are requesting.  What else do you want me to do?

I tried your code and reported on it.  I will try it more if the breaking of
special-display buffers (non-dedicated windows) is fixed.  That is the only
problem with it that I have encountered so far.  But that prevents me from
really using it more to see if there are other problems.

Can you fix that problem?  Is there something more that you would like me to
check, which would help you understand that problem?

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

> What requires you to use `quit-window' and not `delete-frame'?  Just asking, to
> understand.

I cannot use `delete-frame' because there might be other windows on the
frame or because this might be the only visible frame.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

> > What requires you to use `quit-window' and not 
> > `delete-frame'?  Just asking, to understand.
> 
> I cannot use `delete-frame' because there might be other 
> windows on the frame or because this might be the only visible frame.

But those conditions can be tested, no?

IOW, it seems to me that if we are talking about a situation where the buffer is
to be kept but its display is to be removed, there are ways of doing that.

You will no doubt find better ways to do it (e.g., at least a different test
from `one-window-p'), but FWIW I use code like the following, depending on the
context:

1.
(if (one-window-p t) (delete-frame) (delete-window))

2.
(if (and (one-window-p t)  (cdr (visible-frame-list)))
    (delete-frame) ; Sole window but not sole visible frame.
  (delete-window (selected-window)))

3.
(defun browse-kill-ring-quit-deletes-window/frame ()
  "Bury buffer.  Delete window or, if dedicated, frame.
Useful as customized value of `browse-kill-ring-quit-action'."
  (let ((buf            (current-buffer))
        (sole-window-p  (eq (selected-window) (frame-root-window))))
    (cond ((and sole-window-p (window-dedicated-p (selected-window)))
           (delete-frame)
           (bury-buffer buf))
          (t
           (unless sole-window-p (delete-window))
           ;; Avoid BUF as explicit arg to `bury-buffer',
           ;; since we want to undisplay it.
           (with-current-buffer buf (bury-buffer))))))

4.
(save-window-excursion 
  (pop-to-buffer list-buf)
  (condition-case nil ; Ignore error if user deleted window.
      (if (one-window-p) (delete-frame) (delete-window))
    (error nil))
  (if list-was-shown
      (bury-buffer list-buf)
    (kill-buffer list-buf)))

5.
(unwind-protect
     (save-window-excursion
       (dired-pop-to-buffer bufname)
       (setq result  (apply function args)))
  (save-excursion
    (condition-case nil
        (progn
          (select-window (get-buffer-window bufname 0))
          (if (one-window-p) (delete-frame) (delete-window)))
      (error nil)))
  (bury-buffer bufname))

6.
(or (fboundp 'old-delete-window)
    (fset 'old-delete-window (symbol-function 'delete-window)))

(defun delete-window (&optional window)
  "Remove WINDOW from the display.  Default is `selected-window'.
If WINDOW is the only one in its frame, then `delete-frame' too."
  (interactive)
  (save-current-buffer
    (setq window (or window (selected-window)))
    (select-window window)
    (if (one-window-p t)
        (delete-frame)
      (old-delete-window (selected-window)))))

7.
(defun delete/iconify-window (&optional window frame-p)
  "Delete or iconify WINDOW (default: `selected-window').
If WINDOW is the only one in its frame (`one-window-p'), then optional
arg FRAME-P determines the behavior regarding the frame, as follows:
  If FRAME-P is nil, then the frame is deleted (with the window).
  If FRAME-P is t, then the frame is iconified.
  If FRAME-P is a symbol naming a function, the function is applied
             to WINDOW as its only arg.
             If the result is nil, then the frame is deleted.
             If the result is non-nil, then the frame is iconified.
  If FRAME-P is anything else, then behavior is as if FRAME-P were the
             symbol `window-dedicated-p': the frame is iconified if
             WINDOW is dedicated, otherwise the frame is deleted.

Interactively, FRAME-P depends on the prefix arg, as follows:
  Without a prefix arg (prefix = nil), FRAME-P is `window-dedicated-p'.
  With prefix arg < 0, FRAME-P is t.  The frame is iconified.
  With prefix arg >= 0, FRAME-P is nil.  The frame is deleted."
  (interactive
   (list nil (if current-prefix-arg
                 (not (natnump (prefix-numeric-value
                                current-prefix-arg)))
               'window-dedicated-p)))
  (setq window (or window (selected-window)))
  (let ((one-win-p t))
    (save-window-excursion
      (select-window window)
      (if (one-window-p)
          (if frame-p
              (if (eq t frame-p)
                  (iconify-frame)
                (unless (and (symbolp frame-p)
                             (fboundp frame-p))
                  (setq frame-p 'window-dedicated-p))
                (if (funcall frame-p window)
                    (iconify-frame)
                  (delete-frame)))
            (delete-frame))    ; Default.
        (setq one-win-p nil)))
    ;; Do this outside `save-window-excursion'.
    (unless one-win-p (old-delete-window window))))

8.
(defun delete-1-window-frames-on (buffer)
  "Delete all visible 1-window frames showing BUFFER."
  (interactive
   (list (read-buffer 
          "Delete visible 1-window frames showing buffer: "
          (current-buffer) 'EXISTING)))
  (setq buffer  (get-buffer buffer))
  (save-excursion
    (when (buffer-live-p buffer)        ; Do nothing if dead buffer.
      ;; Better to search frames or `get-buffer-window-list'?
      (dolist (fr  (filtered-frame-list 
                    `(lambda (fr) (get-buffer-window ',buffer))))
        (save-window-excursion
          (select-frame fr)
          (when (one-window-p t fr) (delete-frame)))))))

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[martin rudalics]

 > You will no doubt find better ways to do it (e.g., at least a different test
 > from `one-window-p'), but FWIW I use code like the following, depending on the
 > context:

None of these is suitable for dealing with the case that a window has
been reused by `display-buffer'.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes'

[Drew Adams]

>  >> I cannot use `delete-frame' because there might be other 
>  >> windows on the frame or because this might be the only
>  >> visible frame.
>  >
>  > You will no doubt find better ways to do it (e.g., at least
>  > a different test from `one-window-p'), but FWIW I use code
>  > like the following, depending on the context:
> 
> None of these is suitable for dealing with the case that a window has
> been reused by `display-buffer'.

Perhaps.  But they are all useful in practice to distinguish the one-window
case, at least with my setup.  IOW, they do the job for me - I have not had any
problems with them.

I'm afraid I can't offer another suggestion for this particular problem.  You
are the expert here.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > Program received signal SIGSEGV, Segmentation fault.
 > [Switching to thread 420.0x1468]
 > 0x01102012 in ?? ()
 > (gdb) thread apply all bt full
 >
 > Thread 2 (thread 420.0x14c4):
 > #0  0x7c90e514 in ntdll!LdrAccessResource ()
 > No symbol table info available.
 > #1  0x7e4191be in USER32!GetProcessWindowStation ()
 > No symbol table info available.
 > #2  0x7e42776b in USER32!GetMessageA ()
 > No symbol table info available.
 > #3  0x723dfee0 in ?? ()
 > No symbol table info available.
 >
 > Thread 1 (thread 420.0x1468):
 > #0  0x01102012 in ?? ()
 > No symbol table info available.
 > (gdb)

I'm lost here.  Did you type "gdb -p PID" from the directory where your
.gdbinit resides?

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> I'm lost here.  Did you type "gdb -p PID" from the directory 
> where your .gdbinit resides?

Yes.  I did everything from that directory.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 >>  > 1. When I do C-x C-c, and respond to the yes/no question,
 >>  > it seems I must wait a tiny bit before typing yes/no.
 >>  > Otherwise, the first char (e.g. `y') is lost, so
 >>  > I end up with just `es' (I see the `y' nowhere).  Not a
 >>  > big deal; just FYI.
 >>
 >> Does this happen _only_ with your code or also in the emacs
 >> -Q scenarios _without_ your code?  What happens with a
 >> `y-or-no-p' defalias?
 >
 > Not sure what you mean.  There is no equivalent in the emacs -Q tests you asked
 > me to do.  There is nothing on post-command-hook etc.

So the delay is due to processing `post-command-hook'?

 >> That's a bad idea in my opinion.  Redirect as soon as possible.  Why
 >> don't you use `after-make-frame-functions'?
 >
 > I'm not sure what you mean.  I tried this:
 >
 > 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'.
 >
 > 2. Put back the guard (eq last-event-frame (window-frame (minibuffer-window)))
 > at the beginning of `1on1-fit-minibuffer-frame' (so it is a no-op otherwise).
 >
 > 3. Defined this and added it to `after-make-frame-functions':
 >
 > (defun 1on1-redirect-to-minibuffer (new-frame)
 >   "..."
 >   (when (and 1on1-fit-minibuffer-frame-flag
 >              (active-minibuffer-window)
 >              (save-selected-window
 >                (select-window (minibuffer-window))
 >                (one-window-p nil 'selected-frame)))
 >     (redirect-frame-focus
 >       new-frame
 >       (window-frame (minibuffer-window)))))
 >
 > That did not help at all.  The original symptoms returned (typing yes/no did not
 > go to the minibuffer etc.).

Here (Emacs 24.1 release because trunk crashes to frequently these days)
I can do something like

(progn
;;  (setq minibuffer-auto-raise t)
;;  (setq pop-up-frame-function (lambda () (make-frame '((minibuffer . nil)))))
   (setq pop-up-frames t)
   (add-hook 'after-make-frame-functions
	    #'(lambda (frame)
		(redirect-frame-focus frame frame)))
   (shell))

where the two forms in comments are optional.  In all cases, focus is
redirected appropriately after C-x C-c (although I think that when the
new frame does have a minibuffer window, no redirection should be done
at all and the prompt should appear in the new frame - but it seems
difficult to get that right).  And obviously things look better with
`minibuffer-auto-raise' non-nil.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  >>  > 1. When I do C-x C-c, and respond to the yes/no question,
>  >>  > it seems I must wait a tiny bit before typing yes/no.
>  >>  > Otherwise, the first char (e.g. `y') is lost, so
>  >>  > I end up with just `es' (I see the `y' nowhere).  Not a
>  >>  > big deal; just FYI.
>  >>
>  >> Does this happen _only_ with your code or also in the emacs
>  >> -Q scenarios _without_ your code?  What happens with a
>  >> `y-or-no-p' defalias?
>  >
>  > Not sure what you mean.  There is no equivalent in the 
>  > emacs -Q tests you asked me to do.  There is nothing on
>  > post-command-hook etc.
> 
> So the delay is due to processing `post-command-hook'?

Is that a question or an answer? ;-)

If it is a question, I don't have the answer.  I can only report the symptom:
the first char is seemingly lost (does not show up in the minibuffer, at least,
and I have not seen it anywhere else).

As I said, this is not a big deal.  I mention it FYI.

>  >> That's a bad idea in my opinion.  Redirect as soon as 
>  >> possible.  Why don't you use `after-make-frame-functions'?
>  >
>  > I'm not sure what you mean.  I tried this:
>  >
>  > 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'.
>  >
>  > 2. Put back the guard (eq last-event-frame (window-frame 
>  > (minibuffer-window))) at the beginning of `1on1-fit-minibuffer-frame'
>  > (so it is a no-op otherwise).
>  >
>  > 3. Defined this and added it to `after-make-frame-functions':
>  >
>  > (defun 1on1-redirect-to-minibuffer (new-frame)
>  >   "..."
>  >   (when (and 1on1-fit-minibuffer-frame-flag
>  >              (active-minibuffer-window)
>  >              (save-selected-window
>  >                (select-window (minibuffer-window))
>  >                (one-window-p nil 'selected-frame)))
>  >     (redirect-frame-focus
>  >       new-frame
>  >       (window-frame (minibuffer-window)))))
>  >
>  > That did not help at all.  The original symptoms returned 
>  > (typing yes/no did not go to the minibuffer etc.).
> 
> Here (Emacs 24.1 release because trunk crashes to frequently 
> these days) I can do something like
> 
> (progn
> ;;  (setq minibuffer-auto-raise t)
> ;;  (setq pop-up-frame-function
> ;;        (lambda () (make-frame '((minibuffer . nil)))))
>    (setq pop-up-frames t)
>    (add-hook 'after-make-frame-functions
> 	    #'(lambda (frame)
> 		(redirect-frame-focus frame frame)))
>    (shell))
> 
> where the two forms in comments are optional.  In all cases, focus is
> redirected appropriately after C-x C-c (although I think that when the
> new frame does have a minibuffer window, no redirection should be done
> at all and the prompt should appear in the new frame - but it seems
> difficult to get that right).  And obviously things look better with
> `minibuffer-auto-raise' non-nil.

Yes, if I try that with emacs -Q then it does what you say (with Emacs 24.1 and
later).

And uncommenting those two lines also behaves as I think you intend.  In both
cases, the question is posed, and the response is accepted, in the minibuffer of
frame *shell* (i.e., not the minibuffer of frame *Process List* in the case
where it has one).

But if *Process List* has no minibuffer (uncommented test case), and it is
selected (e.g., later, manually, after replying "no" once) when you hit `C-x
C-c' (i.e., the second `C-x C-c'), then frame *shell* is raised and receives the
input, even though there is nothing on that frame that the user needs to see
(apart from the question/answer).

It is better, IMO, for the question/response to be in frame *Process List*, as
we discussed earlier.  (This is all for the case where there is no standalone
minibuffer frame.)

The reason I provided the description I did was that I thought we were talking
about my setup with a standalone minibuffer frame.  See my previous description
(quoted above) for what happens in that context.  For that context, your
suggestion of using `after-make-frame-functions', as I understood it, did not
help.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 >> (progn
 >> ;;  (setq minibuffer-auto-raise t)
 >> ;;  (setq pop-up-frame-function
 >> ;;        (lambda () (make-frame '((minibuffer . nil)))))
 >>    (setq pop-up-frames t)
 >>    (add-hook 'after-make-frame-functions
 >> 	    #'(lambda (frame)
 >> 		(redirect-frame-focus frame frame)))
 >>    (shell))
 >>
 >> where the two forms in comments are optional.  In all cases, focus is
 >> redirected appropriately after C-x C-c (although I think that when the
 >> new frame does have a minibuffer window, no redirection should be done
 >> at all and the prompt should appear in the new frame - but it seems
 >> difficult to get that right).  And obviously things look better with
 >> `minibuffer-auto-raise' non-nil.
 >
 > Yes, if I try that with emacs -Q then it does what you say (with Emacs 24.1 and
 > later).
 >
 > And uncommenting those two lines also behaves as I think you intend.  In both
 > cases, the question is posed, and the response is accepted, in the minibuffer of
 > frame *shell* (i.e., not the minibuffer of frame *Process List* in the case
 > where it has one).
 >
 > But if *Process List* has no minibuffer (uncommented test case), and it is
 > selected (e.g., later, manually, after replying "no" once) when you hit `C-x
 > C-c' (i.e., the second `C-x C-c'), then frame *shell* is raised and receives the
 > input, even though there is nothing on that frame that the user needs to see
 > (apart from the question/answer).

This is probably the case where a window on another frame is reused
before asking the `yes-or-no-p' question.  This should be easier to
handle because the window manager supposedly won't focus that frame.

In any case I think a `yes-or-no-p' question should terminate by
killing the *Process List* buffer to avoid such confusion.

 > It is better, IMO, for the question/response to be in frame *Process List*, as
 > we discussed earlier.  (This is all for the case where there is no standalone
 > minibuffer frame.)

I think so too.

 > The reason I provided the description I did was that I thought we were talking
 > about my setup with a standalone minibuffer frame.  See my previous description
 > (quoted above) for what happens in that context.  For that context, your
 > suggestion of using `after-make-frame-functions', as I understood it, did not
 > help.

What precisely is the problem with it?

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  > The reason I provided the description I did was that I 
>  > thought we were talking about my setup with a standalone
>  > minibuffer frame.  See my previous description
>  > (quoted above) for what happens in that context.  For that 
>  > context, your suggestion of using `after-make-frame-functions',
>  > as I understood it, did not help.
> 
> What precisely is the problem with it?

(As I said, it was quoted above.)  Here again is what I reported (2012-07-22)
after that test:

> > > Anyway, it seems we are very close, for my needs.  I suppose I
> > > can put that redirection on `post-command-hook' (instead of in
> > > `1on1-fit-minibuffer-frame', which some oneonone.el users will
> > > not use), and things should generally work.
> >
> > That's a bad idea in my opinion.  Redirect as soon as possible.  Why
> > don't you use `after-make-frame-functions'?
> 
> I'm not sure what you mean.  I tried this:
> 
> 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'.
> 
> 2. Put back the guard
> (eq last-event-frame (window-frame (minibuffer-window)))
> at the beginning of `1on1-fit-minibuffer-frame' (so it is a 
> no-op otherwise).
> 
> 3. Defined this and added it to `after-make-frame-functions':
> 
> (defun 1on1-redirect-to-minibuffer (new-frame)
>   "..."
>   (when (and 1on1-fit-minibuffer-frame-flag
>              (active-minibuffer-window)
>              (save-selected-window
>                (select-window (minibuffer-window))
>                (one-window-p nil 'selected-frame)))
>     (redirect-frame-focus
>       new-frame
>       (window-frame (minibuffer-window)))))
> 
> That did not help at all.  The original symptoms returned 
> (typing yes/no did not go to the minibuffer etc.).

IOW, that was the same as doing nothing at all: the minibuffer frame did not
receive the yes/no user input.

So far, the most successful "fix" for my setup seems to be a combination of (a)
your code (`with-temp-buffer-window.el') plus (b) either (i) calling
`redirect-frame-focus' or `select-frame-set-input-focus' at the end of
`1on1-fit-minibuffer-frame' or (ii) using the guard (eq last-event-frame
(window-frame (minibuffer-window))) at the beginning of that function.

As I said, some users of oneonone.el won't also use fit-frame.el, so for them
putting a fix into `1on1-fit-minibuffer-frame' won't help.  I speculated to you
about putting the focus redirection instead on `post-command-hook', but you said
that was a bad idea and proposed to "use `after-make-frame-functions'".  I am
not sure what you meant by that, but the test above, which uses that hook, did
not work, in any case: the input was not redirected to the minibuffer frame.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

 > I speculated to you
 > about putting the focus redirection instead on `post-command-hook', but you said
 > that was a bad idea and proposed to "use `after-make-frame-functions'".  I am
 > not sure what you meant by that, but the test above, which uses that hook, did
 > not work, in any case: the input was not redirected to the minibuffer frame.

I did so because you said that you experienced some delay when
processing input and had the first characetr entered swallowed in some
way.  So I attributed this behavior to the use of `post-command-hook'
and was suggesting an alternative method.

martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

>  > The frame for posing and answering all questions should 
>  > be, as usual, the minibuffer frame.  Aside from `read-event'
>  > etc., reading user input should use the minibuffer, and that
>  > means it should use the minibuffer frame....
>  >
>  > It makes no sense for any other frame to have the input 
>  > focus when reading from the minibuffer, since no other frame
>  > _has_ a minibuffer.
> 
> Most users don't care about standalone minibuffer frames.  
> They want to see one frame where they find all information.

This bug is about those users who _do_ use a standalone minibuffer frame,
whether they are a majority or a minority of GNU Emacs users.  They want reading
of user input and echoing of messages to take place in the same location each
time: the standalone minibuffer frame.  I'm confident of that, even if it is
presumptuous to speak of what other users might want.

FWIW, if most GNU Emacs users do not use a standalone minibuffer today, it might
have something to do with bugs like this one.  I'd be willing to bet that at
least half the users of Epoch did use the standalone minibuffer.  But in Epoch
it was standard, available out of the box, and worked perfectly.  IOW, Epoch
users had a real, simple choice, with no jumping through hoops.

Using a standalone minibuffer is not some oddball idea, even if only a minority
of users choose it today.  And even if, after the bugs are fixed in GNU Emacs,
such users remain a minority, that does not mean that their use case is
unimportant.

>  >>  > But in the case of a standalone minibuffer, it definitely
>  >>  > should continue to have the input focus.
>  >>
>  >> Why "continue"?  You could invoke C-x C-c in any frame.
>  >
>  > See above.  It should have the input focus for any _reading
>  > from the minibuffer_.  Obviously, other frames can have the input 
>  > focus when not reading from the minibuffer.  `yes-or-no-p' reads
>  > from the minibuffer.
> 
> So if another frame has input focus and emacs asks a `yes-or-no-p'
> question, focus _should_ switch.

Emacs should always switch to the minibuffer when it reads from the minibuffer,
yes.  You cannot use the minibuffer if it does not have the focus.  And that's
the point of this bug.

>  > But the behavior I saw with that test indicated/suggested 
>  > that *Help* was not entirely special-display...
>  >
>  > The frame was created with the correct colors etc., but 
>  > buffer *Help* ended up being replaced in the frame, which is not
>  > what "special display" means.  So I think there might be a
>  > second bug here.
> 
> If this is independent from the behavior we discuss currently, we'll
> have to investigate it.

I'm comforted that you consider that behavior to be a bug.  See also my earlier
message today, where I reported (seemingly) the same bug wrt special-display
buffer `*Process List*' when testing the code you sent.  That special-display
definition was made differently (via `special-display-regexps'), but the bugged
effect seems to be the same.

No buffer should take the place of a special-display buffer in its window/frame.
That's always been part of the definition of "special display".

>  >>  > If I use Dired+ (which does what my patch does) then there
>  >>  > is no problem, so in my daily use this is solved for the
>  >>  > Dired but reported, but not in general (viz.
>  >>  > this bug wrt quitting with active processes).
>  >>
>  >> But your patch doesn't address the input focus issue or 
>  >> am I missing something?
>  >
>  > Correct.  But the problem does not exist with my patch.  I 
>  > don't have an explanation.
> 
> Me neither.  You would have to go through it and find what it does
> differently.
> 
>  > But please see the #15566 thread

Sorry, I meant #11566.

Note: I am testing using 24.1.  Dunno whether the bug reported in #11566 was
deemed to have been fixed after 24.1 or before it.  IOW, perhaps it has been
fixed since 24.1, but I cannot test with a recent build until I can get a post
24.1 Windows build that works.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

> This is part of the ongoing saga of trying to get Emacs to DTRT with
> buffers popped up only to serve as info while Emacs asks a question
> requiring a response.
>  
> IF you use a standalone minibuffer frame, AND the popped up buffer is
> special-display (e.g. because of `special-display-regexps'), AND you are
> on MS Windows (which automatically shifts the focus to a new frame that
> it creates), THEN:
>  
> 1. When you try to exit Emacs with active processes, Emacs pops up a new
> frame for buffer `*Process List*' and asks you about killing them.
>  
> 2. But the minibuffer frame no longer has the focus!  So when you type
> your answer (e.g. "yes") Emacs tries to insert it as text in buffer
> `*Process List*'.  Poor Emacs.

Please check with the next binaries whether this works now as intended.

Thanks, martin

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[Drew Adams]

> Please check with the next binaries whether this works now as 
> intended. Thanks, martin

Will do; thanks.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[Drew Adams]

> Sent: Wednesday, September 05, 2012 7:36 AM
> 
> > Please check with the next binaries whether this works now as 
> > intended. Thanks, martin
> 
> Will do; thanks.

Finally got a Windows binary I could check this with.

There was a lot in this thread.  But I at least checked that the original
problem reported (for the popup question about active processes) is fixed.  It
is.  Thx.

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when itcalls `list-processes'

[martin rudalics]

> There was a lot in this thread.  But I at least checked that the original
> problem reported (for the popup question about active processes) is fixed.  It
> is.  Thx.

OK.  Closing this as well.

Thanks, martin