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>, "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 11939 <at> debbugs.gnu.org
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it	calls	`list-processes'
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.

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

Previous Next

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