"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> It is likely a good idea to refuse even this if variables like
> custom-file, user-init-file, user-emacs-directory are changed from their
> default. At least if XEmacs interprets those variables.
> Because otherwise loading the copied .emacs file is likely to ultimately
> result in writes to original files anyway.
That's pure paranoia with no foundation in reality, David.
Sigh. When the user has
(setq custom-file "~/.emacs.d/custom.el")
in his .emacs, and you copy/migrate this setting into ~/.xemacs/.emacs
(or whatever the migration is called), then XEmacs will save
customizations into ~/.emacs.d/custom.el.
Once those variables are set (all of the logic for finding the init
file is hard-coded in the initialization), ~/.emacs is just another
file to XEmacs. There is no evidence whatsoever that (once
configured) XEmacs will make the mistake of setting user-init-file to
"~/.emacs", in at least 15 years of experience with init.el.
I am not talking about what XEmacs might do of its own accord, but what
the "migrated" .emacs will make it do if you don't check that it does
not contain settings like that.
It's also true that the *user* may become confused *if* they try
edit ~/.emacs in XEmacs. Again, that's perverse, not an easily-made
mistake, and XEmacs should not try to second-guess the user.
Well, but it seems you could use some practice second-guessing users.
XEmacs-Beta mailing list