Aloha All,

Apologies for the delay.

> Instead of 6+7, write a single commit and use =git format-patch=.

Understood. Used =git format-patch HEAD~1= after =git reset --hard
origin/HEAD= to only have a single commit.

> Is that #:splice? #t meant to be there?

Yes, I believe so. Without the =#:splice? #:t= everything within the
file is surrounded by parenthesis. For example

#+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" '((setq x 42) (setq y
10)) #:splice? #:t))))))))
#+END_SRC

Places =(setq x 42)(setq y 10)= (no whitespace so it's kind of hard to
read) in =greetings=. That would properly run as Elisp. Without the
splicing we obtain =((setq x 42) (setq y 10))= which assumes we will
call a function =(setq x 42)= on the argument =(setq y 10)= which will
not work.

> Also, why is bash required here?

Bash was there for debugging purposes. You are right though, it does
not make a lot of sense to be there. It should be in the
=home-environment= =packages= not in the =home-emacs-configuration=.
Surprisingly if =bash= was not installed, =sh= was nowhere to be found
from within =guix home container ${FILE}= and Emacs info manuals were
not readable (something Joshua Branson helped me iron out).

> You should perhaps also distinguish
> the emacs package and the emacs-* packages like so:
> (emacs emacs-next)
> (packages (list emacs-dash emacs-tempel))

Attached is a patch with =emacs= as a configuration type and here is
an example =home-environment= where =bash= installed using the
=packages= slot.

#+BEGIN_SRC scheme
(use-modules (gnu home services emacs)
     (gnu home)
     (guix gexp)
     (gnu packages)
     (ice-9 pretty-print)
     (gnu services))

(home-environment
 (packages (list (specification->package "bash")))
 (services
  (list
   (service home-emacs-service-type))))
#+END_SRC

In the guix-dev mailing list, it has been discussed that Andrew
Tropin's method of declaring a config is worthwhile inspiration. Here
is an example configuration block.

#+BEGIN_SRC scheme
(define emacs-configure-rde-keymaps
  (rde-emacs-configuration-package
   'rde-keymaps
   `((defvar rde-app-map nil "Prefix keymap for applications.")
     (define-prefix-command 'rde-app-map nil)
     (defvar rde-toggle-map nil "\
Prefix keymap for binding various minor modes for toggling functionalitty.")
     (define-prefix-command 'rde-toggle-map nil))
   #:summary "Keymaps inteded for reuse among configure-* packages"))
#+END_SRC

This is a bit closer to the current patch using S-Expressions over
files. Perhaps I should wait for more people to chime in. Maybe I can
try to please both sides. Make a conditional, if the =init= or
=early-init= form is empty (as it is by default) then allow for a file
named =init.el= in the =extra-files= argument.

On Thu, Oct 20, 2022 at 8:06 PM Liliana Marie Prikler
<liliana.prikler@ist.tugraz.at> wrote:
>
> 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



-- 
Mahalo,
Zain Jabbar