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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4