bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Drew Adams
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes'
Date: Thu, 26 Jul 2012 09:21:02 -0700

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






reply via email to

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