GNU bug report logs - #15539
24.3; setting user-emacs-directory at command line invocation

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 15539 in the body.
You can then email your comments to 15539 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Mike Carifio <carifio <at> carifio.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; setting user-emacs-directory at command line invocation
Date: Sun, 06 Oct 2013 13:08:13 -0400

-----------------------

I'd like a switch for the emacs command line, something like
--user-emacs-directory, that sets the user emacs directory on startup,
rather than hardcodes ~/.emacs.d/. So, for example:

  emacs --user-emacs-directory ~/mine.d/

Will look for the emacs init.el in ~/mine.d/init.el.

-----------------------




In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.6.4)
 of 2013-10-03 on louvi, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11303000
System Description:	Ubuntu 13.04

Configured using:
 `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
 '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
 '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
 --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  global-auto-complete-mode: t
  auto-complete-mode: t
  cua-mode: t
  tooltip-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
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> C-h v c o m m a n d l <backspace> - l i 
n e - a r g <tab> <return> ESC x r e p o r t - e m 
<tab> <return>

Recent messages:
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done
Loading /home/mcarifio/.emacs.d/lib/libemacs.el (source)...done
(lambda (a b) ...) quoted with ' rather than with #'
For information about GNU Emacs and the GNU system, type C-h C-a.
command-line-1: Unknown option `--user-emacs-directory'
Type C-x 1 to delete the help window.

Load-path shadows:
/usr/share/emacs/24.3/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/24.3/site-lisp/cmake-data/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs24/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/24.3/lisp/textmodes/flyspell
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/24.3/lisp/textmodes/rst
/usr/share/emacs24/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/24.3/lisp/textmodes/ispell
/home/mcarifio/.emacs.d/elpa/flymake-0.4.13/flymake hides /usr/share/emacs/24.3/lisp/progmodes/flymake
/home/mcarifio/.emacs.d/elpa/sunrise-commander-20121024.2042/.dir-locals hides /usr/share/emacs/24.3/lisp/gnus/.dir-locals

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils help-mode easymenu auto-complete-config
go-autocomplete auto-complete edmacro kmacro popup
auto-complete-autoloads flymake-go-autoloads flymake-autoloads
flymake-jshint-autoloads gist-autoloads gh-autoloads eieio byte-opt
bytecomp byte-compile cconv go-mode-autoloads
graphviz-dot-mode-autoloads js-comint-autoloads js2-mode-autoloads
logito-autoloads multi-term-autoloads nginx-mode-autoloads
nose-autoloads pcache-autoloads finder-inf popup-autoloads
sunrise-commander-autoloads package uniquify advice help-fns
advice-preload cl-macs gv cl cl-lib cua-base devhelp time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

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

From: François Févotte <francois.fevotte <at> ensta.org>
To: 15539 <at> debbugs.gnu.org
Subject: Setting user-emacs-directory at command line invocation
Date: Fri, 13 Mar 2015 16:01:55 +0100

[Message part 1 (text/plain, inline)]

Hello,

attached is a patch which tries to implement the desired feature. It should
apply cleanly atop master (b91eafe31a524b391d5cec079cf8f36c2f9d5f30)

With this patch, emacs accepts a new command line argument:
    --user-emacs-directory=DIR
which has two effects:
1. it sets the `user-emacs-directory' variable to DIR (instead of the
default "~/.emacs.d")
2. it looks for the init file in DIR/init.el (and only there: ~/.emacs & co
are bypassed)

This doesn't impact anything else in emacs' startup sequence.

Implementationwise, I'm not very proud of having to define a new global
variable, but I fail to see how to do otherwise, except maybe wrapping the
whole `command-line' function in a let form to use a local binding.

Please do not hesitate to criticize or ask me for any modification which
would be desirable. This is the first patch I propose to emacs; I don't
expect to have it right on the first try.

Thanks in advance,

    François

[Message part 2 (text/html, inline)]

[0001-Add-a-user-emacs-directory-command-line-option.patch (text/x-patch, attachment)]

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

From: Glenn Morris <rgm <at> gnu.org>
To: François Févotte <francois.fevotte <at> ensta.org>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: Setting user-emacs-directory at command line invocation
Date: Sun, 15 Mar 2015 20:36:53 -0400

François Févotte wrote:

> Implementationwise, I'm not very proud of having to define a new global
> variable,

I'm not saying it's the right solution, but you could use an environment
variable (eg EMACS_USER_DIRECTORY) rather than a command-line switch to
control this. This would be consistent with eg EMACSDATA, and also I
think with how other applications normally let you control where they
look for their init files (?). But on the other hand, environment
variables can be easier to overlook than explicit flags eg when
debugging.

On the other other hand, the OP could just do

ln -s mine.d .emacs.d

so I'm not sure what the point of this feature would be, unless eg you
frequently want to swap between different .emacs.d's?

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

From: François Févotte <francois.fevotte <at> ensta.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: Setting user-emacs-directory at command line invocation
Date: Mon, 16 Mar 2015 08:28:47 +0100

Hi,

thanks for your comment.

On Mon, Mar 16, 2015 at 1:36 AM, Glenn Morris <rgm <at> gnu.org> wrote:
> I'm not saying it's the right solution, but you could use an environment
> variable (eg EMACS_USER_DIRECTORY) rather than a command-line switch to
> control this. This would be consistent with eg EMACSDATA, and also I
> think with how other applications normally let you control where they
> look for their init files (?). But on the other hand, environment
> variables can be easier to overlook than explicit flags eg when
> debugging.

Yes, you're right, this is a very good idea. I'll develop a new patch
for this as soon as I can.


> On the other other hand, the OP could just do
>
> ln -s mine.d .emacs.d
>
> so I'm not sure what the point of this feature would be, unless eg you
> frequently want to swap between different .emacs.d's?

I'm not sure about the OP's use case, but I can tell about mine: at
work, I try to maintain a sensible set of init files for my co-workers
to use (with the very outdated default version that we have installed
by default on our systems: 23.2). On the other hand, on my machine, I
maintain a locally-installed Emacs version that is more up-to-date. In
order to maintain both sets of init files, I need to be able to run
both versions of Emacs at the same time, which prevents me from
symlinking ~/.emacs.d/

There are reddit and stackexchange questions hinting at the same kind of use:

http://www.reddit.com/r/emacs/comments/2y1b3a/how_can_i_easily_keep_different_emacsd_folders/
http://emacs.stackexchange.com/q/4253/221


Since these questions concern a broader audience, do you think that we
should add emacs-devel to this discussion?

Thanks,

François

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

From: François Févotte <francois.fevotte <at> ensta.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: Setting user-emacs-directory at command line invocation
Date: Tue, 17 Mar 2015 11:08:47 +0100

[Message part 1 (text/plain, inline)]

On Mon, Mar 16, 2015 at 1:36 AM, Glenn Morris <rgm <at> gnu.org> wrote:
> I'm not saying it's the right solution, but you could use an environment
> variable (eg EMACS_USER_DIRECTORY) rather than a command-line switch to
> control this.

Attached is a new patch implementing this idea. The differences with
respect to the first version are:

1- `user-emacs-directory' is read in the `EMACS_USER_DIRECTORY'
environment variable instead of from the command-line;

2- a few custom variables are declared in
`custom-delayed-init-variables' in order to account for the new value
of `user-emacs-directory'.

Once again, please don't hesitate to comment.

    François

[0001-Look-for-an-EMACS_USER_DIRECTORY-environment-variabl.patch (text/x-patch, attachment)]

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

From: François Févotte <francois.fevotte <at> ensta.org>
To: emacs-devel <at> gnu.org, 15539 <at> debbugs.gnu.org
Subject: Re: [PATCH] Setting user-emacs-directory
Date: Wed, 1 Apr 2015 17:24:03 +0200

Hello,

On Tue, Mar 24, 2015 at 12:25 AM, François Févotte <fevotte <at> gmail.com> wrote:
> below is a patch trying to address old bug #15539.

after the lack of reaction to my last email, I would like to have one
more chance of getting emacs-devel's feedback on this issue (namely:
being able to tell Emacs where to find its init file).

Is nobody interested in this feature?  Or is the proposed patch not adequate?
In the former case, please just say so, so that we can maybe mark the
bug as "wontfix" and let it be clear.  In the latter case, I'm still
welcoming any comment on the proposed solution.  And of course I'm
willing to work on any improvement you might suggest.

Thanks in advance,
   François

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

From: Oleh Krehel <ohwoeowho <at> gmail.com>
To: François Févotte <francois.fevotte <at> ensta.org>
Cc: 15539 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: [PATCH] Setting user-emacs-directory
Date: Wed, 01 Apr 2015 17:38:21 +0200

François Févotte <francois.fevotte <at> ensta.org> writes:

> Hello,
>
> On Tue, Mar 24, 2015 at 12:25 AM, François Févotte <fevotte <at> gmail.com> wrote:
>> below is a patch trying to address old bug #15539.
>
> after the lack of reaction to my last email, I would like to have one
> more chance of getting emacs-devel's feedback on this issue (namely:
> being able to tell Emacs where to find its init file).
>
> Is nobody interested in this feature?  Or is the proposed patch not adequate?
> In the former case, please just say so, so that we can maybe mark the
> bug as "wontfix" and let it be clear.  In the latter case, I'm still
> welcoming any comment on the proposed solution.  And of course I'm
> willing to work on any improvement you might suggest.

I'm interested in this feature, I just didn't have time to test it yet.
I'll try to look at it soon.

Oleh

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Oleh Krehel <ohwoeowho <at> gmail.com>, François Févotte
 <francois.fevotte <at> ensta.org>
Cc: 15539 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: RE: [PATCH] Setting user-emacs-directory
Date: Wed, 1 Apr 2015 08:49:32 -0700 (PDT)

> I'm interested in this feature, I just didn't have time to test it yet.
> I'll try to look at it soon.

Can y'all please drop one of the mailing lists (e.g. emacs-devel)?  Thx.

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

From: Oleh Krehel <ohwoeowho <at> gmail.com>
To: François Févotte <francois.fevotte <at> ensta.org>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Wed, 01 Apr 2015 18:48:52 +0200

Oleh Krehel <ohwoeowho <at> gmail.com> writes:

> François Févotte <francois.fevotte <at> ensta.org> writes:
>
>> Hello,
>>
>> On Tue, Mar 24, 2015 at 12:25 AM, François Févotte <fevotte <at> gmail.com> wrote:
>>> below is a patch trying to address old bug #15539.
>>
>> after the lack of reaction to my last email, I would like to have one
>> more chance of getting emacs-devel's feedback on this issue (namely:
>> being able to tell Emacs where to find its init file).
>>
>> Is nobody interested in this feature?  Or is the proposed patch not adequate?
>> In the former case, please just say so, so that we can maybe mark the
>> bug as "wontfix" and let it be clear.  In the latter case, I'm still
>> welcoming any comment on the proposed solution.  And of course I'm
>> willing to work on any improvement you might suggest.
>
> I'm interested in this feature, I just didn't have time to test it yet.
> I'll try to look at it soon.

OK, I've tested it and it works great. I vote for merging this if
someone is counting.

Just one question: why is `getenv' called twice?

Oleh

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

From: François Févotte <francois.fevotte <at> ensta.org>
To: Oleh Krehel <ohwoeowho <at> gmail.com>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Wed, 1 Apr 2015 19:16:36 +0200

Thanks for testing

On Wed, Apr 1, 2015 at 6:48 PM, Oleh Krehel <ohwoeowho <at> gmail.com> wrote:
> Just one question: why is `getenv' called twice?

with the currently implemented logic, the environment variable has two
different impacts: (1) it sets the `user-emacs-directory' variable,
and (2) it changes the logic used to determine the init file. There is
currently no `let' form encompassing the whole `command-line'
function, so I had to either
1- add one (which might be the most correct implementation, but
generates a very large patch for mostly unchanged lines)
2- define a global variable (which seems unnecessary), or
3- call `getenv' multiple times.

I chose the latter, but am perfectly open to rewriting the
implementation if you feel it would be better.

    François

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: François Févotte <francois.fevotte <at> ensta.org>
Cc: 15539 <at> debbugs.gnu.org, Oleh Krehel <ohwoeowho <at> gmail.com>
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Wed, 01 Apr 2015 17:03:30 -0400

> 1- add one (which might be the most correct implementation, but
> generates a very large patch for mostly unchanged lines)

That's the better option.
You can ask diff to ignore whitespace changes, which keeps the patch readable.


        Stefan

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

From: François Févotte <francois.fevotte <at> ensta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15539 <at> debbugs.gnu.org, Oleh Krehel <ohwoeowho <at> gmail.com>
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Thu, 2 Apr 2015 10:12:01 +0200

[Message part 1 (text/plain, inline)]

Here is a new version introducing a `let' form spanning everything
needed.  There is no need for two calls to `getenv' anymore.
I've attached the patch in two versions: with and without whitespace
changes (git diff -b), to make it easier to review.


Thanks,
   François

On Wed, Apr 1, 2015 at 11:03 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> 1- add one (which might be the most correct implementation, but
>> generates a very large patch for mostly unchanged lines)
>
> That's the better option.
> You can ask diff to ignore whitespace changes, which keeps the patch readable.
>
>
>         Stefan

[EMACS_USER_DIRECTORY-nowhitespace.patch (text/x-patch, attachment)]

[EMACS_USER_DIRECTORY.patch (text/x-patch, attachment)]

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

From: Alexis <flexibeast <at> gmail.com>
To: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Mon, 15 Feb 2016 21:31:23 +1100

Ping!

Someone on reddit recently enquired about the status of this 
issue:

https://www.reddit.com/r/emacs/comments/44ojpk/interpreting_the_emacs_bug_list_what_was/

Are there any particular things blocking this patch from being 
applied?


Alexis.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexis <flexibeast <at> gmail.com>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Mon, 15 Feb 2016 16:15:38 +0200

> From: Alexis <flexibeast <at> gmail.com>
> Date: Mon, 15 Feb 2016 21:31:23 +1100
> 
> 
> Ping!
> 
> Someone on reddit recently enquired about the status of this 
> issue:
> 
> https://www.reddit.com/r/emacs/comments/44ojpk/interpreting_the_emacs_bug_list_what_was/
> 
> Are there any particular things blocking this patch from being 
> applied?

Frankly, I don't think there are important enough use cases behind
this request to add yet another option that allows to change a
well-established constant.  But that's me.  (Didn't see any
enthusiastic reactions from others, either.  Not sure what that
means.)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15539 <at> debbugs.gnu.org, Alexis <flexibeast <at> gmail.com>
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Wed, 24 Feb 2016 15:03:31 +1100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alexis <flexibeast <at> gmail.com>
>> Date: Mon, 15 Feb 2016 21:31:23 +1100
>> 
>> 
>> Ping!
>> 
>> Someone on reddit recently enquired about the status of this 
>> issue:
>> 
>> https://www.reddit.com/r/emacs/comments/44ojpk/interpreting_the_emacs_bug_list_what_was/
>> 
>> Are there any particular things blocking this patch from being 
>> applied?
>
> Frankly, I don't think there are important enough use cases behind
> this request to add yet another option that allows to change a
> well-established constant.  But that's me.  (Didn't see any
> enthusiastic reactions from others, either.  Not sure what that
> means.)

I think it might make sense...  it might make some debugging and testing
cases easier, for instance.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15539 <at> debbugs.gnu.org, flexibeast <at> gmail.com
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Wed, 24 Feb 2016 19:15:45 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Alexis <flexibeast <at> gmail.com>,  15539 <at> debbugs.gnu.org
> Date: Wed, 24 Feb 2016 15:03:31 +1100
> 
> > Frankly, I don't think there are important enough use cases behind
> > this request to add yet another option that allows to change a
> > well-established constant.  But that's me.  (Didn't see any
> > enthusiastic reactions from others, either.  Not sure what that
> > means.)
> 
> I think it might make sense...  it might make some debugging and testing
> cases easier, for instance.

You mean, the need to temporarily point HOME to some other place?  Is
that really so problematic as to require yet another knob in Emacs?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15539 <at> debbugs.gnu.org, flexibeast <at> gmail.com
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Thu, 25 Feb 2016 16:18:37 +1030

Eli Zaretskii <eliz <at> gnu.org> writes:

>> I think it might make sense...  it might make some debugging and testing
>> cases easier, for instance.
>
> You mean, the need to temporarily point HOME to some other place?  Is
> that really so problematic as to require yet another knob in Emacs?

Yeah, that's true.  HOME is easy to switch around, so it doesn't make
much sense to offer this extra knob.

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

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

From: François Févotte <francois.fevotte <at> ensta.org>
To: 15539 <at> debbugs.gnu.org
Subject: Fwd: bug#15539: [PATCH] Setting user-emacs-directory
Date: Thu, 24 Mar 2016 20:21:31 +0100

Dear Emacs developers,

sorry for the late reaction: I thought I was subscribed to this bug, but I
somehow wasn't and only just saw last month's discussions.

I fully understand that putting yet another knob in Emacs implies an added
complexity which is not necessarily desirable. However, I would like to
emphasize that the proposed patch does not "change a well-established
constant". People not wanting to know about this new behavior will never see
any change. And I would expect that any user explicitly setting an
`EMACS_USER_DIRECTORY' environment variable know what they are doing.

Also, below is a list of methods (that I know of) which can help users start
Emacs with an initialization file in a custom location. None of them are
flawless, which justifies IMHO the introduction of a feature like the one
proposed here. But even if you still find that there is no real need for such a
feature (which would be perfectly fine by me), at least this list might help
future users stumbling on this bug report...


* Method 1 (as mentioned by Eli Zaretskii above): set the HOME environment
  variable.

  This works well, and can even be set on a per-process basis, which is a
  desirable feature IMO.  This method however has potentially unwelcome side
  effects, mainly related to the fact that $HOME is used in a lot of different
  contexts, unrelated to the Emacs startup process. In particular:

  - All processes launched from within Emacs will inherit this setting. This can
    easily be avoided be re-setting HOME to its normal value in
    `process-environment' within Emacs.

  - All paths beginning with `~/' will be expanded to the "fake" HOME directory,
    which can be confusing. One can reset the HOME environment variable from
    within Emacs using `setenv' to avoid that. But then problems can arise since
    `user-emacs-directory' itself is by default "~/.emacs.d".


* Method 2: set a symbolic link from ~/.emacs.d to somewhere else.

  This method is mainly useful to help quickly switch between different profiles
  by having the symlink point to one of several possible directories.
It's very easy
  to set up (which is why many users seem to do it), but has the main drawback
  that multiple Emacs instances running concurrently must all share the same
  user directory.


* Method 3: run `emacs -q -l SOMEWHERE/init.el'

  The initialization file located SOMEWHERE/init.el can then set things up
  correctly like this:

    (setq user-init-file (or load-file-name (buffer-file-name)))
    (setq user-emacs-directory (file-name-directory user-init-file))

  Like the first method above, this one works on a per-process basis and one can
  run different instances of Emacs using different user directories.

  The main drawback of this approach is that it entirely bypasses the normal
  startup process. Things like `emacs-init-time', `after-init-hook',
  `initial-major-mode' (list is not exhaustive) don't work as expected.


Again, I you feel like the added complexity is not worth the extra flexibility
for users, that's fine by me. Just ignore my message and leave the bug closed.

Cheers,
    François

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

From: John Wiegley <jwiegley <at> gmail.com>
To: François Févotte <francois.fevotte <at> ensta.org>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: Fwd: bug#15539: [PATCH] Setting user-emacs-directory
Date: Sat, 26 Mar 2016 17:37:45 -0700

[Message part 1 (text/plain, inline)]

>>>>> François Févotte <francois.fevotte <at> ensta.org> writes:

> Again, I you feel like the added complexity is not worth the extra
> flexibility for users, that's fine by me. Just ignore my message and leave
> the bug closed.

I'd personally like to avoid the extra complexity. One can always specify
one's init file directly, change `user-emacs-directory' immediately upon load,
and then manually alter the load path. So, it's not that you *can't* make
dynamically variable initialization directories, it's just not *convenient*.

That being the case, unless more users request this, I think we'd be solving a
problem most people aren't sensitive to, while those few who are DO have a way
to address their needs.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[signature.asc (application/pgp-signature, inline)]

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

From: François Févotte <francois.fevotte <at> ensta.org>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: Fwd: bug#15539: [PATCH] Setting user-emacs-directory
Date: Sun, 27 Mar 2016 11:46:41 +0200

> I'd personally like to avoid the extra complexity.

OK, thanks a lot for the answer. I'll keep using manual solutions to
circumvent this issue, and maybe try to provide somewhere
semi-automated ways to do this to help other users who might have the
same needs.

And also thanks for all your work on Emacs.

Cheers,
   François

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

From: Max <maxim.suraev <at> campus.tu-berlin.de>
To: 15539 <at> debbugs.gnu.org
Subject: comment
Date: Thu, 3 Nov 2016 23:32:01 +0100

As an Emacs user I would like to kindly request you to reconsider this bug.

I think that the added complexity (look at the patch size, and even that is more
comments than code) is more than justified by the convenience it adds. Yes, there are
some workarounds which are either cumbersome (like fiddling with symlinks) or break
things (like adjusting $HOME). Using straightforward approach is better because it's
100% backward-compatible, easy to use and aligns well with user expectations (many
other programs allow you to override default config location with environment variable).

best regards,
Max.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Max <maxim.suraev <at> campus.tu-berlin.de>
Cc: 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: comment
Date: Fri, 04 Nov 2016 09:28:50 +0200

> From: Max <maxim.suraev <at> campus.tu-berlin.de>
> Date: Thu, 3 Nov 2016 23:32:01 +0100
> 
> As an Emacs user I would like to kindly request you to reconsider this bug.
> 
> I think that the added complexity (look at the patch size, and even that is more
> comments than code) is more than justified by the convenience it adds.

The "complexity" mentioned in the discussion of this bug did not
allude to the size or complexity of the patch, it alluded to the
complexity this would add to Emacs and its development/maintenance:
where previously user-emacs-directory and the directory pointed to by
HOME in the environment were one and the same, now they will not be.

I think if we want to revisit this issue, we should come up with the
use cases where this feature would be useful, and see if they are
important enough to justify the price.  AFAIR, no use cases were
provided with the original request.

Thanks.

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

From: Evgeny Roubinchtein <zhenya1007 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Max <maxim.suraev <at> campus.tu-berlin.de>, 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: comment
Date: Fri, 4 Nov 2016 08:42:48 -0400

[Message part 1 (text/plain, inline)]

Just out of curiosity: is being compliant with the XDG Base Directory
Specification out-of-the-box (
https://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html)
currently viewed as a non-goal for Emacs?  (The emphasis being on
"out-of-the-box").

On Fri, Nov 4, 2016 at 3:28 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Max <maxim.suraev <at> campus.tu-berlin.de>
> > Date: Thu, 3 Nov 2016 23:32:01 +0100
> >
> > As an Emacs user I would like to kindly request you to reconsider this
> bug.
> >
> > I think that the added complexity (look at the patch size, and even that
> is more
> > comments than code) is more than justified by the convenience it adds.
>
> The "complexity" mentioned in the discussion of this bug did not
> allude to the size or complexity of the patch, it alluded to the
> complexity this would add to Emacs and its development/maintenance:
> where previously user-emacs-directory and the directory pointed to by
> HOME in the environment were one and the same, now they will not be.
>
> I think if we want to revisit this issue, we should come up with the
> use cases where this feature would be useful, and see if they are
> important enough to justify the price.  AFAIR, no use cases were
> provided with the original request.
>
> Thanks.
>
>
>
>

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Evgeny Roubinchtein <zhenya1007 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 15539 <at> debbugs.gnu.org,
 Max <maxim.suraev <at> campus.tu-berlin.de>
Subject: Re: bug#15539: comment
Date: Fri, 4 Nov 2016 08:55:28 -0400

On Fri, Nov 4, 2016 at 8:42 AM, Evgeny Roubinchtein
<zhenya1007 <at> gmail.com> wrote:
> Just out of curiosity: is being compliant with the XDG Base Directory
> Specification out-of-the-box
> (https://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html)
> currently viewed as a non-goal for Emacs?  (The emphasis being on
> "out-of-the-box").

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=583 - some skepticism
More recent effort:
https://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00167.html -
seems to have stalled.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Evgeny Roubinchtein <zhenya1007 <at> gmail.com>
Cc: maxim.suraev <at> campus.tu-berlin.de, 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: comment
Date: Fri, 04 Nov 2016 15:59:52 +0200

> From: Evgeny Roubinchtein <zhenya1007 <at> gmail.com>
> Date: Fri, 4 Nov 2016 08:42:48 -0400
> Cc: Max <maxim.suraev <at> campus.tu-berlin.de>, 15539 <at> debbugs.gnu.org
> 
> Just out of curiosity: is being compliant with the XDG Base Directory Specification out-of-the-box
> (https://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html) currently viewed as a non-goal for
> Emacs? (The emphasis being on "out-of-the-box").

I don't think there's any decision about that, either way.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: maxim.suraev <at> campus.tu-berlin.de, 15539 <at> debbugs.gnu.org,
 Evgeny Roubinchtein <zhenya1007 <at> gmail.com>
Subject: Re: bug#15539: comment
Date: Wed, 14 Dec 2016 13:43:58 -0500

I think the case for adding this feature has been very well made in

https://debbugs.gnu.org/15539#66

and others, and personally I think it seems worth adding.

See also https://debbugs.gnu.org/25163, esp #47 and #50.

(I'd also like to see support for an XDG-style layout as an option (the
default is another matter), compared to which this is very small beer.)

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 15539 <at> debbugs.gnu.org
Cc: Glenn Morris <rgm <at> gnu.org>, Max <maxim.suraev <at> campus.tu-berlin.de>,
 Mike Carifio <carifio <at> carifio.org>, Evgeny Roubinchtein <zhenya1007 <at> gmail.com>,
 François Févotte <francois.fevotte <at> ensta.org>,
 John Wiegley <jwiegley <at> gmail.com>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>,
 Oleh Krehel <ohwoeowho <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 Alexis <flexibeast <at> gmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Sat, 31 Aug 2019 18:56:17 -0700

Glenn Morris mentioned Bug#15539's user-emacs-directory issue here:

https://bugs.gnu.org/583#68

... so this email is giving you a heads-up that I recently installed a patch 
into GNU Emacs master that should allow something approximating Bug#15539's 
requested behavior. For example, one can run Emacs like this:

XDG_CONFIG_HOME=/home/rms/.config emacs

to employ user rms's Emacs configuration, instead of your configuration.

The patch I installed did not do anything special to fix bug#15539, as the new 
Emacs behavior is a natural fallout of supporting the XDG spec's requirements 
for XDG_CONFIG_HOME.

This all assumes people are using the XDG-conforming locations for config files, 
which I hope is good enough since older Emacs obviously wasn't meeting the 
Bug#15539 need anyway.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: François Févotte <francois.fevotte <at> ensta.org>,
 Max <maxim.suraev <at> campus.tu-berlin.de>, Mike Carifio <carifio <at> carifio.org>,
 Evgeny Roubinchtein <zhenya1007 <at> gmail.com>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>, 15539 <at> debbugs.gnu.org,
 Oleh Krehel <ohwoeowho <at> gmail.com>, John Wiegley <jwiegley <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Alexis <flexibeast <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Mon, 02 Sep 2019 19:45:06 -0400

Paul Eggert wrote:

> ... so this email is giving you a heads-up that I recently installed a
> patch into GNU Emacs master that should allow something approximating
> Bug#15539's requested behavior. For example, one can run Emacs like
> this:
>
> XDG_CONFIG_HOME=/home/rms/.config emacs
>
> to employ user rms's Emacs configuration, instead of your configuration.

This is an improvement, but it is not a proper solution to #15539, for
some of the same reasons that "just change HOME" wasn't. XDG_CONFIG_HOME
is not an Emacs-specific variable, so changing it will impact other
things that may be called from within Emacs.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: François Févotte <francois.fevotte <at> ensta.org>,
 Max <maxim.suraev <at> campus.tu-berlin.de>, Mike Carifio <carifio <at> carifio.org>,
 Evgeny Roubinchtein <zhenya1007 <at> gmail.com>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>, 15539 <at> debbugs.gnu.org,
 Oleh Krehel <ohwoeowho <at> gmail.com>, John Wiegley <jwiegley <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Alexis <flexibeast <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Mon, 2 Sep 2019 23:29:03 -0700

Glenn Morris wrote:
> XDG_CONFIG_HOME
> is not an Emacs-specific variable, so changing it will impact other
> things that may be called from within Emacs.

True, but it should suffice for many use cases mentioned in Bug#15539. Of the 
cases mentioned here:

https://bugs.gnu.org/15539#66

XDG_HOME should suffice for most of issues mentioned. Not all: for example, 
overriding XDG_CONFIG_HOME overrides Gtk configuration, font configuration, and 
other settings covered by the XDG convention, whereas one might want to override 
just ~/.config/emacs. But it strikes me that this is often just as much of a 
feature as a drawback, since Gtk etc. configurations influence Emacs so much 
that they really ought to be saved/restored when one is thinking of 
saving/restoring Emacs settings.

One might have a situation where one wants to vary (or save) files traditionally 
kept in ~/.emacs.d/, and no other files. But it's also quite plausible that one 
will want some of those files and not others, just as one might want 
~/.config/emacs and ~/.config/fontconfig but not ~/.config/gtk-3.0. And it's 
unlikely that a single option will have all the fine-grained control that one 
would need for all these situations. Instead, it's probably better just to 
suggest to people that they set up $HOME (or perhaps $XDG_CONFIG_HOME) to point 
to a directory full of configurations that are just they way they like it.

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

From: Mike Carifio <carifio <at> carifio.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Glenn Morris <rgm <at> gnu.org>
Cc: François Févotte <francois.fevotte <at> ensta.org>,
 Max <maxim.suraev <at> campus.tu-berlin.de>,
 Evgeny Roubinchtein <zhenya1007 <at> gmail.com>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>, 15539 <at> debbugs.gnu.org,
 Oleh Krehel <ohwoeowho <at> gmail.com>, John Wiegley <jwiegley <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Alexis <flexibeast <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Sun, 8 Sep 2019 10:54:17 -0400

As the OP approximately six years ago, I neglected to add the "use-case" 
I wanted --user-emacs-directory for, namely to experiment with 
~/.emacs.d/init.el including installing new packages via elpa. I still 
think there's a need, especially as the number of useful packages have 
grown and they can interact. I currently use the "symlink" approach when 
I want to start adding new packages and configurations. It's useful to 
return to a "known good state" if my init.el hacking careens off the 
tracks. Since there was already a _variable_ user-emacs-directory, I 
thought I was just asking to set it early at the command line. It seemed 
to be analogous to --load for an emacs file or --user for another user's 
init file. I didn't realize it had a "read-only" flavor.

Yes, this switch adds another knob, but I happen to think its a useful 
knob and is consistent with --load and --user, both of which allow the 
user to designate a different init file at the command line. Redefining 
HOME at the command line and then "setting it back" inside init.el seems 
convoluted. It could also potentially break site-start.el if some code 
there relied on the right binding of HOME. Admittedly that's a 
farfetched scenario, but not impossible either. Sure would be confusing 
to debug if you didn't know what to look for. All the "do it yourself" 
strategies (other than symlink) also force the user to deeply understand 
the details of the init process, e.g. what switches to throw to override 
various features. So if the criticism is "yet another knob" I would say 
you are pushing people to construct homegrown solutions ... repeatedly.

The XDG patch will let emacs adhere to the XDG desktop conventions and 
you can designate the user-emacs-directory implicitly as well, a 
two-for-one special. Not every platform follows the XDG conventions, but 
I personally mostly use linux, so I'm less concerned with those.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alexis <flexibeast <at> gmail.com>, Glenn Morris <rgm <at> gnu.org>,
 Max <maxim.suraev <at> campus.tu-berlin.de>, Mike Carifio <carifio <at> carifio.org>,
 François Févotte <francois.fevotte <at> ensta.org>,
 Evgeny Roubinchtein <zhenya1007 <at> gmail.com>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>,
 John Wiegley <jwiegley <at> gmail.com>, Oleh Krehel <ohwoeowho <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 15539 <at> debbugs.gnu.org
Subject: Re: bug#15539: [PATCH] Setting user-emacs-directory
Date: Thu, 13 Aug 2020 13:06:33 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> One might have a situation where one wants to vary (or save) files
> traditionally kept in ~/.emacs.d/, and no other files. But it's also
> quite plausible that one will want some of those files and not others,
> just as one might want ~/.config/emacs and ~/.config/fontconfig but
> not ~/.config/gtk-3.0. And it's unlikely that a single option will
> have all the fine-grained control that one would need for all these
> situations. Instead, it's probably better just to suggest to people
> that they set up $HOME (or perhaps $XDG_CONFIG_HOME) to point to a
> directory full of configurations that are just they way they like it.

So I think the conclusion to this long thread was that we don't want to
add a specific switch for this, and instead people can say
"XDG_CONFIG_HOME=/whatever emacs" when they want to change these paths.
So I'm closing this bug report.

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

Previous Next

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