Re: user-controlled load-path extension: load-dir

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > There's a lot of "daddy knows best" packed in your definition, isn't
 > there?

Of course.  That's what a maintainer does, make these kinds of
decisions about what's best for everybody.  That is the point of view
I'm taking, not trying to evaluate the feature on its own terms.

 > I have not advocated [automatically installing and loading code]
 > and am against it; if I implied otherwise I apologize for the
 > misunderstanding.  el-get's *bootstrap* may reside in the load-dir,
 > but all the packages it manages won't.

>From the maintainer's point of view, this is *not about you*.  You
have restrained requirements for the feature, yes.  How do you propose
to impose *your* restraints on *others* who want additional features,
though?

 > SJT> Again, *this is not theory*.  This is based on more than a decade
 > SJT> of experience with such systems in XEmacs.  Users do *not* view
 > SJT> this as "oh, I messed up again".  They view it as "if Emacs is not
 > SJT> going to do it right, it should tell me to do it myself."
 > 
 > I view it as "I enabled the load-dir feature, maybe I should understand
 > it."

Again, how do you propose to get all other users to view it that way?
If this is only for you, you already know how to do it.  Obviously,
you expect this to be used by many people.  It needs to meet their
expectations as well as yours, or it's a bad idea to maintain it in
core.

It is my opinion, based on experience, that requests for more
automation will come up over and over again.  Similarly, requests for
support when code that users throw into the pot conflicts with code
already there will come up over and over again.  I don't think this
feature is worth inducing those requests, that's all.

 > You keep insisting on holding the user's hand.

No.  I'm anticipating what *some* users are going to expect of it,
based on experience with maintaining similar features.  I wouldn't
hold the user's hand in this case, I'd simply insist that the feature
be provided as a package.  Then helping them with their misconceptions
(and statistically speaking, there will be a certain fraction of users
who misunderstand) is my privilege as core maintainer, not my
responsibility.  Putting it in core makes it the other way around, and
that will suck for Stefan and Yidong IMO.

 > FWIW XEmacs rewrote and broke my .emacs without prompting last time I
 > had to use it to debug a Gnus problem, so I'm pessimistic about the way
 > it holds the user's hand.

Bingo!  That's exactly the result of the kind of feature creep I'm
worred about here, that I described as a mistake, which I now regret
not opposing more vehemently at the time, and which I am still not in
a position to unilaterally roll back.

And whatever happened to your "I enabled it, I should understand it"
view?  XEmacs was supposed to be a drop-in replacement for Emacs; you
shouldn't be surprised that it uses .emacs as its init file and its
custom-file if it finds it and custom-file isn't explicitly set, just
like Emacs does.  If you had spent the time to think about the
implications of what you were doing, I should think that "xemacs -q"[1]
would be the obvious thing to use to debug Gnus.  After all, the
person who reported the bug certainly wasn't using *your* .emacs in
*her* XEmacs.

But that's not the way you think about it, clearly.  And guess what?
You're right not to think about it that way, just as the users who
won't think so carefully about a trivial feature like load-dir are
right for them.  Life is too short.


Footnotes: 
[1]  Which causes both user-init-file and custom-file to be nil, so no
accesses, let alone writes, to .emacs would occur.