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

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

[Richard Kim]

My build of emacs 26 (git repo version 25a52ca of 2016/12/10)
starts up with the following warning:

  Warning (initialization): Unable to access `user-emacs-directory' (~/.emacs.d/).
  Any data that would normally be written there may be lost!
  If you never want to see this message again,
  customize the variable `user-emacs-directory-warning'.

This is despite setting the variable as suggested to suppress such warning.
I think this warning should not be printed.

Emacs is started like this:

  chmod 0 ~/.emacs.d
  ~/opt/emacs26/bin/emacs -q \
    --eval '(setq user-emacs-directory (expand-file-name "~/elisp/"))' \
    --eval '(setq user-emacs-directory-warning nil)'

Emacs 25 (git repo build of emacs-25 branch) started the same way does
not print this warning.

I always make ~/.emacs.d unreadable so that emacs will not create files
without me knowing about it.  I set user-emacs-directory to a directory
that is version controlled via git.


In GNU Emacs 26.0.50.3 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-12-10 built on kimr-ubuntu
Repository revision: 25a52ca6b2521623334e5768ae26e46595a1b36b
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:	Ubuntu 16.04.1 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
M-s M-x is undefined

Configured using:
 'configure --with-x-toolkit=yes --with-xml2 --without-compress-install
 --with-modules --with-file-notification=yes --prefix
 /home/kimr/opt/emacs-26-20161210 CFLAGS=-O3'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date warnings mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 98326 6613)
 (symbols 48 20238 0)
 (miscs 40 435 129)
 (strings 32 18189 4875)
 (string-bytes 1 596736)
 (vectors 16 14137)
 (vector-slots 8 457905 5856)
 (floats 8 183 32)
 (intervals 56 227 0)
 (buffers 976 12)
 (heap 1024 32721 1008))

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

[npostavs]

Richard Kim <emacs18@gmail.com> writes:

> My build of emacs 26 (git repo version 25a52ca of 2016/12/10)
> starts up with the following warning:
>
>   Warning (initialization): Unable to access `user-emacs-directory' (~/.emacs.d/).
>   Any data that would normally be written there may be lost!
>   If you never want to see this message again,
>   customize the variable `user-emacs-directory-warning'.
>
> This is despite setting the variable as suggested to suppress such warning.
> I think this warning should not be printed.
>
> Emacs is started like this:
>
>   chmod 0 ~/.emacs.d
>   ~/opt/emacs26/bin/emacs -q \
>     --eval '(setq user-emacs-directory (expand-file-name "~/elisp/"))' \
>     --eval '(setq user-emacs-directory-warning nil)'
>
> Emacs 25 (git repo build of emacs-25 branch) started the same way does
> not print this warning.

I see the same in Emacs 25, 24.5, and 24.4; 24.3 just prints a "File
exists" message.  Looks like the problem is that locate-user-emacs-file
(and thus the check for the warning) is called before any customizations
(or --eval args) are executed.  Here's a backtrace I got by putting
(debug) inside locate-user-emacs-file, just before the `display-warning'
call:

Debugger entered: nil
  locate-user-emacs-file("abbrev_defs" ".abbrev_defs")
  #[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3]()
  funcall(#[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3])
  eval((funcall (function #[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3])))
  custom-reevaluate-setting(abbrev-file-name)
  mapc(custom-reevaluate-setting (temporary-file-directory transient-mark-mode small-temporary-file-directory auto-save-file-name-transforms remote-shell-program Info-default-directory-list rmail-spool-directory abbrev-file-name auto-encryption-mode blink-cursor-mode tutorial-directory global-font-lock-mode file-name-shadow-mode query-replace-from-to-separator image-load-path mouse-wheel-mode electric-indent-mode electric-quote-mode global-eldoc-mode tooltip-mode))
  command-line()
  normal-top-level()

Perhaps the warning could be delayed until after init time?

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

[Tino Calancha]

npostavs@users.sourceforge.net writes:

> I see the same in Emacs 25, 24.5, and 24.4; 24.3 just prints a "File
> exists" message.  Looks like the problem is that locate-user-emacs-file
> (and thus the check for the warning) is called before any customizations
> (or --eval args) are executed.
> Perhaps the warning could be delayed until after init time?

Following patch delay the warning until al command line arguments have
being processed.
What do you think?

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
From 8d715d63eeda6e7814a86203f59ce6ee239aa65d Mon Sep 17 00:00:00 2001
From: Tino Calancha <tino.calancha@gmail.com>
Date: Sun, 11 Dec 2016 17:32:18 +0900
Subject: [PATCH] Fix Bug#25162

* lisp/startup.el (command-line): If user-emacs-directory is not
accessible, delay to show a warning until all command line args
are processed.
---
 lisp/startup.el | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/lisp/startup.el b/lisp/startup.el
index 4a04f9c..dc59d9c 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1094,11 +1094,12 @@ command-line
 
   ;; Re-evaluate predefined variables whose initial value depends on
   ;; the runtime context.
-  (mapc 'custom-reevaluate-setting
-        ;; Initialize them in the same order they were loaded, in case there
-        ;; are dependencies between them.
-        (prog1 (nreverse custom-delayed-init-variables)
-          (setq custom-delayed-init-variables nil)))
+  (let (user-emacs-directory-warning) ; Delay showing this warning (Bug#25162).
+    (mapc 'custom-reevaluate-setting
+          ;; Initialize them in the same order they were loaded, in case there
+          ;; are dependencies between them.
+          (prog1 (nreverse custom-delayed-init-variables)
+            (setq custom-delayed-init-variables nil))))
 
   (normal-erase-is-backspace-setup-frame)
 
@@ -1365,6 +1366,11 @@ command-line
   ;; Process the remaining args.
   (command-line-1 (cdr command-line-args))
 
+  ;; Check if `user-emacs-directory' is accessible (Bug#25162).
+  (when (and user-emacs-directory-warning
+             (not (file-accessible-directory-p user-emacs-directory)))
+    (locate-user-emacs-file ""))
+
   ;; This is a problem because, e.g. if emacs.d/gnus.el exists,
   ;; trying to load gnus could load the wrong file.
   ;; OK, it would not matter if .emacs.d were at the end of load-path.
-- 
2.10.2

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
In GNU Emacs 26.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.4)
 of 2016-12-11
Repository revision: 595a4d6bfd5aad79fb3ab681ae06f0739a4a5701

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

[npostavs]

Tino Calancha <tino.calancha@gmail.com> writes:

> npostavs@users.sourceforge.net writes:
>
>> I see the same in Emacs 25, 24.5, and 24.4; 24.3 just prints a "File
>> exists" message.  Looks like the problem is that locate-user-emacs-file
>> (and thus the check for the warning) is called before any customizations
>> (or --eval args) are executed.
>> Perhaps the warning could be delayed until after init time?
>
> Following patch delay the warning until al command line arguments have
> being processed.
> What do you think?

I think that would still be too early for the user setting the variable
in their init file.  I would suggest using after-init-hook, something
like:

(defun locate-user-emacs-file ...
   ...
   (when errtype
     (add-hook 'after-init-hook #'maybe-warn-about-user-dir)))

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

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Date: Sat, 10 Dec 2016 23:24:06 -0500
> Cc: 25163@debbugs.gnu.org
> 
> Debugger entered: nil
>   locate-user-emacs-file("abbrev_defs" ".abbrev_defs")
>   #[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3]()
>   funcall(#[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3])
>   eval((funcall (function #[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3])))
>   custom-reevaluate-setting(abbrev-file-name)
>   mapc(custom-reevaluate-setting (temporary-file-directory transient-mark-mode small-temporary-file-directory auto-save-file-name-transforms remote-shell-program Info-default-directory-list rmail-spool-directory abbrev-file-name auto-encryption-mode blink-cursor-mode tutorial-directory global-font-lock-mode file-name-shadow-mode query-replace-from-to-separator image-load-path mouse-wheel-mode electric-indent-mode electric-quote-mode global-eldoc-mode tooltip-mode))
>   command-line()
>   normal-top-level()
> 
> Perhaps the warning could be delayed until after init time?

What would that do to the value of abbrev-file-name?

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

[Noam Postavsky]

On Sun, Dec 11, 2016 at 10:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: npostavs@users.sourceforge.net
>> Date: Sat, 10 Dec 2016 23:24:06 -0500
>> Cc: 25163@debbugs.gnu.org
>>
>> Debugger entered: nil
>>   locate-user-emacs-file("abbrev_defs" ".abbrev_defs")
>>   #[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3]()
>>   funcall(#[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3])
>>   eval((funcall (function #[0 "\300\301\302\"\207" [locate-user-emacs-file "abbrev_defs" ".abbrev_defs"] 3])))
>>   custom-reevaluate-setting(abbrev-file-name)
>>   mapc(custom-reevaluate-setting (temporary-file-directory transient-mark-mode small-temporary-file-directory auto-save-file-name-transforms remote-shell-program Info-default-directory-list rmail-spool-directory abbrev-file-name auto-encryption-mode blink-cursor-mode tutorial-directory global-font-lock-mode file-name-shadow-mode query-replace-from-to-separator image-load-path mouse-wheel-mode electric-indent-mode electric-quote-mode global-eldoc-mode tooltip-mode))
>>   command-line()
>>   normal-top-level()
>>
>> Perhaps the warning could be delayed until after init time?
>
> What would that do to the value of abbrev-file-name?

Nothing, only the warning should be delayed.

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 11 Dec 2016 10:50:49 -0500
> Cc: Richard Kim <emacs18@gmail.com>, 25163@debbugs.gnu.org
> 
> >> Perhaps the warning could be delayed until after init time?
> >
> > What would that do to the value of abbrev-file-name?
> 
> Nothing, only the warning should be delayed.

But Emacs will then create .emacs.d, something the OP didn't want,
right?

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

[Noam Postavsky]

On Sun, Dec 11, 2016 at 12:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sun, 11 Dec 2016 10:50:49 -0500
>> Cc: Richard Kim <emacs18@gmail.com>, 25163@debbugs.gnu.org
>>
>> >> Perhaps the warning could be delayed until after init time?
>> >
>> > What would that do to the value of abbrev-file-name?
>>
>> Nothing, only the warning should be delayed.
>
> But Emacs will then create .emacs.d, something the OP didn't want,
> right?

The OP already created an unwritable .emacs.d, so I think that's not
the problem. It's only the non-suppressable warning. Unless I've
misread?

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

[Óscar Fuentes]

Noam Postavsky <npostavs@users.sourceforge.net> writes:

>>> Nothing, only the warning should be delayed.
>>
>> But Emacs will then create .emacs.d, something the OP didn't want,
>> right?
>
> The OP already created an unwritable .emacs.d, so I think that's not
> the problem. It's only the non-suppressable warning. Unless I've
> misread?

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.

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

[Tino Calancha]

npostavs@users.sourceforge.net writes:

> Tino Calancha <tino.calancha@gmail.com> writes:
>
>> Following patch delay the warning until al command line arguments have
>> being processed.
>> What do you think?
>
> I think that would still be too early for the user setting the variable
> in their init file.  I would suggest using after-init-hook, something
> like:
>
> (defun locate-user-emacs-file ...
>    ...
>    (when errtype
>      (add-hook 'after-init-hook #'maybe-warn-about-user-dir)))
I haven't tried your hook solution yet, which probably is better than
mine.  Just for offering an alternative way i have updated my previous
patch to handle the case when the user have customized
`user-emacs-directory-warning':

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
From a96f5a406ec965d6010e840fb938da239df706ef Mon Sep 17 00:00:00 2001
From: Tino Calancha <tino.calancha@gmail.com>
Date: Mon, 12 Dec 2016 11:35:06 +0900
Subject: [PATCH] Fix Bug#25162

* lisp/startup.el (command-line): If user-emacs-directory is not
accessible, delay to show a warning until all command line args
are processed.
---
 lisp/startup.el | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/lisp/startup.el b/lisp/startup.el
index 4a04f9c..f562c88 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1094,11 +1094,12 @@ command-line
 
   ;; Re-evaluate predefined variables whose initial value depends on
   ;; the runtime context.
-  (mapc 'custom-reevaluate-setting
-        ;; Initialize them in the same order they were loaded, in case there
-        ;; are dependencies between them.
-        (prog1 (nreverse custom-delayed-init-variables)
-          (setq custom-delayed-init-variables nil)))
+  (let (user-emacs-directory-warning) ; Delay showing this warning (Bug#25162).
+    (mapc 'custom-reevaluate-setting
+          ;; Initialize them in the same order they were loaded, in case there
+          ;; are dependencies between them.
+          (prog1 (nreverse custom-delayed-init-variables)
+            (setq custom-delayed-init-variables nil))))
 
   (normal-erase-is-backspace-setup-frame)
 
@@ -1362,9 +1363,18 @@ command-line
 	(list 'error
 	      (substitute-command-keys "Memory exhausted--use \\[save-some-buffers] then exit and restart Emacs")))
 
+  ;; Reevaluate `user-emacs-directory-warning' before process '--eval'
+  ;;  args, so that the user can override that default (Bug#25162).
+  (custom-reevaluate-setting 'user-emacs-directory-warning)
+
   ;; Process the remaining args.
   (command-line-1 (cdr command-line-args))
 
+  ;; Check if `user-emacs-directory' is accessible (Bug#25162).
+  (when (and user-emacs-directory-warning
+             (not (file-accessible-directory-p user-emacs-directory)))
+    (locate-user-emacs-file ""))
+
   ;; This is a problem because, e.g. if emacs.d/gnus.el exists,
   ;; trying to load gnus could load the wrong file.
   ;; OK, it would not matter if .emacs.d were at the end of load-path.
-- 
2.10.2

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
In GNU Emacs 26.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.4)
 of 2016-12-11
Repository revision: 2783e0e3899cf92910e97dc8bfda3e47b3df1478

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 11 Dec 2016 23:26:52 +0100
> 
> 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.

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

[Óscar Fuentes]

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.

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

[Richard Kim]

[-- 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 --]

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

[Glenn Morris]

Óscar Fuentes wrote:

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

Somewhat off-topic for this report, but -u is a bit rubbish, isn't it?
  "load ~USER/.emacs instead of your own"
Nobody wants to load Fred's .emacs (since about 1983 on a VAX).
What they want is to use some directory other than ~/.emacs in their own space.
(But that's bug#15539, which I'm a bit surprised to see was closed wontfix.)

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

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

> Somewhat off-topic for this report, but -u is a bit rubbish, isn't it?
>   "load ~USER/.emacs instead of your own"
> Nobody wants to load Fred's .emacs (since about 1983 on a VAX).
> What they want is to use some directory other than ~/.emacs in their own space.

Agreed. I was under the impression that -u was followed by an arbitrary
directory, but now I recall that it expects an user name. This is no
alternative to setting emacs-user-directory at all.

> (But that's bug#15539, which I'm a bit surprised to see was closed wontfix.)

It was after John Wiegley mentioned that you can set
user-emacs-directory to achieve the same effect, which right now it is
not correct.

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

[Eli Zaretskii]

> From: Richard Kim <emacs18@gmail.com>
> Date: Mon, 12 Dec 2016 18:19:33 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>, 25163@debbugs.gnu.org
> 
> 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.

Setting things up in your ~/.emacs and making the same settings via --eval
or --load produces subtly different results for some options.  That's because 
Emacs processes the user settings in ~/.emacs specially, sometimes
evaluating the same setting more than once, to provide the expected effects,
This special processing is not done for the other methods of specifying
initial settings.

So when you made that switch, you already changed the way your
sessions are set up.  You might not paid attention to this aspect,
because for most options the effect is identical.  But the difference
is there nonetheless, and it's real.

The above isn't meant to invalidate your report in any way, just to
explain that .emacs and --eval, as designed and implemented, sometimes
produce different results.

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

[Noam Postavsky]

I wrote:

> Looks like the problem is that locate-user-emacs-file (and thus the
> check for the warning) is called before any customizations (or --eval
> args) are executed.

> Perhaps the warning could be delayed until after init time?

So, taking another look at this, the warning *is* currently delayed
until after init time (as are all warnings occuring before init time).
The problem is, delayed warnings are displayed just after init time,
which is just before --eval args are executed.  Maybe we should have
--early-eval to go along with ~/.emacs.d/early-init.el?  Or maybe just
require suppressing this warning via site-start.el.  The patch below
makes that possible (maybe the first hunk isn't really needed, and we
should just remove the user-emacs-directory-warning option in favour of
setting warning-suppress-log-types instead):

--- i/lisp/files.el
+++ w/lisp/files.el
@@ -990,6 +990,13 @@ user-emacs-directory-warning
   :group 'initialization
   :version "24.4")
 
+(defvar warning-suppress-log-types) ; `warnings.el'.
+(defun maybe-suppress-user-emacs-directory-warning ()
+  "Apply `user-emacs-directory-warning' suppression."
+  (unless user-emacs-directory-warning
+    (add-to-list 'warning-suppress-log-types '(initialization user-emacs-directory))))
+(add-hook 'after-init-hook #'maybe-suppress-user-emacs-directory-warning)
+
 (defun locate-user-emacs-file (new-name &optional old-name)
   "Return an absolute per-user Emacs-specific file name.
 If NEW-NAME exists in `user-emacs-directory', return it.
@@ -1021,7 +1028,7 @@ locate-user-emacs-file
 			(not (get 'user-emacs-directory-warning 'this-session)))
 	       ;; Only warn once per Emacs session.
 	       (put 'user-emacs-directory-warning 'this-session t)
-	       (display-warning 'initialization
+	       (display-warning `(initialization user-emacs-directory ,(intern errtype))
 				(format "\
 Unable to %s `user-emacs-directory' (%s).
 Any data that would normally be written there may be lost!

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

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> So, taking another look at this, the warning *is* currently delayed
> until after init time (as are all warnings occuring before init time).
> The problem is, delayed warnings are displayed just after init time,
> which is just before --eval args are executed.  Maybe we should have
> --early-eval to go along with ~/.emacs.d/early-init.el?  Or maybe just
> require suppressing this warning via site-start.el.  The patch below
> makes that possible (maybe the first hunk isn't really needed, and we
> should just remove the user-emacs-directory-warning option in favour of
> setting warning-suppress-log-types instead):

[...]

> +(defvar warning-suppress-log-types) ; `warnings.el'.
> +(defun maybe-suppress-user-emacs-directory-warning ()
> +  "Apply `user-emacs-directory-warning' suppression."
> +  (unless user-emacs-directory-warning
> +    (add-to-list 'warning-suppress-log-types '(initialization user-emacs-directory))))
> +(add-hook 'after-init-hook #'maybe-suppress-user-emacs-directory-warning)

I tried applying the patch to Emacs 28, but it doesn't seem to fix the
problem -- I still get the warning about the directory not existing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Tino Calancha <tino.calancha@gmail.com> writes:

> I haven't tried your hook solution yet, which probably is better than
> mine.  Just for offering an alternative way i have updated my previous
> patch to handle the case when the user have customized
> `user-emacs-directory-warning':

The discussion then went on to whether we're respecting
`user-emacs-directory' enough, but Tino's patch seems to be the right
thing for the warning, at least, so I've applied it to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no