[bug#58652] Creating home-emacs-service-type

[Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>]

Am Donnerstag, dem 20.10.2022 um 11:30 -1000 schrieb Zain Jabbar:
> Aloha All,
> 
> Thank you for your input.
> 
> > Note that you reverted the patch direction.
> 
> Please forgive me for that. Is it possible to explain what I did
> wrong? I will outline my steps to help you figure out what I did
> incorrectly.
> 
> 1. I cloned the repo
> 2. Used =guix shell -D guix=
> 3. Ran =./bootstrap=
> 4. Ran =./configure --localstatedir=/var=
> 5. Ran =make && make check=. By the way, my =make check= had a failed
> test, I don't know if that was expected.
> 6. Made some commits
> 7. I used =git diff HEAD origin/HEAD > my-guix-patch.patch=.
> 
> I might have messed around too much in my cloned repo, throwing
> something off.
Instead of 6+7, write a single commit and use =git format-patch=.

You can of course do multi-patch series, but this feature seems not to
be one that requires that.  Always clean up your commit log after a
hacking session ;)

> > You should also take an extra-files argument, e.g. to add custom.el
> > or other elisp files that init.el might refer to.
> 
> Understood. Attached as a new patch. =home-emacs-configuration= now
> has an extra field =extra-files=. To use it, input a list of file
> objects. The service will splice them into
> =$XDG_CONFIG_HOME/emacs/{FILE}=. Here is an example configuration.
> Using =guix home container= will allow you to see the file
> =greetings=
> with contents "hello world" in =.config/emacs/=.
> 
> #+BEGIN_SRC scheme
> (use-modules (gnu home services emacs)
>      (gnu home)
>      (guix gexp)
>      (gnu packages)
>      (ice-9 pretty-print)
>      (gnu services))
> 
> (home-environment
>  (services
>   (list
>    (service home-emacs-service-type
>     (home-emacs-configuration
>      (packages
>       (list
>        (specification->package "bash")
>        (specification->package "emacs-next")))
>      (extra-files (list (scheme-file "greetings" '(hello world)
> #:splice? #:t))))))))
> #+END_SRC
Is that #:splice? #t meant to be there?

Also, why is bash required here?  You should perhaps also distinguish
the emacs package and the emacs-* packages like so:

(emacs emacs-next)
(packages (list emacs-dash emacs-tempel))

As a future extension, it'd be nice if we could use this service to
easily specify native compilation for emacs packages, but for this one
would have to lay some groundwork in emacs-build-system.

> > Also, I'm not certain if "scheme-file" is the right primitive here
> > – Emacs Lisp does differ from Scheme, e.g. in keyword syntax among
> > others.
> 
> I agree; using =scheme-file= for =emacs-lisp= feels blasphemous.
> There are some odd errors associated with this method too. For
> example, =#'foo= is the shorthand for =(function foo)= in Emacs Lisp
> but gets turned into =(syntax foo)= when using Guile. Meaning a pure
> drag and drop =init.el >> guile-sexp= has some things that need to be
> changed.
> The fact that Emacs-Lisp and Guile Scheme use S-Expressions was
> something I wanted to leverage. It becomes easy to write Elisp in the
> parens of the =init= parameter because there is no context switching
> (e.g. lispy works, cape-symbols works for Elisp in Scheme).
Note that Guile has an elisp reader, albeit a broken one, but no means
to switch languages inside files.

> I am open to other forms of inputting the text in the files. This is
> a bit high maka maka, but I would also like to see how "elegant" the
> other methods of inserting Elisp look. That is, can we make it
> desirable for people to integrate Elisp into Guile Scheme moreso than
> a =local-file= declaration. Using backquotes and S-Expressions allows
> for some variables from Guile to be placed into the Emacs
> configuration like the system type, user names, and emails.
I think taking a list of file-like objects and concatenating their
contents might be worth considering.  That's a bit more overhead, but
we'd have a cleaner separation between fragments that have the same
semantics in Scheme and those that don't.

Cheers