From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Summary and next steps for (package-initialize) Date: Tue, 22 Aug 2017 17:33:03 +0300 Message-ID: <83ziarad0g.fsf@gnu.org> References: <83tw12cocz.fsf@gnu.org> <83d17qcfa1.fsf@gnu.org> <83h8x0c206.fsf@gnu.org> <83efs4byzj.fsf@gnu.org> <83378kba5u.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1503414718 20593 195.159.176.226 (22 Aug 2017 15:11:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2017 15:11:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 22 17:11:53 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkAq5-00041L-E7 for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2017 17:11:33 +0200 Original-Received: from localhost ([::1]:52308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkAq8-0000OB-Ro for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2017 11:11:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkAEy-0007eB-7Z for emacs-devel@gnu.org; Tue, 22 Aug 2017 10:33:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkAEt-0003jW-AO for emacs-devel@gnu.org; Tue, 22 Aug 2017 10:33:12 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkAEt-0003jS-71; Tue, 22 Aug 2017 10:33:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2410 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dkAEs-00034a-Gi; Tue, 22 Aug 2017 10:33:07 -0400 In-reply-to: (message from Radon Rosborough on Mon, 21 Aug 2017 21:52:03 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217683 Archived-At: > From: Radon Rosborough > Date: Mon, 21 Aug 2017 21:52:03 -0700 > Cc: emacs-devel@gnu.org > > > 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.