emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stephen J. Turnbull
Subject: Re: user-controlled load-path extension: load-dir
Date: Thu, 10 Mar 2011 12:20:53 +0900

Ted Zlatanov writes:

 > SJT> There's no broken code here, just code not engineered with automatic
 > SJT> loading in mind.
 > 
 > By your logic out-of-order startup scripts in /etc/rc.d should be
 > managed with an external system because simple shell scripts are not
 > engineered with automatic loading in mind.

Yes.  That's what all of the GNU/Linux distros actually do.  IIRC,
NetBSD does as well, as does Mac OS X (nee FreeBSD), and *BSD is quite
a bit farther to the "user responsibility" side of the field than
GNU/Linux distros are.  Some use a total order maintained mostly by
hand, some use a partial ordering mechanism based on require/conflict/
provides.  I'm not talking theory, I'm talking a decade of practice.

 > OK.  What reasons do you have to NOT include the load-dir functionality
 > in the core if it's disabled by default and must be consciously enabled?
 > That you're happy without it?

No.  I maintain an Emacs, and I really don't want a feature that I am
sure will cause some users pain, but I intend to disclaim
responsibility for.  I've made that mistake a couple of times, and the
minor convenience it would provide to experienced users like you just
doesn't offset the user pain and maintainer embarrassment.

 > For me those reasons are modularization and easy code deployment on a
 > personal level.  I think I've been clear on that and wonder how you
 > determined your reasons were the good ones.

My definition of "good" is pretty strict here.  That is, "the need is
sufficiently great, and the problem sufficiently difficult for users
to solve on their own that it's appropriate to introduce new
problems."  The use of outline-minor-mode introduces no new problems
so the hurdle is low for it.  Since Emacs doesn't have per-function
autoloads, optional loading and autoloading clear a substantially
higher hurdle.  load-dir, OTOH, is easy to implement, and will be even
easier to install as a package.  "Sorry, you're not tall enough to ride
this ride."

 > Who said load-dir is supposed to avoid problems?  As with the earlier
 > comment about broken code, if you screw up your configuration layout in
 > any form, you go and fix it.  Emacs should indicate where the error
 > happened, but beyond that it's a user issue.

But here *Emacs is screwing up the configuration* by automatically
downloading and installing code, at least according to several
advocates' proposals.  Again, *this is not theory*.  This is based on
more than a decade of experience with such systems in XEmacs.  Users
do *not* view this as "oh, I messed up again".  They view it as "if
Emacs is not going to do it right, it should tell me to do it myself."

 > Sorry, I don't follow [the argument about non-idempotent configs].
 > Can you give a specific example?

Hooks written as lambdas, which will be added several times.

 > SJT> If Stefan and Yidong could get away with "Ted Z says that's
 > SJT> overengineering so we ain't gonna touch it", it might be worth
 > SJT> putting this in core.  But my recommendation to them is "snippet
 > SJT> conflicts are going to be a persistent annoyance in the long term;
 > SJT> let Ted Z and Jan D maintain a package and deal with the PEBKACs
 > SJT> and RFEs."
 > 
 > OK, got it.  Thanks.

You're welcome.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]