[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#64620] [PATCH] gnu: home: Add home-emacs-service-type.
From: |
Liliana Marie Prikler |
Subject: |
[bug#64620] [PATCH] gnu: home: Add home-emacs-service-type. |
Date: |
Fri, 13 Oct 2023 06:30:59 +0200 |
User-agent: |
Evolution 3.46.4 |
Hi, Kierin
Am Donnerstag, dem 12.10.2023 um 18:15 -0400 schrieb Kierin Bell:
> […]
> 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!
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 …) (elisp* …) …))))
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.
Cheers