[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'
Date: Tue, 17 Jul 2012 11:50:06 +0200

> (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 

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

  (defalias 'yes-or-no-p 'y-or-n-p)
  (load "~/with-temp-buffer-window.el")
  (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

  (defalias 'yes-or-no-p 'y-or-n-p)
  (load "~/with-temp-buffer-window.el")
  (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.


Attachment: with-temp-buffer-window.el
Description: application/emacs-lisp

reply via email to

[Prev in Thread] Current Thread [Next in Thread]