David Kastrup writes:
It wasn't the last time I was bitten by it (long time ago).
was saved without explicit request IIRC.
Well, if so, that's a bug. But I've reviewed that code several times
(long ago), and don't know how that could happen. So ... without a
reproduction recipe ... I'm stuck.
Anyway, it seems like a good idea to figure out what happened with
Yes, but given my state of knowledge, I'm going to need more
information from the people who have seen misbehavior.
Look, this is a user interface trap. You ask the user whether he
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.
Thing is, as currently structured, any attempt to save customizations
could do that, because it rewrites the whole file and doesn't keep
backups. So what it comes down to is that in the past migration had a
bad bug. Maybe it does now, too, but I don't know about it yet.
So to be on the safe side, he says "no" and continues.
Unfortunately, the safe side is the other one.
Not as far as I know. Despite this report, the jury is still out
until I know how it happened.
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.
Er, AFAIK that's precisely what happens if you migrate, except that no
Custom customizations will land in .emacs at all, which goes one
better, since you can't screw up Emacs with XEmacs-specific
customizations unless you write code yourself, which generally (though
not always) indicates you know enough about what you're doing to save
> No, XEmacs has the habit of doing what it is told to do by the
After asking him loaded questions.
What's loaded about the question? Really, David, a bug is a bug. If
you don't want bugs in your software to ever destroy your data, don't
turn the workstation on.
> A user doing a "test drive" without migrating code
from .emacs to
> .xemacs/init.el should not be saving customizations AFAICS. Why would
See above. Accident waiting to happen.
How? As I said, it theoretically *can* happen in normal usage,
because of the way customize behaves when saving. Isn't that an
accident waiting to happen, too? Should we disable customize and
force users to write all customizations by hand in Lisp?
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.
Well, yes, I know that. On the other hand, the judgment of the folks
who made the decision was that people who have lots of customizations
won't try XEmacs without some help in migrating their customizations.
I'm not going to second-guess them until I have reason to believe that
bad things are definitely happening.
Messing with somebody's init files is definitely a Bad Thing, and most
users would go farther, it's a VERY BAD THING. If this were happening
very often, I would think we would have heard about it. But in fact
this is the first report since Alan Mackenzie's that I can remember.
Maybe I missed yours.
XEmacs-Beta mailing list