Re: feature/package-vc has been merged

[Philip Kaludercic]

Rudolf Adamkovič <salutis@me.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
> Thank you for reading my first-time user experience!

Thank you for taking the time to write up your comments and impressions
in such detail!

>> What I had in mind was for `package-vc-selected-packages' to be used
>> as is.  It is an autoloaded option with a custom setter that installs
>> all "selected packages" as a side effect.
>>
>> As the manual says, all you need to do is write
>>
>>     (setopt package-vc-selected-packages '((modus-themes)))
>>
>> [...]
>
> As both a developer and a user, I remain cautious about any "magic" that
> makes it harder to tell memory access from arbitrary execution of some
> instructions.  Many new and "modern" mainstream languages, such as
> Swift, make that mistake.

The thing is the user options aren't strictly variables.  The usually
are, but they are explicitly meant to operate on a higher abstraction
level, sort of even in a separate name space.

But of course, I understand that not everyone feels comfortable with
this.  So while I insist that package-vc-selected-packages ought to be a
user option, I have also made `package-vc-install-selected-packages'
autoloaded (I have yet to push all the commits) and invocable as a
regular function

> I like the clear distinction between `foo' and `(foo)' in Lisp.  I even
> like the `*' in C that clearly says "a pointer".  Brilliant ideas lost
> to the history in most modern languages.  But I digress!

Maybe I am missing your point, but why shouldn't `foo' and (foo) be
different?  The only context where I can think of `foo' and (foo) being
treated the same is in some APL-like language that "automatically"
upgrades an atomic variable to a 0-dimensional array.

> I would never expect `setopt' to do networking.  In fact, I use `setq'
> everywhere, like almost everybody else, because I know exactly what it
> does, at the call site.  With `setopt', I can only guess.

Right, but this is not always correct.  Usually works, but some user
options are meant to perform a computation on setting a value.  Of
course, computation is dangerous, but it might also be the only way to
provide the necessary flexibility in some cases.

> But anyway, I have a practical reason to say all this:
>
> I have a literate Emacs configuration, mixed with notes.  In it, any
> part can add *some* package to the selected packages but any part can
> also rely on the availability of *all* installed packages.
>
> To get this freedom, I install the selected packages early on the
> after-init hook.  Then, all configuration blocks, evaluated in any
> order, can count on all installed packages.
>
> Any number of times, anywhere, and evaluated in any order:
>
>   (with-eval-after load '...
>      ...do anything, all packages already installed...)
>
>   (add-hook 'after-init-hook
>             ...do anything, all packages already installed...)
>
> Once, does not matter where:
>
>   (add-hook 'after-init-hook
>             ...install selected packages...
>             -99)

I see, this is an interesting approach.  But just to make sure, can you
confirm that package-vc doesn't break any of the assumptions you make
that are necessary for your configuration to work as intended?

> Rudy