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

[Ted Zlatanov]

On Thu, 10 Mar 2011 04:33:16 +0900 "Stephen J. Turnbull" <address@hidden> 
wrote: 

SJT> Ted Zlatanov writes:
>> On Thu, 10 Mar 2011 02:29:02 +0900 "Stephen J. Turnbull" <address@hidden> 
>> wrote: 
>> 
SJT> I can only imagine that a load-dir would very likely be the source
SJT> of numerous bugs as some snippets conflict with or depend on others
SJT> but the automatic loader gets them in the wrong order.
>> 
>> We're just adding a mechanism for easy personal code deployment and
>> modularization, not a cure for broken code.

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.  Sometimes things really are
independent and you have to trust the user.

SJT> Ie, it's the idea of automatically loading random snippets that is
SJT> broken: it's a mechanism for speeding up the mess, as Robert
SJT> Townsend put it.  I don't think that belongs in core, but rather
SJT> should be an individually maintained function, tuned to each
SJT> person's requirements.

OK, thank you for your opinion.

SJT> As for easy personal code deployment and modularization, there's
SJT> nothing that says that deployment and modularization requires
SJT> implementation as separate files, and in fact using separate files for
SJT> most things that you would do in an init file is an annoyance as
SJT> Stefan points out.  Stefan's recommendation of using outline minor
SJT> mode easily scales to a 100kB file for me in other contexts, I imagine
SJT> it would work fine for the init file.  While I admit YMMV as a user,
SJT> from the point of view of Emacs maintainers this blows away the
SJT> load-dir idea in terms of maintainability of Emacs core.

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?

SJT> Note that the good reasons for using separate files (assuming you use
SJT> an editor that supports things like outline minor mode -- you do,
SJT> don't you?<wink>) are not really compatible with automatic
SJT> installation and loading.  They're things like lazy loading and
SJT> optional loading to avoid memory bloat and namespace pollution.  Lazy
SJT> loading could be a win (somebody mentioned autoloading instead of
SJT> automatic loading at init time), therefore, but guess what? that
SJT> requires reading code and deciding where to put autoload cookies.

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.

SJT> Note also that .d directories generally use some convention (such as
SJT> file names starting with fixed width integers) that ensure that
SJT> snippets sort in the right order.
>> 
>> I'm sure users can use that (I will).  But they can also specify the
>> order with explicit loads if that's what they need.

SJT> Neither of those is easy or automatic.  To the extent that such are
SJT> needed, people are going to have to sit down and read code to figure
SJT> out what the problems are.  That's precisely what the system is
SJT> supposed to avoid.

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.

SJT> Note that you also have a problem that such explicitly loaded files
SJT> will often need to be moved out of the load-dir, as they won't be
SJT> designed to be idempotent.  Mostly not a problem, of course, and
SJT> therefore all the more annoying and confusing when it does arise.

Sorry, I don't follow.  Can you give a specific example?
 
SJT> More modern systems use (please sit down, you're in for a shock)
SJT> full-blown dependency systems (requires, provides, conflicts, etc)
SJT> in the snippets, which avoids the need to maintain explicit order
SJT> in favor of a partial order.
>> 
>> That's, again, overengineering the problem (as Mark Twain put it, "with
>> all the modern inconveniences").

SJT> Well, no, it's not.  The problem in question is maintaining a .d
SJT> directory without requiring the user to have a clue.

NO IT'S NOT!  Why are you assuming you must treat the user like an idiot
who doesn't know he put a file in a directory and can't figure out load
dependencies?  If the user wants hand-holding, he will use Customize and
package.el and el-get and all the other marvels of the modern age.  I
prefer not to, for my own snippets I will write.

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.

Ted