"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> Rodney Sparapani <rsparapa(a)mcw.edu> writes:
>
> > On 02/23/11 01:39 PM, Rodney Sparapani wrote:
> >>
> >> It's xemacs-21.5.29-12.el5.1.x86_64
> >>
<
http://download.fedora.redhat.com/pub/epel/5/x86_64/xemacs-21.5.29-12.el5...
> > I don't if this is part of the bug or not. But, there is also
> > something weird with how it interacts with .emacs If you say
> > that you don't want to migrate .emacs then it writes the
> > custom.el font settings in .emacs
This is only if you tell custom to save customizations.
It wasn't the last time I was bitten by it (long time ago). Something
was saved without explicit request IIRC. Anyway, it seems like a good
idea to figure out what happened with Rodney's installation.
Last I heard, Emacs writes *all* customizations to .emacs, not to a
special custom- only file (but I haven't paid much attention to
Emacs's customize facilities since the bug described below was fixed).
So that's what I would *expect* to happen if I (a) tell XEmacs not to
migrate and (b) proceed to customize and save customizations.
What do you expect it to do? What do you want it to do, if that's
different from what you might expect?
Look, this is a user interface trap. You ask the user whether he should
migrate .emacs. Now we imagine an Emacs user who is just taking XEmacs
for a test ride. You ask him whether you should do an obscure operation
("migrate the .emacs file"). He is just testing and does not want
permanent changes to his Emacs configuration. He does not know what
"migration" involves and whether it might render his Emacs useless. So
to be on the safe side, he says "no" and continues.
Unfortunately, the safe side is the other one. Questions that better
match the expectations and behavior of users:
"Should I attempt read/write sharing of your .emacs (not recommended)"
No-> "Should I attempt to copy your Emacs configuration?"
Yes-> "Should I make this selection permanent?"
If you say Yes, create a .xemacs/init.el file that just loads the Emacs
custom file. So if you at one point delete your .xemacs directory, you
are back to square one, modulo any customizations that landed in .emacs
when saving from XEmacs.
> If XEmacs still has the habit of destroying your .emacs file
when you
> start it even once, that is not going to win it points from Emacs users
> taking it for a test drive.
No, XEmacs has the habit of doing what it is told to do by the user.
After asking him loaded questions.
A user doing a "test drive" without migrating code from
.emacs to
.xemacs/init.el should not be saving customizations AFAICS. Why would
she?
See above. Accident waiting to happen. And if it does happen, it is a
rather awful introduction of XEmacs. Being burnt like that, people
won't try XEmacs a second time.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta