Re: Release plans [was: Building packages with 21.5b29?]

Rodney Sparapani <rsparapa(a)mcw.edu&gt; 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. 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?

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.
A user doing a "test drive" without migrating code from .emacs to
.xemacs/init.el should not be saving customizations AFAICS. Why would
she?
There was indeed a bug where if there was GNU-Emacs-specific code that
caused an error during the migration process, then the reading of the
customizations was aborted, but XEmacs would write the incomplete
customizations out to the specified file later upon request to save.
This could happen without the migration process as well, but the
migration process made it very likely that the user would save the
broken file, overwriting the good customizations. However, that was
fixed within a few days of release, just about 10 years ago. And in
fact that whole release was withdrawn and deprecated (over the
objections of other reviewers, sad to say, but it was withdrawn and
deprecated).
And in any case it required a specific request from the user to save
customizations. This is a serious design bug in Customize as
implemented by Per (ie, that the file is completely rewritten to save
any one change). I don't know if Emacs does it differently these
days, but in 2001 it was possible to get the same behavior from Emacs.
Of course it was much less likely, because if customizations were
broken enough to interrupt the initialization process, the user would
be aware, and probably would fix the initialization process by hand
without doing custom-save-all. By contrast the migration process
would blithely ask the user if he wanted to save despite the failed
initialization. As the reporter admitted, "if I had been thinking I
would have known better than to save anything since I hadn't done
anything I wanted to save", but it's equally true that if Emacs
initialization blows up in your face, you're probably not thinking
very clearly.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta