Re: Release plans [was: Building packages with 21.5b29?]
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> It wasn't the last time I was bitten by it (long time ago). Something
> 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.
This was just anecdotal evidence of something that happened a long time
ago and that could or could not happen nowadays as far as I know.
Certainly nothing sufficient to take action on. Rodney's experience is
much more current and:
> Anyway, it seems like a good idea to figure out what happened
with
> Rodney's installation.
Yes, but given my state of knowledge, I'm going to need more
information from the people who have seen misbehavior.
Let's hope you get it.
> 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.
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.
"Safe" does not mean "I think we got sufficient code review to hazard a
guess that nothing bad happens when we rewrite the files created by
Emacs under normal circumstances" but rather "we don't rewrite files
created by Emacs" in my book. That's the safe option. Everything else
is optimistic (which is pretty much the same as delusionary with regard
to software development).
Using terms like like "migrate" which imply some irreversible action
(when in fact it is the manner to get _reversible_ behavior by confining
XEmacs' actions to a newly created directory rather than letting it
meddle with existing files if you don't watch your step) is letting the
user pick the wrong option for his intent.
> 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
yourself.
I am explaining to you how to avoid letting the user pick the choice
that has prospectively unwanted consequences for him, and you keep
telling me that everything is working as intended.
The problem is that the _user_ is not working as intended.
Unfortunately, there is no bug database for users, and XEmacs depends on
the user as a critical component in order to be of any use.
So you need to include a workaround in XEmacs to deal with the flaws in
the implementation of the user as he is a required component, but you
don't have access to his source code.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta