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

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 11939 <at> debbugs.gnu.org
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenitcalls `list-processes'
Date: Tue, 7 Aug 2012 06:39:56 -0700

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

Previous Next

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