From: Radon Rosborough <radon.neon@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: mvoteiza@udel.edu, emacs-devel@gnu.org
Subject: Re: Summary and next steps for (package-initialize)
Date: Tue, 22 Aug 2017 11:09:41 -0700 [thread overview]
Message-ID: <CADB4rJHHL-ojsxc36PM3tYjD4YnXrQvX3ph6pCr8PbaWC1j+8w@mail.gmail.com> (raw)
In-Reply-To: <83ziarad0g.fsf@gnu.org>
> I think you forget that file-local variables support 'eval' forms.
This is different, since such `eval' forms can be processed just by
evaluating them. Whereas the implementation you proposed involved
determining the evaluation result of Lisp code without actually
evaluating it.
> 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.
I see now that your proposal was more general than I took it to be.
I'll try to refrain from overgeneralizing from now on. (I still may
point out flaws in particular implementation ideas, though.)
> Perhaps we should support a separate .package-exclude file under
> ~/.emacs.d, where users would list packages they don't want to load.
This is roughly equivalent to having a second init-file, which is
indeed a valid solution (although it has the disadvantage that users
will inevitably put package.el customizations in their init-files and
then get confused when they don't work).
> Or maybe it'd be good enough to unload the packages not in the list,
> after processing the user init file.
I think the resulting performance regressions make this impractical.
Not to mention that packages can, in general, run arbitrary Lisp code
in their autoloads which cannot be unloaded.
> 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.
This wouldn't solve the problem of package customizations in the
init-file not working, which is the primary issue. (But just to be
clear, I'm not insisting that you be the one to provide a solution to
that problem just because you made the suggestion.)
> 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.
Do you consider a one-time default init-file as violating the
principle of "leaving the user init file alone"? That's a perfectly
reasonable position; I just haven't heard you say that yet.
> And yet we do something similar in file-local variables and
> elsewhere, like the .dir-locals.el files.
I've already said that this is completely different, since file-local
variables can be evaluated directly, whereas anything in the init-file
depends on the runtime behavior of the entire rest of the init-file.
> 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.
Is "not allowing dynamic customization of package-load-list"
acceptable by the user community? Honest question. It wouldn't be
acceptable by me but then I don't use package.el.
> 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'm just trying to point out that any ahead-of-time static analysis of
the init-file will necessarily fail in some circumstances. If we're OK
with that, then fine, but we have to be aware of it.
> > 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.
Well, nobody (including you) has told me *why* they don't like my
proposal. If somebody would explain that, then I would stop bringing
it up.
Also, Mark Oteiza clearly likes my proposal, so I think "no one" is an
exaggeration:
> Radon Rosborough <radon.neon@gmail.com> writes:
> > Last week I posted an inquiry [1] about package.el's auto-insertion of
> > code into the init-file. Six people weighed in, but no definitive
> > conclusion was reached. I would like to propose concrete next steps,
> > summarizing relevant parts of the discussion in the process.
>
> Thanks for pushing the issue.
>
> > ==> The proposal
> >
> > The `package--ensure-init-file' logic will be removed
>
> +1 for reverting.
>
> I will happily propose and write documentation for various use cases of
> package.el, but I will not waste my time as long as the current solution
> is in place.
In fact, I think Mark is the only person in this whole thread who has
made a specific comment directly on my proposal. (I still haven't
received replies from you or Stefan requesting a specific explanation
of your comments that my proposal is "a non-starter" or will not be
"significantly better".)
In the meantime, here is my analysis of the options we have:
* Require package.el customization to happen in file-local variables.
* Scan the init-file for customization of package.el, and accept that
this will fail in many cases.
* Introduce a second init-file just for package.el.
* Don't allow package.el to be customized.
* Use a default init-file.
* Require users to understand that the package manager must be loaded
before packages can be customized.
* Leave it as is, where Emacs modifies the init-file programmatically,
and accept that this usually does the wrong thing.
Let me know if I missed anything.
next prev parent reply other threads:[~2017-08-22 18:09 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-20 2:38 Summary and next steps for (package-initialize) Radon Rosborough
2017-08-20 6:10 ` Drew Adams
2017-08-20 17:20 ` Radon Rosborough
2017-08-20 18:09 ` Drew Adams
2017-08-20 18:39 ` Radon Rosborough
2017-08-21 0:33 ` Drew Adams
2017-08-21 4:08 ` Radon Rosborough
2017-08-20 8:13 ` Stefan Monnier
2017-08-20 17:21 ` Radon Rosborough
2017-08-20 8:15 ` Clément Pit-Claudel
2017-08-20 17:21 ` Radon Rosborough
2017-08-20 14:20 ` Eli Zaretskii
2017-08-20 16:37 ` Alex
2017-08-20 16:44 ` Eli Zaretskii
2017-08-20 16:46 ` Yuri Khan
2017-08-20 16:54 ` Drew Adams
2017-08-20 17:18 ` Colin Baxter
2017-08-22 21:24 ` Alex
2017-08-20 17:22 ` Radon Rosborough
2017-08-20 17:36 ` Eli Zaretskii
2017-08-20 17:54 ` Radon Rosborough
2017-08-21 16:35 ` Eli Zaretskii
2017-08-21 16:43 ` Radon Rosborough
2017-08-21 17:40 ` Eli Zaretskii
2017-08-21 20:33 ` Radon Rosborough
2017-08-22 2:37 ` Eli Zaretskii
2017-08-22 4:52 ` Radon Rosborough
2017-08-22 8:41 ` Clément Pit-Claudel
2017-08-22 16:02 ` Radon Rosborough
2017-08-22 14:33 ` Eli Zaretskii
2017-08-22 18:09 ` Radon Rosborough [this message]
2017-08-22 21:01 ` Clément Pit-Claudel
2017-08-21 9:04 ` Stefan Monnier
2017-08-21 14:31 ` Eli Zaretskii
2017-08-21 16:34 ` Radon Rosborough
2017-08-21 17:47 ` Clément Pit-Claudel
2017-08-22 11:37 ` Timur Aydin
2017-08-22 16:58 ` Radon Rosborough
2017-08-22 21:04 ` Clément Pit-Claudel
2017-08-23 5:17 ` Radon Rosborough
2017-08-23 11:33 ` Angelo Graziosi
2017-08-23 17:16 ` Radon Rosborough
2017-08-23 13:28 ` Drew Adams
2017-08-23 17:31 ` Radon Rosborough
2017-08-23 18:00 ` Drew Adams
2017-08-23 18:32 ` Radon Rosborough
2017-08-23 20:27 ` Drew Adams
2017-08-23 20:59 ` Clément Pit-Claudel
2017-08-23 21:21 ` Drew Adams
2017-08-23 21:44 ` Clément Pit-Claudel
2017-08-23 21:53 ` Drew Adams
2017-08-24 0:44 ` Radon Rosborough
2017-08-24 6:39 ` Drew Adams
2017-08-25 1:03 ` Radon Rosborough
2017-08-24 17:14 ` Eli Zaretskii
[not found] ` <<83fucg99cj.fsf@gnu.org>
2017-08-24 17:44 ` Drew Adams
2017-08-24 18:12 ` Clément Pit-Claudel
2017-08-24 18:29 ` Drew Adams
2017-08-24 21:34 ` Clément Pit-Claudel
2017-08-24 21:40 ` Drew Adams
2017-08-25 1:04 ` Radon Rosborough
2017-08-24 18:14 ` Eli Zaretskii
[not found] ` <<83bmn496js.fsf@gnu.org>
2017-08-24 18:36 ` Drew Adams
2017-08-24 18:57 ` Eli Zaretskii
2017-08-25 1:04 ` Radon Rosborough
2017-08-25 1:04 ` Radon Rosborough
2017-08-23 3:15 ` Stefan Monnier
2017-08-24 16:47 ` Eli Zaretskii
2017-08-24 17:48 ` Stefan Monnier
2017-08-24 18:26 ` Eli Zaretskii
2017-08-25 3:52 ` Stefan Monnier
2017-08-25 3:59 ` Radon Rosborough
2017-08-25 4:39 ` Stefan Monnier
2017-08-25 4:45 ` Radon Rosborough
2017-08-25 4:48 ` Stefan Monnier
2017-08-25 6:47 ` Eli Zaretskii
2017-08-25 11:51 ` Stefan Monnier
2017-08-25 1:04 ` Radon Rosborough
2017-08-25 4:14 ` Stefan Monnier
2017-08-25 4:28 ` Radon Rosborough
2017-08-25 4:47 ` Stefan Monnier
2017-08-25 21:07 ` Stefan Monnier
2017-08-25 21:34 ` Radon Rosborough
2017-08-26 22:29 ` Stefan Monnier
2017-08-26 22:33 ` Radon Rosborough
2017-08-21 16:18 ` Radon Rosborough
2017-08-20 19:09 ` Mark Oteiza
2017-08-23 15:57 ` Nikolay Kudryavtsev
2017-08-23 18:17 ` Radon Rosborough
2017-08-23 19:17 ` Nikolay Kudryavtsev
2017-08-23 19:38 ` Radon Rosborough
2017-08-23 20:09 ` Nikolay Kudryavtsev
2017-08-24 0:13 ` Radon Rosborough
2017-08-24 13:44 ` Nikolay Kudryavtsev
2017-08-25 1:04 ` Radon Rosborough
2017-08-24 17:12 ` Eli Zaretskii
2017-08-23 22:30 ` Nathan Moreau
2017-08-24 0:54 ` Radon Rosborough
2017-08-24 11:13 ` Nathan Moreau
2017-08-24 17:02 ` Eli Zaretskii
2017-08-24 17:52 ` Nikolay Kudryavtsev
2017-08-24 18:31 ` Eli Zaretskii
2017-08-25 13:48 ` Nikolay Kudryavtsev
-- strict thread matches above, loose matches on Subject: below --
2017-08-21 8:24 angelo.g0
2017-08-21 16:22 ` Radon Rosborough
2017-08-21 19:35 ` Angelo Graziosi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADB4rJHHL-ojsxc36PM3tYjD4YnXrQvX3ph6pCr8PbaWC1j+8w@mail.gmail.com \
--to=radon.neon@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=mvoteiza@udel.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.