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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rudalics <at> gmx.at, 11939 <at> debbugs.gnu.org
Subject: Re: bug#11939: 24.1;
	`save-buffers-kill-emacs' loses minibuffer focus when
	it	calls	`list-processes'
Date: Mon, 23 Jul 2012 19:04:02 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <rudalics <at> gmx.at>, <11939 <at> debbugs.gnu.org>
> Date: Sun, 22 Jul 2012 14:01:58 -0700
> 
> > > Error (initialization): User  has no home directory
> >                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > What does that last message tell you?  I think this is the key to
> > unlock your mystery.
> 
> Perhaps you can tell me how so?

How could I, without knowing all that you told about your environment
since my message?  Even now, with all that additional info in hand, I
can only guess (see below).  By contrast, you should be well equipped
to find out what is going on, because this message comes from
startup.el (says 'grep').

> The bash cmd prompt recognizes ~ correctly.  And so does Emacs (aside from emacs
> -Q).
> 
> And env var HOME is also defined correctly and recognized by both bash (outside
> and inside Emacs, aside from emacs -Q) and Emacs (aside from emacs -Q).
> 
> Can you please demystify the mystery that you see?

Given this:

> Perhaps I should add that in a bash command prompt outside Emacs, echoing $HOME
> or ~ shows this:
> 
> /cygdrive/c
> 
> Inside Emacs (apart from emacs -Q), `C-x d ~' takes me to c:/,
> and (getenv "HOME") returns "c:\\".

I'm guessing that you invoked GDB from the Cygwin Bash's prompt, which
has the effect of setting HOME to /cygdrive/c, which the native
Windows Emacs doesn't grok.  The code in startup.el that looks for
~/.emacs tests the value of HOME by calling file-directory-p, which
fails for /cygdrive/c, the result being the error message.  I'm
guessing that invoking GDB from the Windows shell cmd.exe should fix
this.

In any case, since the purpose of this discussion is not to "fix" your
environment, I suggest that instead of invoking Emacs from GDB, you
invoke it normally (presumably from a desktop shortcut); then
immediately attach GDB to it, like you do when Emacs crashes; then
type "continue" at GDB's prompt to let Emacs run; and finally do
whatever Martin asked you to for which he wanted GDB to kick in.

Previous Next

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