[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use-package :after ??
From: |
David Masterson |
Subject: |
Re: use-package :after ?? |
Date: |
Thu, 18 May 2023 20:03:43 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: David Masterson <dsmasterson@gmail.com>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Wed, 17 May 2023 13:30:24 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > No, :after says that a will be loaded immediately after b, and _only_
>> > if b is loaded. If b is never loaded, neither will a.
>>
>> So, you're saying, if (via :bind) I call a-mode before a and b have been
>> loaded (but their autoloads are setup), b will not be loaded and,
>> therefore, neither will a (because of :after) causing the call to a-mode
>> via the :bind to fail?
>
> No, I'm saying that :bind will cause Emacs to attempt loading a if you
> invoke the command to which the key was bound by :bind. But if a
> cannot be loaded before b, then when Emacs attempts to auto-load a, it
> will likely signal an error because b was not loaded yet. Or maybe a
> will load successfully, but doing so will not produce the effect the
> user wanted, because b is not loaded.
Ahh, a test is needed to determine how to adjust the docs to better
explain this without getting into the ELisp weeds.
>> :bind is one of the triggers to autoload the
>> package (a in this case), so this would be unexpected.
>
> Which part is unexpected?
Maybe it's my reading. I read :after as a requirement that use-package
could enforce by loading b (if necessary) for a at the appropriate time.
You seem to be reading it as a requirement that, if not met already,
will cause an error of some sort. I suppose my view would be
eval-before-load (which doesn't exist) whereas yours fits
eval-after-load.
>> In your mind, what is the use-case for :after?
>
> Like I said before: :after is just a short for eval-after-load. So
> any use case where a package has another package as its prerequisite
> can use :after. But that doesn't mean you can now forget about
> loading those prerequisites.
Yeah, I had assumed use-package was a little more elegant than that as
it had (via :after) all the info needed to know what should be loaded to
go with the current package load.
As I get more time, I'll play with ERT around this.
Thanks
--
David Masterson
- Re: use-package :after ??, (continued)
- Re: use-package :after ??, Eli Zaretskii, 2023/05/15
- Re: use-package :after ??, David Masterson, 2023/05/15
- Re: use-package :after ??, Eli Zaretskii, 2023/05/16
- Re: use-package :after ??, David Masterson, 2023/05/16
- Re: use-package :after ??, David Masterson, 2023/05/16
- Re: use-package :after ??, Eli Zaretskii, 2023/05/17
- Re: use-package :after ??, David Masterson, 2023/05/17
- Re: use-package :after ??, Eli Zaretskii, 2023/05/18
- Re: use-package :after ??, Lynn Winebarger, 2023/05/18
- Re: use-package :after ??, David Masterson, 2023/05/18
- Re: use-package :after ??,
David Masterson <=
- Re: use-package :after ??, Eli Zaretskii, 2023/05/11
- Re: use-package :after ??, David Masterson, 2023/05/11
- Re: use-package :after ??, Eli Zaretskii, 2023/05/12
- Re: use-package :after ??, David Masterson, 2023/05/12
- Re: use-package :after ??, Emanuel Berg, 2023/05/13