GNU bug report logs -
#583
Use XDG basedir spec for configuration files?
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 583 in the body.
You can then email your comments to 583 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#583
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
ferkiwi+a <at> gmail.com
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
The XDG Base Directory
Specification<http://standards.freedesktop.org/basedir-spec/>provides
some common paths in user's home to store personal application
configurations, or, using their own words "*defines where these files should
be looked for by defining one or more base directories relative to which
files should be located*".
XDG Base Directory Specification allows efficient backup, in which you can
easily choose to backup your data and/or your configuration files for
instance. An application could easily propose such backup for the whole
system if all applications were matching these specification.
Therefore, although I think that this bug/enhancement is not vital, it would
be great for Emacs to be "FreeDesktop XDG Base Directory Specification"
compliant.
Currently Emacs is using "$HOME/.emacs.d/". This is what XDG basedir spec
defines:
- $XDG_DATA_HOME (usually $HOME/.local/share/) as "*the base directory
relative to which user specific data files should be stored*"
- $XDG_CONFIG_HOME (usually $HOME/.config/) as "*the base directory
relative to which user specific configuration files should be stored*"
- $XDG_CACHE_HOME (usually $HOME/.cache/) as "*the base directory
relative to which user specific non-essential data files should be stored
*"
(http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)
In order to make Emacs XDG basedir compliant, I think that it would be nice
to use:
- $XDG_CONFIG_HOME/emacs ;;for "init.el" and storing customize
configuration
- $XDG_DATA_HOME/emacs ;;for sessions and backups
- $XDG_CACHE_HOME/emacs ;;for cache files
Or maybe some other distribution. What do you think about it?
There's a small C library that may be useful check it out, written for the
sole purpose of xdg basedir spec compliance:
https://n.ethz.ch/student/nevillm/download/libxdg-basedir/
[Message part 2 (text/html, inline)]
Severity set to `wishlist' from `normal'
Request was from
Chong Yidong <cyd <at> stupidchicken.com>
to
control <at> emacsbugs.donarmstrong.com
.
(Wed, 30 Jul 2008 13:35:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sat, 08 Dec 2012 18:50:01 GMT)
Full text and
rfc822 format available.
Message #10 received at 583 <at> debbugs.gnu.org (full text, mbox):
What is planned now about FreeDesktop XDG basedir specification for Emacs?
http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders
http://standards.freedesktop.org/basedir-spec/latest/
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sat, 08 Dec 2012 19:08:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 583 <at> debbugs.gnu.org (full text, mbox):
8 dec 2012 kl. 13:18 skrev Eric Heintzmann <Heintzmann.Eric <at> free.fr>:
> What is planned now about FreeDesktop XDG basedir specification for Emacs?
>
>
> http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
> https://live.gnome.org/GnomeGoals/XDGConfigFolders
> http://standards.freedesktop.org/basedir-spec/latest/
Hopefully nothing, as the free desktop specs in this area keeps changing and never reach a stable state.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sat, 08 Dec 2012 19:32:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 583 <at> debbugs.gnu.org (full text, mbox):
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sat, 8 Dec 2012 20:06:34 +0100
> Cc: 583 <at> debbugs.gnu.org
>
> 8 dec 2012 kl. 13:18 skrev Eric Heintzmann <Heintzmann.Eric <at> free.fr>:
>
> > What is planned now about FreeDesktop XDG basedir specification for Emacs?
> >
> >
> > http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
> > https://live.gnome.org/GnomeGoals/XDGConfigFolders
> > http://standards.freedesktop.org/basedir-spec/latest/
>
> Hopefully nothing, as the free desktop specs in this area keeps changing and never reach a stable state.
I agree, FWIW.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Tue, 27 Aug 2019 21:59:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
ferkiwi+a <at> gmail.com
:
bug acknowledged by developer.
(Tue, 27 Aug 2019 21:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 583-done <at> debbugs.gnu.org (full text, mbox):
After discussion we added something along the suggested lines to Emacs master here:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3
so I am closing bug report number 583.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Wed, 28 Aug 2019 16:12:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 583 <at> debbugs.gnu.org (full text, mbox):
It's great to finally see some progress in this area, but IIUC this is
still not really following the XDG spec. For example, I think a proper
solution would see user elpa packages stored undo XDG_DATA_HOME, etc.
I think the OP points this out.
It looks like what we have at the moment is basically
~/.emacs.d/ -> ~/.config/emacs/?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Wed, 28 Aug 2019 16:30:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 583 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Wed, 28 Aug 2019 12:11:21 -0400
> Cc: ferkiwi+a <at> gmail.com, eggert <at> cs.ucla.edu
>
> It's great to finally see some progress in this area, but IIUC this is
> still not really following the XDG spec. For example, I think a proper
> solution would see user elpa packages stored undo XDG_DATA_HOME, etc.
Yes, because we don't set user-emacs-directory from XDG_DATA_HOME. We
only load the init files from there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Wed, 28 Aug 2019 16:51:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 583 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> It's great to finally see some progress in this area, but IIUC this is
>> still not really following the XDG spec. For example, I think a proper
>> solution would see user elpa packages stored undo XDG_DATA_HOME, etc.
>
> Yes, because we don't set user-emacs-directory from XDG_DATA_HOME. We
> only load the init files from there.
I'm not sure I've made my point.
With a proper following of the XDG spec, the concept of (a single)
"user-emacs-directory" would no longer be present. Obviously this
requires more radical changes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Wed, 28 Aug 2019 17:19:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 583 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 583 <at> debbugs.gnu.org, ferkiwi+a <at> gmail.com, eggert <at> cs.ucla.edu
> Date: Wed, 28 Aug 2019 12:50:46 -0400
>
> With a proper following of the XDG spec, the concept of (a single)
> "user-emacs-directory" would no longer be present.
I'm not sure I understand why. Can you tell more? (I know very
little about XDG.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Wed, 28 Aug 2019 18:12:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 583 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> It's great to finally see some progress in this area, but IIUC this is
> still not really following the XDG spec. For example, I think a proper
> solution would see user elpa packages stored undo XDG_DATA_HOME, etc.
> I think the OP points this out.
> It looks like what we have at the moment is basically
> ~/.emacs.d/ -> ~/.config/emacs/?
Yes, that's what Emacs basically has in master now. I don't see where Fernando
mentioned ELPA, though. And it's not clear that an ELPA package's files should
be considered "user specific data files" (XDG_DATA_HOME) as opposed to "user
specific configuration files" (XDG_CONFIG_HOME).
Looking at my own home directory for what other XDG-ish programs do, I see data
files under ~/.local/share (XDG_DATA_FILES default): things like
xorg/Xorg.0.log, gnome-shell/application_state, gvfs-metadata/home, and
evolution/addressbook/system/contacts.db. Programs (if any) are few and far
between. (Not that I use many plugins in any programs, so perhaps I'm not the
best person to check this.)
For what it's worth, I found an old directory named '~/.gimp-2.8' and a newer
one named '~/.config/GIMP/2.10' with similar structure. It appears that when
GIMP made the transition to XDG style in GIMP version 2.9.2, it did what Emacs
just did in master now: that is, GIMP moved all its stuff into ~/config/GIMP.
Although I don't use GIMP plug-ins, the GIMP plug-ins directory moved too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Thu, 29 Aug 2019 02:15:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 583 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
>> ~/.emacs.d/ -> ~/.config/emacs/?
>
> Yes, that's what Emacs basically has in master now. I don't see where
> Fernando mentioned ELPA, though.
He didn't. Elpa may not even have existed when this report was opened.
I was using it as an example.
> And it's not clear that an ELPA package's files should be considered
> "user specific data files" (XDG_DATA_HOME) as opposed to "user
> specific configuration files" (XDG_CONFIG_HOME).
It seems clear to me. They are data, not configuration. You would not
install them under /etc, but somewhere like /usr/share.
> For what it's worth, I found an old directory named '~/.gimp-2.8' and
> a newer one named '~/.config/GIMP/2.10' with similar structure. It
> appears that when GIMP made the transition to XDG style in GIMP
> version 2.9.2, it did what Emacs just did in master now: that is, GIMP
> moved all its stuff into ~/config/GIMP. Although I don't use GIMP
> plug-ins, the GIMP plug-ins directory moved too.
IMO "dump everything under ~/.config/emacs" isn't a proper
implementation, even if some other packages have done this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Thu, 29 Aug 2019 02:19:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 583 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> From: Glenn Morris <rgm <at> gnu.org>
>> Cc: 583 <at> debbugs.gnu.org, ferkiwi+a <at> gmail.com, eggert <at> cs.ucla.edu
>> Date: Wed, 28 Aug 2019 12:50:46 -0400
>>
>> With a proper following of the XDG spec, the concept of (a single)
>> "user-emacs-directory" would no longer be present.
>
> I'm not sure I understand why. Can you tell more? (I know very
> little about XDG.)
It's well documented, the link in the OP still works.
See also eg https://wiki.archlinux.org/index.php/XDG_Base_Directory
IMO a true conversion of Emacs to the XDG spec would involve the
addition of new variables (user-config-directory, user-data-directory,
user-cache-directory, etc). Each use of user-emacs-directory would have
to be reviewed to see where it actually belongs. For some, it would
probably be ambiguous.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Thu, 29 Aug 2019 06:23:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 583 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
>> And it's not clear that an ELPA package's files should be considered
>> "user specific data files" (XDG_DATA_HOME) as opposed to "user
>> specific configuration files" (XDG_CONFIG_HOME).
> It seems clear to me. They are data, not configuration. You would not
> install them under /etc, but somewhere like /usr/share.
If I understand correctly, ELPA packages are not really either "data" or
"configuration": they're software packages. And the XDG scheme doesn't appear to
be designed for installing software packages: it's designed only for user
preferences (aka configuration), user data, and information cached for the user.
If ELPA packages are just local copies from a server somewhere, it seems the
most plausible place for them is the XDG cache (XDG_CACHE_HOME, which is
~/.cache by default) rather than either in "data" or "configuration"; only the
list of downloaded packages should be placed in XDG_CONFIG_HOME. Presumably the
ELPA package manager could arrange for this.
Not being an expert in these matters, I looked at another popular packaging
scheme: Flatpak. It appears to put everything under ~/.local/share, i.e., under
XDG_DATA_HOME. This includes configuration. See
<https://github.com/flatpak/flatpak/wiki/Filesystem>.
It's quite a mess, huh?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Thu, 29 Aug 2019 07:04:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 583 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 583 <at> debbugs.gnu.org, ferkiwi+a <at> gmail.com, eggert <at> cs.ucla.edu
> Date: Wed, 28 Aug 2019 22:17:55 -0400
>
> IMO a true conversion of Emacs to the XDG spec would involve the
> addition of new variables (user-config-directory, user-data-directory,
> user-cache-directory, etc). Each use of user-emacs-directory would have
> to be reviewed to see where it actually belongs. For some, it would
> probably be ambiguous.
I'm afraid almost all of them will be ambiguous. Moreover, defining a
clear enough set of rules for where to put files that will be added in
the future is a non-trivial job, and enforcing it will not be easy. I
predict confusion and arguments.
My gut feeling is that Emacs should have one, at most 2 XDG-derived
directories, certainly not 3. And if we want to support that
correctly, these environment variables should be accessed much earlier
in the startup process, somewhere in init_callproc and friends,
because setting user-emacs-directory in startup is too late and
creates problems, as we saw already.
We've made a small step in that direction; if we want to continue that
way, someone should volunteer to do the job of defining what files
will go were.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Thu, 29 Aug 2019 08:43:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 583 <at> debbugs.gnu.org (full text, mbox):
On Wed, 28 Aug 2019 23:22:35 -0700
Paul Eggert wrote:
> If ELPA packages are just local copies from a server somewhere, it
> seems the most plausible place for them is the XDG cache
> (XDG_CACHE_HOME, which is ~/.cache by default) rather than either in
> "data" or "configuration"; only the list of downloaded packages should
> be placed in XDG_CONFIG_HOME. Presumably the ELPA package manager
> could arrange for this.
XDG_CACHE_HOME is for "non-essential data files" (quoting the spec).
Some people put it on tmpfs, so it is deleted on system restart.
> Not being an expert in these matters, I looked at another popular
> packaging scheme: Flatpak. It appears to put everything under
> ~/.local/share, i.e., under XDG_DATA_HOME. This includes
> configuration. See
> <https://github.com/flatpak/flatpak/wiki/Filesystem>.
Some programs (notably Python[1]) use ~/.local/lib/, which makes sense,
but is not part of the XDG spec.
> It's quite a mess, huh?
It is.
[1] https://www.python.org/dev/peps/pep-0370/
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Thu, 29 Aug 2019 18:32:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 583 <at> debbugs.gnu.org (full text, mbox):
BTW, I think the handling of user-emacs-directory is buggy:
rm -rf /tmp/foo
mkdir -p /tmp/foo/.config/emacs
HOME=/tmp/foo emacs
Now:
user-init-file -> /tmp/foo/.config/emacs/init
user-emacs-directory -> ~/.emacs.d/
I guess user-emacs-directory is being set at build time, not run time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Thu, 29 Aug 2019 18:36:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 583 <at> debbugs.gnu.org (full text, mbox):
PS I should have prefaced this recipe with "having built Emacs in an
environment where ~/.config/emacs does not exist".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Thu, 29 Aug 2019 18:54:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 583 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Thu, 29 Aug 2019 14:30:54 -0400
> Cc: ferkiwi <at> gmail.com, 583 <at> debbugs.gnu.org
>
> rm -rf /tmp/foo
> mkdir -p /tmp/foo/.config/emacs
> HOME=/tmp/foo emacs
>
> Now:
> user-init-file -> /tmp/foo/.config/emacs/init
> user-emacs-directory -> ~/.emacs.d/
>
> I guess user-emacs-directory is being set at build time, not run time.
It's a defconst in subr.el, and I believe one of my review comments
for the initial version of the patch was that I didn't think using
defconst for this was correct.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Fri, 30 Aug 2019 08:03:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 583 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> BTW, I think the handling of user-emacs-directory is buggy:
Yes, it is. I'll have to take a look at that. I guess we'll have to change
user-home-directory to a variable, since we can't easily determine it until
command-line runs.
Also, a good many places in the documentaiton refer to ~/.emacs.d and these need
to be updated.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Fri, 30 Aug 2019 16:19:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 583 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
>> BTW, I think the handling of user-emacs-directory is buggy:
>
> Yes, it is. I'll have to take a look at that. I guess we'll have to
> change user-home-directory to a variable, since we can't easily
> determine it until command-line runs.
>
> Also, a good many places in the documentaiton refer to ~/.emacs.d and
> these need to be updated.
IMO this means one should allow a user-defined user-emacs-directory,
which means un-wontfix'ing https://debbugs.gnu.org/15539 .
Maybe the patch in https://debbugs.gnu.org/15539#40 contains some useful ideas.
Although in hindsight an environment variable doesn't seem like the way
to go.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Fri, 30 Aug 2019 17:46:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 583 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Fri, 30 Aug 2019 12:18:40 -0400
> Cc: ferkiwi <at> gmail.com, 583 <at> debbugs.gnu.org
>
> Although in hindsight an environment variable doesn't seem like the way
> to go.
Actually, I think it does, because otherwise the user-defined value
will be noticed too late, after defcustom's that depend on it were
already recomputed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sat, 31 Aug 2019 21:53:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 583 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Glenn Morris wrote:
> I guess user-emacs-directory is being set at build time, not run time.
Thanks for reporting that. I installed the attached to fix it. I plan to follow
up soon on the other issues raised here.
[0001-Calculate-user-emacs-directory-on-startup.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sun, 01 Sep 2019 01:25:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 583 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[Responding belatedly to a 2019-07-28 review that I missed, as I was looking for
reviews in Bug#583 instead of in the emacs-devel archive. Sorry about that.]
> the test which describes in detail how Emacs finds the init
> file should be in the section by that name; otherwise it makes no
> sense to have that section in the first place. The "Init File"
> section should just mention the possible places and refer to that
> other section for the details.
I gave it a shot by installing the first attached patch, which also fixes a few
other confusions and/or inaccuracies that I spotted.
The documentation also needs to be updated to replace ~/.emacs.d, either with
~/.config/emacs or with something more general, in places where the
documentation refers to the value of user-emacs-directory. That should be fairly
mechanical, and can wait until we have the details nailed down.
>> > (defconst user-emacs-directory
> ...
> Can this be a defconst?
It's been a defconst ever since it was added to Emacs in 2007. However, the
manual has always said it's a variable and there are quite a few uses of (setq
user-emacs-directory ...) in the wild, so I installed the second attached patch
to make it a defvar.
I think the other issues in the review were addressed earlier.
[0001-Improve-documentation-for-recent-XDG-related-changes.patch (text/x-patch, attachment)]
[0002-Make-user-emacs-directory-a-variable.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sun, 01 Sep 2019 02:03:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 583 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> IMO this means one should allow a user-defined user-emacs-directory,
> which means un-wontfix'ing https://debbugs.gnu.org/15539 .
Thanks for mentioning that. I followed up in that bug report, here:
https://bugs.gnu.org/15539#109
By the way, making user-emacs-directory a variable instead of a constant has its
downsides, because if a user changes user-emacs-directory, then a lot of other
variables will keep their old values derived from the previous value of
user-emacs-directory, leading to a confusing mish-mosh of old and new behavior.
Changing user-emacs-directory works coherently only if it's done very early in
startup (which is all that Bug#15539 was asking for).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sun, 01 Sep 2019 14:39:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 583 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 31 Aug 2019 19:02:01 -0700
> Cc: 583 <at> debbugs.gnu.org
>
> Changing user-emacs-directory works coherently only if it's done very early in
> startup (which is all that Bug#15539 was asking for).
We should document what that "very early" means in practice. Does it
mean in the early-init file? or can this be done reliably in the
normal init file as well?
The problem here is that some defcustom's refer to
user-emacs-directory, and so changing the value of
user-emacs-directory after those defcustoms were computed during
startup will leave those defcustoms pointing at the old place.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sun, 01 Sep 2019 18:41:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 583 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> We should document what that "very early" means in practice. Does it
> mean in the early-init file? or can this be done reliably in the
> normal init file as well?
Sorry, I don't know. That's why I didn't document it.
> The problem here is that some defcustom's refer to
> user-emacs-directory, and so changing the value of
> user-emacs-directory after those defcustoms were computed during
> startup will leave those defcustoms pointing at the old place.
Yes, it's quite a mess.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sun, 01 Sep 2019 18:51:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 583 <at> debbugs.gnu.org (full text, mbox):
> Cc: rgm <at> gnu.org, 583 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 1 Sep 2019 11:40:21 -0700
>
> Eli Zaretskii wrote:
> > We should document what that "very early" means in practice. Does it
> > mean in the early-init file? or can this be done reliably in the
> > normal init file as well?
>
> Sorry, I don't know. That's why I didn't document it.
>
> > The problem here is that some defcustom's refer to
> > user-emacs-directory, and so changing the value of
> > user-emacs-directory after those defcustoms were computed during
> > startup will leave those defcustoms pointing at the old place.
>
> Yes, it's quite a mess.
If doing this in early-init works, I'd rather we documented that as
the canonical place that saves users from the mess.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Sun, 01 Sep 2019 23:02:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 583 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> Yes, it's quite a mess.
> If doing this in early-init works, I'd rather we documented that as
> the canonical place that saves users from the mess.
I doubt whether it even works in early-init. Not that I've tested it; I don't
use early-init and would not be a good person to delve deeper into that part of
the mess.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#583
; Package
emacs
.
(Wed, 11 Sep 2019 09:22:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 583 <at> debbugs.gnu.org (full text, mbox):
On 2019-08-31 14:51 -0700, Paul Eggert wrote:
> Glenn Morris wrote:
>> I guess user-emacs-directory is being set at build time, not run time.
>
> Thanks for reporting that. I installed the attached to fix it. I plan
> to follow up soon on the other issues raised here.
FWIW, this patch broke auto-save-list-file-prefix, at least when
user-emacs-directory is "~/.emacs.d/". See bug #37354.
,----
| auto-save-list-file-prefix is a variable defined in ‘startup.el’.
| Its value is "auto-save-list/.saves-"
| Original value was
| "~/.emacs.d/auto-save-list/.saves-"
`----
Cheers,
Sven
> From 2befb4f0a1494f699f56215d5f28ba055663d881 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 31 Aug 2019 14:47:04 -0700
> Subject: [PATCH] Calculate user-emacs-directory on startup
>
> Problem reported by Glenn Morris (Bug#583#56).
> * lisp/startup.el (startup--xdg-config-default): New constant.
> (startup--xdg-config-home-emacs): New var.
> (startup--xdg-or-homedot): New function.
> (normal-top-level): Use it to set user-emacs-directory early on.
> (command-line): Also use it to determine the startup init directory.
> * lisp/subr.el (user-emacs-directory): Just initialize to nil.
> ---
> lisp/startup.el | 51 +++++++++++++++++++++++++++++++++++++------------
> lisp/subr.el | 14 ++------------
> 2 files changed, 41 insertions(+), 24 deletions(-)
>
> diff --git a/lisp/startup.el b/lisp/startup.el
> index c1e429b8db..a16db242da 100644
> --- a/lisp/startup.el
> +++ b/lisp/startup.el
> @@ -490,6 +490,27 @@ normal-top-level-add-to-load-path
> (when tail
> (setcdr tail (append (mapcar 'expand-file-name dirs) (cdr tail))))))
>
> +;; The default location for XDG-convention Emacs init files.
> +(defconst startup--xdg-config-default "~/.config/emacs/")
> +;; The location for XDG-convention Emacs init files.
> +(defvar startup--xdg-config-home-emacs)
> +
> +;; Return the name of the init file directory for Emacs, assuming
> +;; XDG-DIR is the XDG location and USER-NAME is the user name.
> +;; If USER-NAME is nil or "", use the current user.
> +;; Prefer the XDG location unless it does does not exist and the
> +;; .emacs.d location does exist.
> +(defun startup--xdg-or-homedot (xdg-dir user-name)
> + (if (file-exists-p xdg-dir)
> + xdg-dir
> + (let ((emacs-d-dir (concat "~" user-name
> + (if (eq system-type 'ms-dos)
> + "/_emacs.d/"
> + "/.emacs.d/"))))
> + (if (file-exists-p emacs-d-dir)
> + emacs-d-dir
> + xdg-dir))))
> +
> (defun normal-top-level ()
> "Emacs calls this function when it first starts up.
> It sets `command-line-processed', processes the command-line,
> @@ -499,6 +520,14 @@ normal-top-level
> (message internal--top-level-message)
> (setq command-line-processed t)
>
> + (setq startup--xdg-config-home-emacs
> + (let ((xdg-config-home (getenv-internal "XDG_CONFIG_HOME")))
> + (if xdg-config-home
> + (concat xdg-config-home "/emacs/")
> + startup--xdg-config-default)))
> + (setq user-emacs-directory
> + (startup--xdg-or-homedot startup--xdg-config-home-emacs nil))
> +
> ;; Look in each dir in load-path for a subdirs.el file. If we
> ;; find one, load it, which will add the appropriate subdirs of
> ;; that dir into load-path. This needs to be done before setting
> @@ -1167,19 +1196,17 @@ command-line
> :error))))
>
> ;; Calculate the name of the Emacs init directory.
> - ;; This is typically equivalent to ~/.config/emacs if the user is
> - ;; following the XDG convention, and is ~INIT-FILE-USER/.emacs.d
> - ;; on other systems.
> - (setq xdg-dir (concat (or (getenv "XDG_CONFIG_HOME")
> - (concat "~" init-file-user "/.config"))
> - "/emacs/"))
> + ;; This is typically ~INIT-FILE-USER/.config/emacs unless the user
> + ;; is following the ~INIT-FILE-USER/.emacs.d convention.
> + (setq xdg-dir startup--xdg-config-home-emacs)
> (setq startup-init-directory
> - (if (file-exists-p xdg-dir)
> - xdg-dir
> - (let ((emacs-d-dir (concat "~" init-file-user "/.emacs.d/")))
> - (if (file-exists-p emacs-d-dir)
> - emacs-d-dir
> - xdg-dir))))
> + (if (or (zerop (length init-file-user))
> + (and (eq xdg-dir user-emacs-directory)
> + (not (eq xdg-dir startup--xdg-config-default))))
> + user-emacs-directory
> + ;; The name is not obvious, so access more directories to calculate it.
> + (setq xdg-dir (concat "~" init-file-user "/.config/emacs/"))
> + (startup--xdg-or-homedot xdg-dir init-file-user)))
>
> ;; Load the early init file, if found.
> (startup--load-user-init-file
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 566a3fc758..cf6fb108e9 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -2938,18 +2938,8 @@ temp-buffer-setup-hook
> mode.")
>
> (defconst user-emacs-directory
> - (let ((config-dir (concat (or (getenv-internal "XDG_CONFIG_HOME")
> - "~/.config")
> - "/emacs/")))
> - (if (file-exists-p config-dir)
> - config-dir
> - (let ((emacs-d-dir (if (eq system-type 'ms-dos)
> - ;; MS-DOS cannot have initial dot.
> - "~/_emacs.d/"
> - "~/.emacs.d/")))
> - (if (file-exists-p emacs-d-dir)
> - emacs-d-dir
> - config-dir))))
> + ;; The value does not matter since Emacs sets this at startup.
> + nil
> "Directory beneath which additional per-user Emacs-specific files are placed.
> Various programs in Emacs store information in this directory.
> Note that this should end with a directory separator.
> --
> 2.17.1
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 09 Oct 2019 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 172 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.