Re: Summary and next steps for (package-initialize)

[Eli Zaretskii]

> From: Radon Rosborough <address@hidden>
> Date: Mon, 21 Aug 2017 21:52:03 -0700
> Cc: address@hidden
> 
> > We do something very similar in other situations, like finding the
> > file-local variables.
> 
> That is completely different. File-local variables conform to a fixed,
> simple syntax which is -- in particular -- not Turing-complete, unlike
> Emacs Lisp.

I think you forget that file-local variables support 'eval' forms.

> If you'd like to propose that `package-load-list' and friends only be
> settable via file-local variables, then that would indeed solve the
> problem. But that's a different proposal.

I proposed _an_idea_.  You forced me to go into details in an area
where my expertise leaves a lot to be desired, to say the least.  So
we shouldn't reject the idea because the details of the possible
implementation I proposed don't add up (which I'm still not sure they
don't), as I excused myself in advance.

Instead, we should look for a better implementation.  Perhaps we
should support a separate .package-exclude file under ~/.emacs.d,
where users would list packages they don't want to load.  After all,
other features have their files there, like abbrev_defs or .mailcap or
.authinfo.

Or maybe it'd be good enough to unload the packages not in the list,
after processing the user init file.

Or maybe people who set package-load-list should also be told to place
the call to package-initialize in their init files, but do it
manually, not automatically by Emacs.

Or something else.  There could be any number of possible solutions
for this issue, which IMO is minor compared to the larger issue of
leaving the user init file alone, letting the users manage its content
as they see fit.

> I should have said: "Emacs Lisp is Turing-complete. It is futile for
> Emacs to try to understand it in any way other than executing it."
> That is what I meant. Static analysis is very different from just
> running the program and seeing what happens.

And yet we do something similar in file-local variables and elsewhere,
like the .dir-locals.el files.  So there are solutions along these
lines that don't violate the basic principles, but still solve
practical problems in a way that is acceptable by the user community.

> > Anyway, the proposal still stays
> 
> OK, but given that there is a formal proof that no general solution
> can possibly exist, I don't think anybody will find one.

Only because you are trying to solve a larger problem than we need to
solve, and because you are reasoning in absolute terms, rather than in
practical engineering terms.

> I started this thread by proposing a specific, comprehensive solution
> to the problem. Nobody has pointed out any flaws yet. Why is there an
> impasse?

Because AFAICT no one likes your proposal.