From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id IKDwMCNwKGVHQQAAauVa8A:P1 (envelope-from ) for ; Fri, 13 Oct 2023 00:16:03 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id IKDwMCNwKGVHQQAAauVa8A (envelope-from ) for ; Fri, 13 Oct 2023 00:16:03 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A6F126DFED for ; Fri, 13 Oct 2023 00:16:01 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=fernseed.me header.s=MBO0001 header.b=x7rOlcmu; dmarc=fail reason="SPF not aligned (relaxed)" header.from=fernseed.me (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1697148963; a=rsa-sha256; cv=none; b=J1I/BwZ1LMPhn8gWisjUgpOzT+MbxU0oBWFRB3M6vAzzaXQEsK+efgs3rqLi+IpdB73HyZ gCfWO/HDAdX92ryo7VQ71O0hJpkGxrltXOr12GGO9fLx2hbdlesacctpw7oeCgW3gQwlZO BOxj3xht1Pe5CpEQj+feMdTdRCnB8WxZqRFjwxmDDYeZCaic0KI+bmrPB5IOGNrTfRaAq8 Wc30Ymto2IK/5unrWyfr9ErsfTVN5vTn0Kpft0Q+2bO7qjAWrD3SV4qE2D2/Sh7jKnNx1C ZfdPJZcC6jSDeV4Lx+1oD2X1rk4VVpuWxDKgYjgOytSeirk2LCl7jcgBXNvo2A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=fernseed.me header.s=MBO0001 header.b=x7rOlcmu; dmarc=fail reason="SPF not aligned (relaxed)" header.from=fernseed.me (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1697148963; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=BwOZn6IYZhOD8WmZN+vZbTjEt/VPzmgOvq4Fitedt44=; b=JrlC1co464RBxGi6vlmdVQmkKr2wrlwenSN4vtII5IjVQ7q1crCPHyzOM5in8ZzHP+3WKL 5t4GR2nBX7s+isuK9By1aIdPtGbYBiN72Me6EZwcK8h1mmOfpmIfg3tHD3oSdv7x1tnKa9 wrey2xOU86DDiLzfMP8+hAn+rGhiJPkg0Axrs8nRVZ9jxS7JP7NVg+oGxJ72qxzB/rk7CA YUbla3wZysa1A8lk19iafYd8rOPn39NKrtItJyNi6E1OA/wwBeR1Kk+4DE2qLXZ2W/eFW1 /H4Cgp4WABuDiqjMxi90iVG3BUPQQYVBh6IhHHVf+ztMw65/5SlzkiU6D1hduw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qr3yA-0005Jg-S1; Thu, 12 Oct 2023 18:15:50 -0400 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 1qr3xz-0005Hp-KM for guix-patches@gnu.org; Thu, 12 Oct 2023 18:15:42 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qr3xz-0005zy-Br for guix-patches@gnu.org; Thu, 12 Oct 2023 18:15:39 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qr3yL-0007dP-Ug for guix-patches@gnu.org; Thu, 12 Oct 2023 18:16:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#64620] [PATCH] gnu: home: Add home-emacs-service-type. Resent-From: Kierin Bell Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 12 Oct 2023 22:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64620 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: cox.katherine.e+guix@gmail.com, "\(" , Andrew Tropin , 64620@debbugs.gnu.org, Liliana Marie Prikler Received: via spool by 64620-submit@debbugs.gnu.org id=B64620.169714895529329 (code B ref 64620); Thu, 12 Oct 2023 22:16:01 +0000 Received: (at 64620) by debbugs.gnu.org; 12 Oct 2023 22:15:55 +0000 Received: from localhost ([127.0.0.1]:44430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qr3yE-0007cz-BY for submit@debbugs.gnu.org; Thu, 12 Oct 2023 18:15:54 -0400 Received: from mout-y-111.mailbox.org ([91.198.250.236]:40546) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qr3yB-0007ck-Lk for 64620@debbugs.gnu.org; Thu, 12 Oct 2023 18:15:53 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-y-111.mailbox.org (Postfix) with ESMTPS id 4S63qF33nxz9sYY; Fri, 13 Oct 2023 00:15:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fernseed.me; s=MBO0001; t=1697148921; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BwOZn6IYZhOD8WmZN+vZbTjEt/VPzmgOvq4Fitedt44=; b=x7rOlcmukYco1fdN+fstpTD1AVVMzrEQQs6OyJcdXBL8myXquhToZVoE+QWOdoooXDzXbI LuSKUBI//f0lP2DfTmL7GLRXyCyPaYTFha2iOXEEGzSIjpyhjOzkO65srBKm30sjqv8QWn s35K9C6IXxrf96q0lsaIwC16Fvr8JU0sCCsJZO6eBdte2aYxgLp90dz9VuSZXWxrCT+nmK BzDhRN7QJWR/Z0i30sYTh2jdyVzvOAYa00SihM+LweL1wR4arI4a4h2moPvxxGT8h23kfq BFEq+R22dAMpVk33oowXOCQQxZHj+roftyuUouT5jsUDFlJIa1Zvrmk+x6TRQA== From: Kierin Bell In-Reply-To: <87a5spuoc5.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Wed, 11 Oct 2023 18:16:10 +0200") References: <0173e076aafb6ec389a7ebca5d56b7f4e8a02b6e.1689347338.git.fernseed@fernseed.me> <87il945gzu.fsf@disroot.org> <874jklyk38.fsf@fernseed.me> <873503hebs.fsf@disroot.org> <87y1huvluu.fsf@fernseed.me> <87o7iqpeou.fsf@disroot.org> <87a5spuoc5.fsf@gnu.org> Date: Thu, 12 Oct 2023 18:15:15 -0400 Message-ID: <8734yf4he4.fsf@fernseed.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: 4.29 X-Spam-Score: 4.29 X-Migadu-Queue-Id: A6F126DFED X-TUID: qq6KIT1fVWV9 Hello, Ludovic Court=C3=A8s writes: > Hello! > > If there=E2=80=99s consensus, I think we should go ahead with this patch = series. > Worst that could happen is that people will think of ways to change the > service in one way or another, and that=E2=80=99s fine! > > Two general comments: > > =E2=80=A2 As I wrote earlier, I think it=E2=80=99d be nice to have inte= gration tests > for this, in addition to the unit tests the patch already adds. > > =E2=80=A2 We may want to split the patch into sizable, self-contained b= ites. > For instance, the (guix read-print) changes should probably be > separated out. > > I=E2=80=99ll provide more specific comments about the code. > > To Emacs team members: please review the Emacs bits of the series! > > Thanks, > Ludo=E2=80=99. > > I have been working on getting v2 ready! I'll address the comments specific to the reader, printer and G-expression parts in a reply to the other message. Specifically regarding the `home-emacs-service-type' interface, most of it has not changed since July, but I have a few pertinent comments here. First, I've made a few obvious improvements: 1. The package serializers no longer automatically try to add `-hook' suffixes to hook symbols specified in the `hooks' field of the `emacs-package' record type (=C3=A0 la `use-package'). This bites back when we want to use hooks whose names end in `-functions'. 2. In order to achieve (1), the `%emacs-use-package-serializer' needs to set the relevant options for `use-package' so that it does not add `-hook' suffixes. Hence, I've added a new field to the `emacs-package-serializer' record type for any Elisp that must be evaluated in order for serialized package configuration to work properly. 3. Writing `(list (elisp .) (elisp .))' is cumbersome, so I implemented a new `elisp*' macro that splices multiple s-exps together. We can achieve the same effect as above by writing `(elisp* . .)'. 4. I'm implementing two new functions, `make-simple-package-elisp-serializer' and `make-use-package-elisp-serializer', such that with no arguments they return the default package serializer procedures, but: =20=20 (make-use-package-elisp-serializer EXTRA-KEYWORD-HANDLER) =20 ...Returns a version that serializes the `extra-keywords' field of any `emacs-package' record according to the function EXTRA-KEYWORD-HANDLER. I'm using this, for example, in my own config to define an `auto-faces' keyword that lets me specify faces on a per-theme basis. 5. I'm adding an `extra-init-files' field to the `emacs-package' record type that mirrors that of the `emacs-configuration' record type. The rationale is that it is often convenient to have a complex configuration for a specific package in a self-contained Elisp file, which via this field can be loaded in the main Emacs user init file. Second, I understand that the 1.3kloc implementation of the interface for configuring Emacs packages in Scheme is rather opinionated. Some of the changes described above arguably add to this even more. To simplify things, I've been playing around with splitting this functionality into a `home-emacs-packages-service-type', which would extend the `home-emacs-service-type'. This could go in unofficial channels, but ideally I'd like to see it included with this patch set. The old configuration interface looks like this: --8<---------------cut here---------------start------------->8--- (home-environment ;; ... (services (list ;; ... (service home-emacs-service-type (home-emacs-configuration (user-emacs-directory "~/.local/state/emacs/") (package-serializer %emacs-use-package-serializer) (configured-packages (list (emacs-package ;; ... ) ;; ... Lots more stuff here ... ))))))) --8<---------------cut here---------------end--------------->8--- And the modularized configuration would look like this: --8<---------------cut here---------------start------------->8--- (home-environment ;; ... (services (list ;; ... (service home-emacs-service-type (home-emacs-configuration (emacs %my-custom-emacs-version) (user-emacs-directory "~/.local/state/emacs/") (configured-packages (list (emacs-package ;; ... ) ;; ... Lots more stuff here ... )))) (service home-emacs-packages-service-type (emacs %my-custom-emacs-version) (serializer %emacs-use-package-serializer) (packages (emacs-package ;; ... ) ;; ... Lots of stuff here ... ))))) --8<---------------cut here---------------end--------------->8--- The benefits are maintainability and usability --- users who don't want to use the package configuration interface don't have to deal with the cognitive dissonance. The downside is that Emacs package configuration becomes more cumbersome for more advanced use cases. One case, illustrated above, is that the `home-emacs-packages-service-type' doesn't know the Emacs version used by the `home-emacs-service-type' --- a non-default version of Emacs must be specified again, separately, for the packages service (that is, if it matters that the package serializer knows the Emacs version). Another case is that in order to configure Emacs packages for specific Emacs servers (created via the `servers' field of the `home-emacs-configuration'), there would either need to be a `servers' field in the `home-emacs-packages-configuration' record type (complicated to implement) or users would need to do this manually (with the help of a new function such as `emacs-server-with-packages'). I'd appreciate hearing preferences or arguments for or against either. Also, suggestions for simplifying any part of the interface are welcome! Thanks. --=20 Kierin Bell GPG Key: FCF2 5F08 EA4F 2E3D C7C3 0D41 D14A 8CD3 2D97 0B36