From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id cN95CaZNKWWzTQAA9RJhRA:P1 (envelope-from ) for ; Fri, 13 Oct 2023 16:01:10 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id cN95CaZNKWWzTQAA9RJhRA (envelope-from ) for ; Fri, 13 Oct 2023 16:01:10 +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 514F644BFD for ; Fri, 13 Oct 2023 16:01:09 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=fernseed.me header.s=MBO0001 header.b=HGnuzC5L; 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"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=fernseed.me (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1697205670; 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=uXnTpUfRnIvmXJHt8WANVCsmbIoMwk+Lu1SyZh04qAo=; b=L2BYfwAFl7CiR7WLtFlofthTDeekiNnQ2MEmj8GX7ZXc+aJD4Wsm30mgRN5XXFg9VIE/oo 9fu9XAqEbwfxg3tW/trClGIgjF1nmsD+HtweKWG9wbT5P9T1YIpafVmm+g5n/3jhxzk2WD +vAz5OEVQ6GLrxsMyKtR0tEyq8Y4wy5u5zJITuyYKPnWsMzJS8w2vSJt/JDYcjV8wAxkHt MChcCzwnhWy7+sNAUfj5dw9V51uLBGVFLAw6tYdlEQRUl+lDqCKhR5Wquz4MAauo6qM3rl PKttkqBKqrlnSYM8p+pUrvDFsZwXBXRcCR3s4xOAUSxBOuoC9SyJ0bgBE7+42A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1697205670; a=rsa-sha256; cv=none; b=WWmsJJxK84QwyqznCN1NYFQKBZ0MsXMerFkPg5Zi9wbSJio78Oy4gbBvWRfTjjLa/Fn5U2 p6Wm54O/aEC5IZklTpXDzhqboPBQhov9g5e6eZOCz62mgrXAxqhxPOwjCliESnGwhjZTzb kY/N8Br5hcb0nLCtYsNl8edIrKK4oRAgmxRXrQSVfMUtRn8ZSfjfQ3SACPWb30ffri4+ID E5yCo/gJbqoZC6hLBp+r/NXMzwrbbbcdn+XWI90DUY6l5Fn3ETIgGo9JTaZfEIUAJ3NwaB GlBYZyTqUGLYOh0IrUBYXwByIlVWuTh6DLvkvXZD7AUXRWdDmpAyGLPTMSC1Ug== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=fernseed.me header.s=MBO0001 header.b=HGnuzC5L; 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"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=fernseed.me (policy=none) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qrIiZ-0005yW-50; Fri, 13 Oct 2023 10:00:43 -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 1qrIiW-0005y6-3r for guix-patches@gnu.org; Fri, 13 Oct 2023 10:00:41 -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 1qrIiV-00022b-5d for guix-patches@gnu.org; Fri, 13 Oct 2023 10:00:39 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qrIir-0000sq-V8 for guix-patches@gnu.org; Fri, 13 Oct 2023 10:01: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: Fri, 13 Oct 2023 14:01: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: Liliana Marie Prikler Cc: "\(" , Ludovic =?UTF-8?Q?Court=C3=A8s?= , cox.katherine.e+guix@gmail.com, 64620@debbugs.gnu.org, Andrew Tropin Received: via spool by 64620-submit@debbugs.gnu.org id=B64620.16972056393358 (code B ref 64620); Fri, 13 Oct 2023 14:01:01 +0000 Received: (at 64620) by debbugs.gnu.org; 13 Oct 2023 14:00:39 +0000 Received: from localhost ([127.0.0.1]:47010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qrIiU-0000s5-JQ for submit@debbugs.gnu.org; Fri, 13 Oct 2023 10:00:39 -0400 Received: from mout-y-209.mailbox.org ([2001:67c:2050:103:465::209]:45038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qrIiP-0000rk-Ox for 64620@debbugs.gnu.org; Fri, 13 Oct 2023 10:00:37 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (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-209.mailbox.org (Postfix) with ESMTPS id 4S6SnG3v4Tz9v6S; Fri, 13 Oct 2023 16:00:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fernseed.me; s=MBO0001; t=1697205602; 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=uXnTpUfRnIvmXJHt8WANVCsmbIoMwk+Lu1SyZh04qAo=; b=HGnuzC5LLDI56Ajrb1T7DTsb7ey3+GymyNks1xxTxn0pt/2f/s5pQrgUZIf66BI89C5qSp ZSE7YFI2VEOjV6jQurTvlJ9HLop5WUQEnwMuV3QHTHQap0hvg/NecrNREz/+XXt672mYdG Z3YZGaBL+ZZyr1z/C+O0+hMX8rvPK551HVigz4MDN0tHcszOybCAYh4KoUR6eS6FHFaxHf LZ0Fcs3I7oG9O1NA0f98nnHC5PNtHkHPAJDGt3DfIgHQinc+Ct1rOhL8sA7zUS0SWTS1HE Q74TGNNVd78tGD7c/gDtvIS3BWSZxb8YOj0qnRhij82vLtsWmvc5V52crqS/lw== From: Kierin Bell In-Reply-To: <0dc55cac713686514f90ec04243f710894451a82.camel@gmail.com> (Liliana Marie Prikler's message of "Fri, 13 Oct 2023 06:30:59 +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> <8734yf4he4.fsf@fernseed.me> <0dc55cac713686514f90ec04243f710894451a82.camel@gmail.com> Date: Fri, 13 Oct 2023 09:59:57 -0400 Message-ID: <87o7h2lj1e.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-Flow: FLOW_IN X-Migadu-Country: US X-Spam-Score: 4.32 X-Migadu-Queue-Id: 514F644BFD X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: 4.32 X-TUID: miXmx2Vwh8Lj Hello, Liliana Marie Prikler writes: > Hi, Kierin > > Am Donnerstag, dem 12.10.2023 um 18:15 -0400 schrieb Kierin Bell: [...] > I think you should separate your concerns more clearly. Rather than > having home-emacs-service-type take packages and all that other fluff, > you could just have init-directory as a list of file-likes. Then you > can have an init.el-file procedure (or syntax) to take care of > packages. > > e.g. > (home-emacs-configuration > (emacs %my-custom-emacs) > (init-directory > (list (init.el-file (emacs-package =E2=80=A6) (elisp* =E2=80=A6) = =E2=80=A6)))) Apologies! I made some confusing errors in the example configurations in previous message. In the newer design, the `home-emacs-service-type' would not directly deal with objects at all. Here would be a proper example of the newer semantics: --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/") (default-init (emacs-configuration (extra-init (elisp* . . . .)))) ;; ... And possibly: (servers (list (emacs-server-with-packages (emacs-server (name "server")) (list (emacs-package ;; ... ))))))) (service home-emacs-packages-service-type (emacs %my-custom-emacs-version) (serializer %emacs-use-package-serializer) (packages (list (emacs-package ;; ... ) ;; ... )))))) --8<---------------cut here---------------end--------------->8--- I think you're suggesting flatting the hierarchy from: --8<---------------cut here---------------start------------->8--- (home-emacs-configuration (default-init (emacs-configuration (extra-init (elisp* . . . .)) (extra-init-files ; files symlinked and loaded with `load' (list (local-file "~/guix-config/extras.el"))) (variables '((foo . #f)))))) --8<---------------cut here---------------end--------------->8--- ...Into something like: --8<---------------cut here---------------start------------->8--- (home-emacs-configuration (init-file (list (elisp* . . .) (local-file "~/guix-config/extras.el") ; file contents spliced in ; or symlinked and loaded? (emacs-variables '((foo . #f))) (emacs-packages (emacs-package ;; ... ))))) --8<---------------cut here---------------end--------------->8--- This is what David Wilson's patch[1] did.=20 There could easily be an explicit `init.el-file' function in there instead. > Now, admittedly, snarfing guix packages out of init.el-file might > become an issue; I haven't thought about how to implement that > concretely. > > The upside is, that you could reuse this structure for servers. An > emacs-server would just take another home-emacs-configuration and a > server name. The upside of the approach that uses records is that the encapsulation avoids the weirdness of using a that contains objects to create new server objects. Also, obviously the introspection of records. The nesting is confusing, though, and I'd definitely like to work on that. A middle ground might be to keep the concept of the record (maybe even the `home-emacs-packages-service-type'), but make an `init-file' field smart enough to accept either Elisp expressions, file-like objects, or records. I feel like this may be more of an Elispish way to do things than a properly Schemic way, but it's a lot simpler to understand. We could export functions/macros that explicitly convert alists, objects, etc. into Elisp, too, in addition. These may be useful in other contexts. But I think it is probably less confusing and better in principle to chose only one configuration paradigm as the "proper", standardized way of doing things. WDYT? Footnotes: [1] https://issues.guix.gnu.org/60753 --=20 Kierin Bell GPG Key: FCF2 5F08 EA4F 2E3D C7C3 0D41 D14A 8CD3 2D97 0B36