GNU bug report logs - #13930
Emacs doesn't cope well if it can't access/create .emacs.d

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13930 <at> debbugs.gnu.org, rprije <at> janestreet.com
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 12 Mar 2013 18:48:22 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Robert Prije <rprije <at> janestreet.com>,  13930 <at> debbugs.gnu.org
> Date: Tue, 12 Mar 2013 12:29:23 -0400
> 
> Eli Zaretskii wrote:
> 
> >> It does exactly the same thing with --debug-init (says "creating directory:
> >> permission denied...") and supplies no further information.
> >
> > How about running it under GDB with a breakpoint on report_file_error
> > and on xsignal?  If you start GDB from the src directory of the Emacs
> > sources, the .gdbinit file there defines a command xbacktrace which
> > will produce a Lisp-level backtrace in addition to the C-level
> > backtrace produced by the "bt" command of GDB.
> 
> Why do we need to jump through such hoops, when locate-user-emacs-file,
> which Stefan has just added all over the place, says:
> 
>   Else return NEW-NAME in `user-emacs-directory', creating the
>   directory if it does not exist.

If you mean that remembering this was all you needed to deduce that
locate-user-emacs-file is the culprit, then good for you.  I never
remember such details (and this one I think I never knew about in the
first place).  A debugger will show the truth even if the problem is
in some other place, so it is (IMO) a more efficient way of finding
the root cause.

IOW, more often than not I find that "jumping through hoops" is the
shortest and most reliable way to solution.

Previous Next

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