bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/)

[Richard Kim <emacs18@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

I don't normally set user-emacs-directory via --eval argument. Instead
it is set within a file which is loaded via --eval. I suppose this is
not that significant difference. In the original report I tried to
remove all non-essential stuff by coming up with a minimum instruction
that demonstrated the problem. Isn't that how you would like most
problems reported?

For the first 25 or so years, I used ~/.emacs to customize emacs.
However for the past few years I switched to using "eamacs -q --eval ...
--eval ... " style. This decision was not because of my ignorance of
other command line options that emacs provides. Instead this style gave
me the flexibility to generate elisp on the fly to setup emacs exactly
the way I want without having to edit any files. I happen to use python
script that takes few command line arguments, which then may generate
elisp files, and/or generate appropriate --eval arguments. The primary
motivation for this style of emacs launching is to allow me to enable or
disable spacemacs, enable or disable my own configration, etc. This
flexibility is very handy when something goes wrong. I can quickly
eliminate big parts of potential causes.

With packaging system, there are so many useful packages that I want to
use. Unfortunately stability suffers. I did not know about "kill -USR2
<pid>" until recently as some have also pointed out in emacs-devel list.
So ability to diagnose problems quickly is important to me.

The reason I test drove emacs 26 was in response to a call for testing
concurrency stuff. Until this I used only emacs-25 git branch for months
and months. The problem I reported is not a big deal for me. I can
easily suppress the warning by doing something like

   cd
   rm -rf ~/.emacs.d
   mkdir ~/elisp/.emacs.d
   ln -s ~/elisp/.emacs.d

so that if emacs were to create a file under ~/.emacs.d, then I would
know about it since ~/elisp would be version controlled via git.
I supposed I could  use git repo for the home directory, but I have other
reasons for not doing that.

On 11 December 2016 at 20:07, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> The underlying problem is that Emacs uses user-emacs-directory and
> >> user-emacs-directory-warning before any user-customization is made
> >> effective.
> >>
> >> Emacs not being aware of the user setting user-emacs-directory-warning
> >> is annoying and can be solved by delaying the warning, but the part
> >> about user-emacs-directory looks more concerning.
> >
> > Yes, those are my concerns exactly.
> >
> > More generally, Emacs supports only one method of pointing that
> > directory to another place, and that is via the -u command-line
> > option.  We could perhaps support other methods as well, like the one
> > the OP uses, but IMO it will require more changes than just delaying
> > the warning.
>
> I guess that the OP is exceptional among the Emacs user base when he
> resorts to --eval '(setq user-emacs-directory ...)' because he is not
> aware of the correct and simple -u command line option. If that's the
> case, his problem should be completely solved by using -u (without need
> to set user-emacs-directory-warning).
>
> I propose to change the docstring of user-emacs-directory to mention -u
> as the correct method and recommend against setting that variable in any
> way. Sadly, we cannot remove it altogether.
>
> As for user-emacs-directory-warning, leave it alone. Actually, in this
> case it was doing its job.
>

[-- Attachment #2: Type: text/html, Size: 4466 bytes --]