[bug#64620] [PATCH] gnu: home: Add home-emacs-service-type.

[Kierin Bell <fernseed@fernseed.me>]

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> 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 …) (elisp* …) …))))

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 <emacs-package> 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. 

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 <emacs-configuration> records is
that the encapsulation avoids the weirdness of using a
<home-emacs-configuration> that contains <emacs-server> 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
<emacs-configuration> 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
<emacs-configuration> 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,
<emacs-package> 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

-- 
Kierin Bell
GPG Key: FCF2 5F08 EA4F 2E3D C7C3  0D41 D14A 8CD3 2D97 0B36