From: "Ludovic Courtès" <ludo@gnu.org>
To: fernseed@fernseed.me
Cc: , 64620@debbugs.gnu.org
Subject: [bug#64620] [PATCH] gnu: home: Add home-emacs-service-type.
Date: Wed, 23 Aug 2023 12:01:51 +0200 [thread overview]
Message-ID: <87v8d613hs.fsf@gnu.org> (raw)
In-Reply-To: <0173e076aafb6ec389a7ebca5d56b7f4e8a02b6e.1689347338.git.fernseed@fernseed.me> (fernseed@fernseed.me's message of "Fri, 14 Jul 2023 11:12:31 -0400")
Hi Kierin,
This is a truly impressive piece of work!
fernseed@fernseed.me skribis:
> This patch builds on patches from ( and David Wilson for a
> `home-emacs-service-type' (https://issues.guix.gnu.org/58693,
> https://issues.guix.gnu.org/60753, https://issues.guix.gnu.org/62549).
>
> Many of the features of the prior patches have been included, but the
> major focus here is to configure Emacs in Scheme rather than symlinking
> to existing configuration files.
OK, interesting. This seems to be one of the main questions: how far
should we go on the Scheme side?
In <https://issues.guix.gnu.org/62549>, unmatched-paren chose to not
generate elisp at all from Scheme. The advantage is that the
implementation is simpler; as a user, the model one has to have in mind
is also simpler: you’re still configuring most things the traditional
way in elisp. That’s also its downside: you have to do plumbing on the
elisp side, when Guix Home in some cases would know what to do.
I don’t have the answer and I’m not sure what I’d prefer, but I’m trying
to see the tradeoffs and to map out the design space.
> Here are some of the broad strokes:
>
> * The following record types have been introduced to encapsulate
> configuration for Emacs: `emacs-configuration' (for general
> configuration), `emacs-package' (for package-specific configuration),
> `emacs-keymap' (for configuration of local keymaps), and
> `emacs-server' (for configuration of Emacs servers).
Why special-case keymaps, of all the things one might one to configure
in Emacs? I understand it’s one of the first things one may want to
tweak, but then why not add <emacs-theme> as well, etc.; IOW, where do
we draw the line?
> * Most configuration fields are either flat lists or alists that are
> considerably abstracted from their final serialized Elisp
> representation, but escape hatches are provided for both pulling in
> existing configuration files and specifying s-expressions directly.
Are seasoned Emacsers not going to be frustrated because of this? :-)
They might prefer to have full access to elisp.
> * All serialized Elisp is pretty-printed much how we would expect to see
> it in Emacs (for example, with proper indentation according to the
> `lisp-indent-function' symbol property, etc.). This has been
> accomplished by adding a new keyword argument to
> `pretty-print-with-comments' from `(guix read-print)', among other
> improvements.
Fun. I’d like to see how we can avoid spreading elisp conditionals in
(guix read-print).
> * Emacs package configuration can either be serialized as `use-package'
> forms or as equivalent, more minimalist s-expressions. Users can
> define their own package serializers, too.
>
> * For specifying s-expressions, an "Elisp expression" syntax has been
> implemented that is essentially a lighter-weight version G-expressions.
> (I try to explain why this is helpful in the documentation.)
>
> * A reader extension has been implemented that allows for "Elisp
> expressions" to be specified directly with Elisp read syntax, and
> Scheme values (including file-like objects or G-expressions) can in
> turn be "unquoted" within that Elisp code. Also, comments and
> whitespace can be included within the Elisp code via the `#;'
> (comment), `#>' (newline), and `;^L' (page break) forms.
Great that you’re putting (language elisp parser) to good use!
> * Each Emacs server has its own user init and early init files, which
> can optionally inherit configuration from the init files used by
> non-server Emacsen. Each server can also inherit the "main"
> `user-emacs-directory', or it can use its own subdirectory.
>
> * The `home-emacs-service-type' can be extended, with subordinate
> configuration records being merged intelligently when possible.
Very nice.
> * A utility function has been provided for generating the aforementioned
> Scheme records from an existing Emacs init file:
> `elisp-file->home-emacs-configuration'.
Neat; perhaps ‘guix home import’ could use it?
> (define %gnus-init-file
> (elisp-file "gnus.el"
> (list
> (elisp (setq gnus-select-method '(nnnil "")))
> (elisp (setq gnus-secondary-select-methods
> '((nnml "")
> (nntp "news.gmane.io"))))
> (elisp (setq mail-sources
> '((imap :server "mail.example.net"
> :user "user@example.net"
> :port 993
> :stream tls))))
> ;; Elisp reader extension
> #%(define-key global-map [remap compose-mail] #;comment
> '#$%my-function-name nil))))
Could I write:
#%(progn
(setq x …)
(setq y …)
(define-key …))
? That would seem nicer.
#%(body …) is short for (elisp body …) right?
[...]
> (configured-packages
> (list
> (emacs-package
> (name 'windmove)
> ;; Autoload a function used by `my--display-buffer-down'.
> (autoloads '(windmove-display-in-direction))
> (keys-override
> '(("C-M-<left>" . windmove-left)
> ("C-M-<right>" . windmove-right)
> ("C-M-<up>" . windmove-up)
> ("C-M-<down>" . windmove-down)
> ("C-x <down>"
> . my--display-buffer-down)))
> (keys-local
> (list
> (emacs-keymap
> (name 'windmove-repeat-map)
> (repeat? #t)
> (keys '(("<left>" . windmove-left)
> ("<right>" . windmove-right)
> ("<up>" . windmove-up)
> ("<down>" . windmove-down))))))
My first reaction is that I don’t see myself my 2K lines (or a subset
thereof) of .emacs and .gnus in that style. I can foresee potential
benefits in terms of composability, but the barrier to entry looks too
high. WDYT?
> Finally, unit tests have been added for the new `(guix read-print)'
> functionality, and for the "Elisp expression" syntax. I couldn't make
> unit tests for anything that builds derivations serializing Elisp,
> because '%bootstrap-guile' is apparently too old to load `(guix
> read-print)' on the derivation side. But most of this has gotten quite
> a bit of testing, as all of my personal Emacs config is now generated
> from Scheme.
I think you could write tests using ‘guix home container’ and the host’s
store, similar to what ‘tests/guix-home.sh’ is doing. We don’t have a
testing strategy for Home services yet, but we should definitely work on
it.
That’s it for my initial feedback. I hope others in the Home and Emacs
teams will chime in!
Thanks,
Ludo’.
next prev parent reply other threads:[~2023-08-23 10:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 15:12 [bug#64620] [PATCH] gnu: home: Add home-emacs-service-type fernseed
2023-07-22 2:45 ` 宋文武 via Guix-patches via
2023-08-23 10:01 ` Ludovic Courtès [this message]
2023-08-23 16:14 ` Kierin Bell
2023-08-24 12:26 ` Hilton Chain via Guix-patches via
2023-08-24 13:13 ` Kierin Bell
2023-08-24 20:00 ` ( via Guix-patches via
2023-08-26 14:06 ` Kierin Bell
2023-08-28 6:24 ` ( via Guix-patches via
2023-08-28 22:32 ` Kierin Bell
2023-08-29 6:03 ` ( via Guix-patches via
2023-10-11 16:16 ` Ludovic Courtès
2023-10-12 22:15 ` Kierin Bell
2023-10-13 4:30 ` Liliana Marie Prikler
2023-10-13 13:59 ` Kierin Bell
2023-08-26 20:01 ` Liliana Marie Prikler
2023-08-28 22:27 ` Kierin Bell
2023-08-29 4:24 ` Liliana Marie Prikler
2023-10-11 16:48 ` Ludovic Courtès
2023-10-12 22:26 ` Kierin Bell
2024-04-01 8:28 ` [bug#64620] Bumping - " Steve George
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8d613hs.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=64620@debbugs.gnu.org \
--cc=fernseed@fernseed.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).