From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: feature/package-vc has been merged Date: Mon, 07 Nov 2022 08:30:14 +0000 Message-ID: <87fsevyxnt.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <874jvqv2u3.fsf@posteo.net> <875yg6qtbl.fsf@posteo.net> <87ilk33lqk.fsf@posteo.net> <87mt9epqlk.fsf@posteo.net> <87ilk1bgvd.fsf@posteo.net> <87edupbdp0.fsf@posteo.net> <875yg1bc02.fsf@posteo.net> <878rkxgpms.fsf@posteo.net> <87sfiyk3a2.fsf_-_@posteo.net> <87mt948pmo.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21329"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Richard Stallman , emacs-devel@gnu.org To: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 07 09:31:46 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1orxXl-0005LH-Rw for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Nov 2022 09:31:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orxWW-0003W7-Qa; Mon, 07 Nov 2022 03:30:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orxWU-0003Vb-A6 for emacs-devel@gnu.org; Mon, 07 Nov 2022 03:30:26 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orxWS-0006og-3N for emacs-devel@gnu.org; Mon, 07 Nov 2022 03:30:26 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 56EA724002C for ; Mon, 7 Nov 2022 09:30:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667809822; bh=epGoUTV7vjIs3ja7Nwz76Xzls4ZICkEfxkV4CRbpDOo=; h=From:To:Cc:Subject:Date:From; b=TsOJsRXQYx4bn/xv2qkuXeXZpqIwTqb4MG3OJ/aJQnwsREjwuk06g3xtSVzOU1Xjh RMjHDyo4U6xLkRNRpXyspV6BUhoW7oFy3sriA4DBlfL7aE7OnpjkdP+l299rZbLskd z3QqpsB+w2GChVj5H4IbZWivFxjF/bmZ5UHZCYfWK9b0RGUjwwbH/ZXUCVgumvkXKy lYEy4iyOIiQPlpAtprP/rYr4lxXEjl3XJr4VMmQGWbE9v0mGZhOJGITEJTcqN68Z/I 1iCX3Ehra+qpPf/R8XVnp+EEe/VvX6CdQEIGFNFBZsrRmy78a0o9xC1yHDC4LT+Vnq ZsIWAgiOS0jhQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N5PYl0lZKz6tmV; Mon, 7 Nov 2022 09:30:18 +0100 (CET) In-Reply-To: ("Rudolf =?utf-8?Q?Adamkovi=C4=8D=22'?= =?utf-8?Q?s?= message of "Mon, 07 Nov 2022 01:58:03 +0100") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299282 Archived-At: Rudolf Adamkovi=C4=8D writes: > Philip Kaludercic 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