[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary and next steps for (package-initialize)
From: |
Nathan Moreau |
Subject: |
Re: Summary and next steps for (package-initialize) |
Date: |
Thu, 24 Aug 2017 00:30:23 +0200 |
Hello,
> So I propose,
I really like the proposal, except that I would prefer to force
the call to package-initialize if something goes wrong (with
a warning written in the *Messages* buffer) instead of a prompt.
The idea being that
- this seems like a reasonable (a setup with `(package-initialize)'
as only package.el stuff is quite common)
- while remaining backward compatible with existing configurations
- and makes users that don't want package.el happy: they don't need to
put anything related to it in their configuration code, and the its
code is unloaded as long as their configuration loads cleanly.
Nathan
On 23 August 2017 at 17:57, Nikolay Kudryavtsev
<address@hidden> wrote:
> Hello.
>
> I have another proposal that was not considered so far.
>
> The main problem we're trying to solve here is when a new user calls
> something from package.el without having it initialized first. We also want
> the solution to touch only that group of users and no one else.
>
> So I propose, we don't do anything until user either:
>
> 1. Requires something that's not available.
>
> 2. Calls a function that's not available.
>
> In either of those cases we check whether (package-initialize) was already
> called. And, if not, we give user an interactive window along the lines of:
>
> "You tried to call X which is not available and Emacs package manager was
> not initialized. Press:
>
> i to initialize and try again
>
> w to initialize, try again and don't ask again
>
> x to dismiss
>
> K to dissmiss and never ask again."
>
> w writes (package-initialize) to init)
>
> K would set variable
> dear-emacs-i-totally-don-t-need-any-begginers-advice-thanks to t.
>
> We also don't show this window when kill-package-el-and-burn-its-body is t.
>
> I'm not entirely sure on the technical side of catching requires and
> void-functions, but this seems to be the best solution when all other things
> are considered.
>
> Also similar approach is already used in Emacs, there's some key binding
> that's disabled until you confirm it in a similar way, sorry at the moment I
> don't remember which one.
>
> --
> Best Regards,
> Nikolay Kudryavtsev
- Re: Summary and next steps for (package-initialize), (continued)
- Re: Summary and next steps for (package-initialize), Mark Oteiza, 2017/08/20
- Re: Summary and next steps for (package-initialize), Nikolay Kudryavtsev, 2017/08/23
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/23
- Re: Summary and next steps for (package-initialize), Nikolay Kudryavtsev, 2017/08/23
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/23
- Re: Summary and next steps for (package-initialize), Nikolay Kudryavtsev, 2017/08/23
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/23
- Re: Summary and next steps for (package-initialize), Nikolay Kudryavtsev, 2017/08/24
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/24
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
Re: Summary and next steps for (package-initialize),
Nathan Moreau <=
Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
Re: Summary and next steps for (package-initialize), angelo . g0, 2017/08/21