* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/)
@ 2016-12-11 3:34 Richard Kim
2016-12-11 4:24 ` npostavs
0 siblings, 1 reply; 19+ messages in thread
From: Richard Kim @ 2016-12-11 3:34 UTC (permalink / raw)
To: 25163
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))
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 3:34 bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) Richard Kim @ 2016-12-11 4:24 ` npostavs 2016-12-11 8:38 ` Tino Calancha ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: npostavs @ 2016-12-11 4:24 UTC (permalink / raw) To: Richard Kim; +Cc: 25163 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 4:24 ` npostavs @ 2016-12-11 8:38 ` Tino Calancha 2016-12-11 14:07 ` npostavs 2016-12-11 15:28 ` Eli Zaretskii 2018-06-13 1:24 ` Noam Postavsky 2 siblings, 1 reply; 19+ messages in thread From: Tino Calancha @ 2016-12-11 8:38 UTC (permalink / raw) To: npostavs; +Cc: Richard Kim, 25163, 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 8:38 ` Tino Calancha @ 2016-12-11 14:07 ` npostavs 2016-12-12 2:41 ` Tino Calancha 0 siblings, 1 reply; 19+ messages in thread From: npostavs @ 2016-12-11 14:07 UTC (permalink / raw) To: Tino Calancha; +Cc: Richard Kim, 25163 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))) ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 14:07 ` npostavs @ 2016-12-12 2:41 ` Tino Calancha 2022-04-21 15:28 ` Lars Ingebrigtsen 0 siblings, 1 reply; 19+ messages in thread From: Tino Calancha @ 2016-12-12 2:41 UTC (permalink / raw) To: npostavs; +Cc: Óscar Fuentes, Richard Kim, 25163, 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-12 2:41 ` Tino Calancha @ 2022-04-21 15:28 ` Lars Ingebrigtsen 0 siblings, 0 replies; 19+ messages in thread From: Lars Ingebrigtsen @ 2022-04-21 15:28 UTC (permalink / raw) To: Tino Calancha; +Cc: Óscar Fuentes, Richard Kim, 25163, npostavs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 4:24 ` npostavs 2016-12-11 8:38 ` Tino Calancha @ 2016-12-11 15:28 ` Eli Zaretskii 2016-12-11 15:50 ` Noam Postavsky 2018-06-13 1:24 ` Noam Postavsky 2 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2016-12-11 15:28 UTC (permalink / raw) To: npostavs; +Cc: emacs18, 25163 > 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 15:28 ` Eli Zaretskii @ 2016-12-11 15:50 ` Noam Postavsky 2016-12-11 17:32 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Noam Postavsky @ 2016-12-11 15:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Richard Kim, 25163 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 15:50 ` Noam Postavsky @ 2016-12-11 17:32 ` Eli Zaretskii 2016-12-11 22:15 ` Noam Postavsky 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2016-12-11 17:32 UTC (permalink / raw) To: Noam Postavsky; +Cc: emacs18, 25163 > 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 17:32 ` Eli Zaretskii @ 2016-12-11 22:15 ` Noam Postavsky 2016-12-11 22:26 ` Óscar Fuentes 0 siblings, 1 reply; 19+ messages in thread From: Noam Postavsky @ 2016-12-11 22:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Richard Kim, 25163 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 22:15 ` Noam Postavsky @ 2016-12-11 22:26 ` Óscar Fuentes 2016-12-12 3:28 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Óscar Fuentes @ 2016-12-11 22:26 UTC (permalink / raw) To: 25163 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 22:26 ` Óscar Fuentes @ 2016-12-12 3:28 ` Eli Zaretskii 2016-12-12 4:07 ` Óscar Fuentes 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2016-12-12 3:28 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 25163 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-12 3:28 ` Eli Zaretskii @ 2016-12-12 4:07 ` Óscar Fuentes 2016-12-13 2:19 ` Richard Kim 2016-12-13 2:40 ` Glenn Morris 0 siblings, 2 replies; 19+ messages in thread From: Óscar Fuentes @ 2016-12-12 4:07 UTC (permalink / raw) To: Eli Zaretskii, Richard Kim; +Cc: 25163 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-12 4:07 ` Óscar Fuentes @ 2016-12-13 2:19 ` Richard Kim 2016-12-13 15:52 ` Eli Zaretskii 2016-12-13 2:40 ` Glenn Morris 1 sibling, 1 reply; 19+ messages in thread From: Richard Kim @ 2016-12-13 2:19 UTC (permalink / raw) To: Óscar Fuentes; +Cc: 25163 [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-13 2:19 ` Richard Kim @ 2016-12-13 15:52 ` Eli Zaretskii 0 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2016-12-13 15:52 UTC (permalink / raw) To: Richard Kim; +Cc: ofv, 25163 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-12 4:07 ` Óscar Fuentes 2016-12-13 2:19 ` Richard Kim @ 2016-12-13 2:40 ` Glenn Morris 2016-12-13 4:02 ` Óscar Fuentes 1 sibling, 1 reply; 19+ messages in thread From: Glenn Morris @ 2016-12-13 2:40 UTC (permalink / raw) To: Óscar Fuentes; +Cc: Richard Kim, 25163 Ó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.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-13 2:40 ` Glenn Morris @ 2016-12-13 4:02 ` Óscar Fuentes 0 siblings, 0 replies; 19+ messages in thread From: Óscar Fuentes @ 2016-12-13 4:02 UTC (permalink / raw) To: Glenn Morris; +Cc: Richard Kim, 25163 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2016-12-11 4:24 ` npostavs 2016-12-11 8:38 ` Tino Calancha 2016-12-11 15:28 ` Eli Zaretskii @ 2018-06-13 1:24 ` Noam Postavsky 2020-08-24 15:54 ` Lars Ingebrigtsen 2 siblings, 1 reply; 19+ messages in thread From: Noam Postavsky @ 2018-06-13 1:24 UTC (permalink / raw) To: 25163; +Cc: Richard Kim 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! ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) 2018-06-13 1:24 ` Noam Postavsky @ 2020-08-24 15:54 ` Lars Ingebrigtsen 0 siblings, 0 replies; 19+ messages in thread From: Lars Ingebrigtsen @ 2020-08-24 15:54 UTC (permalink / raw) To: Noam Postavsky; +Cc: Richard Kim, 25163 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2022-04-21 15:28 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-12-11 3:34 bug#25163: 26.0.50; Unable to access `user-emacs-directory' (~/.emacs.d/) Richard Kim 2016-12-11 4:24 ` npostavs 2016-12-11 8:38 ` Tino Calancha 2016-12-11 14:07 ` npostavs 2016-12-12 2:41 ` Tino Calancha 2022-04-21 15:28 ` Lars Ingebrigtsen 2016-12-11 15:28 ` Eli Zaretskii 2016-12-11 15:50 ` Noam Postavsky 2016-12-11 17:32 ` Eli Zaretskii 2016-12-11 22:15 ` Noam Postavsky 2016-12-11 22:26 ` Óscar Fuentes 2016-12-12 3:28 ` Eli Zaretskii 2016-12-12 4:07 ` Óscar Fuentes 2016-12-13 2:19 ` Richard Kim 2016-12-13 15:52 ` Eli Zaretskii 2016-12-13 2:40 ` Glenn Morris 2016-12-13 4:02 ` Óscar Fuentes 2018-06-13 1:24 ` Noam Postavsky 2020-08-24 15:54 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).