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

Previous Next

Full log

Message #239 received at 11939 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11939 <at> debbugs.gnu.org
Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus
	whenit	calls	`list-processes'
Date: Fri, 27 Jul 2012 08:33:14 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.