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

Hey (!

"(" <paren@disroot.org> writes:
> home-emacs-shepherd-services isn't defined here :(  Doesn't this cause an unbound-variable
> error?  (Also, most of the reason I wrote this service was to support auto-starting emacs
> --daemon :))

Whoops, in my haste to send out the patch I forgot to take that out!

Yes, I saw that you meant to run Emacs as a daemon and I think it should
be added to this service (or another daemon-specific service) in a
future patch.  I figured it would be easier to get a patch accepted
without the daemon functionality just yet since there seemed to be more
feedback about that aspect in your patch thread.

Here's an update to my patch that actually works (sorry if I'm doing
this wrong, it's been a while since I worked on a patch thread!) --

Co-authored-by: ( <paren@disroot.org>
---
 doc/guix.texi               |  77 +++++++++++++++
 gnu/home/services/emacs.scm | 185 ++++++++++++++++++++++++++++++++++++
 gnu/local.mk                |   1 +
 3 files changed, 263 insertions(+)
 create mode 100644 gnu/home/services/emacs.scm

--
2.38.1

Hello!

David Wilson <david@daviwil.com> skribis:

> Yes, I saw that you meant to run Emacs as a daemon and I think it should
> be added to this service (or another daemon-specific service) in a
> future patch.  I figured it would be easier to get a patch accepted
> without the daemon functionality just yet since there seemed to be more
> feedback about that aspect in your patch thread.

Agree, I think we should add the daemon functionality in a subsequent
patch.

Overall it looks nice to me!  Some comments and suggestions:

> +@node Emacs Home Services
> +@subsection Emacs Home Services
> +
> +@defvr {Scheme Variable} home-emacs-service-type

It would be nice if you could start the section with a few sentences
explaining the rationale and what’s being described here.

> +This is the service type for configuring the Emacs text editor.  It
> +enables you to assemble @file{init.el} and @file{early-init.el} files
> +from snippets in your home configuration and other Emacs Lisp files you
> +have in your personal configuration folder.

Maybe like so:

  … to assemble the @file{init.el} (@pxref{Init File,,, emacs, GNU Emacs
  Manual}) and @file{early-init.el} (@pxref{Early Init File,,, emacs,
  GNU Emacs Manual}) files …

> +@example
> +$ cp ~/.emacs.d $XDG_CONFIG_HOME/emacs
> +$ cp ~/.emacs $XDG_CONFIG_HOME/emacs/init.el
> +@end example

I’d drop the prompt.

> +@item @code{init-file} (default: @code{'()})
> +Configuration text or files to include in @file{init.el}.
> +
> +@item @code{early-init-file} (default: @code{'()})
> +Configuration text or files to include in @file{early-init.el}.

What about accepting sexps (or gexps) instead of strings?  As in:

  (init-file '((require 'whatever) (setq something t)))

Also I find it confusing that it’s either text or files.  In the code it
has type ‘text-config’, which means list of file-like objects IIUC, no?

> +@item @code{load-paths} (default: @code{'()})
> +Additional load paths to add to Emacs' @code{load-path} variable.  Lines
> +will be inserted at the beginning of @file{early-init.el}.

Nitpick: I think this should be ‘load-path’ (singular), because it’s one
search path (i.e., a list of directories).

And: s/Additional load paths/Additional directories/

> +@end table
> +@end deftp

Would be nice to have a couple of commented examples here, like you had
in the first message in this thread.  :-)

> +@deftp {Data Type} home-emacs-extension
> +The extension record for @code{home-emacs-service-type}.

Would be nice to have a sentence above, like “This service type can be
extended with @code{home-emacs-extension} records, described below:”.

> +@table @asis
> +@item @code{packages} (default: @code{'()})
> +Additional packages required by the Emacs configuration.
> +
> +@item @code{init-file} (default: @code{'()})
> +Configuration text or files to include in @file{init.el}.
> +
> +@item @code{early-init-file} (default: @code{'()})
> +Configuration text or files to include in @file{early-init.el}.
> +
> +@item @code{load-paths} (default: @code{'()})

Ditto.

> +@end deftp

Would be great to have an example of that too.  :-)

Thank you!

Ludo’.

On 2023-01-14 19:00, Ludovic Courtès wrote:

> Hello!
>
> David Wilson <david@daviwil.com> skribis:
>
>> Yes, I saw that you meant to run Emacs as a daemon and I think it should
>> be added to this service (or another daemon-specific service) in a
>> future patch.  I figured it would be easier to get a patch accepted
>> without the daemon functionality just yet since there seemed to be more
>> feedback about that aspect in your patch thread.
>
> Agree, I think we should add the daemon functionality in a subsequent
> patch.
>
> Overall it looks nice to me!  Some comments and suggestions:
>
>> +@node Emacs Home Services
>> +@subsection Emacs Home Services
>> +
>> +@defvr {Scheme Variable} home-emacs-service-type
>
> It would be nice if you could start the section with a few sentences
> explaining the rationale and what’s being described here.
>
>> +This is the service type for configuring the Emacs text editor.  It
>> +enables you to assemble @file{init.el} and @file{early-init.el} files
>> +from snippets in your home configuration and other Emacs Lisp files you
>> +have in your personal configuration folder.
>
> Maybe like so:
>
>   … to assemble the @file{init.el} (@pxref{Init File,,, emacs, GNU Emacs
>   Manual}) and @file{early-init.el} (@pxref{Early Init File,,, emacs,
>   GNU Emacs Manual}) files …
>
>> +@example
>> +$ cp ~/.emacs.d $XDG_CONFIG_HOME/emacs
>> +$ cp ~/.emacs $XDG_CONFIG_HOME/emacs/init.el
>> +@end example
>
> I’d drop the prompt.
>
>> +@item @code{init-file} (default: @code{'()})
>> +Configuration text or files to include in @file{init.el}.
>> +
>> +@item @code{early-init-file} (default: @code{'()})
>> +Configuration text or files to include in @file{early-init.el}.
>
> What about accepting sexps (or gexps) instead of strings?  As in:
>
>   (init-file '((require 'whatever) (setq something t)))

A quick minor note on this approach: it won't be possible to use
#'elisp-function inside such configuration because it will be
interpreted by guile reader, but actually rde lives without this
functionality completely ok.

Do we want something like this possible?

(init-file `((require 'whatever)
             (setq something t)
             (load ,(local-file "old-init.el")))

>
> Also I find it confusing that it’s either text or files.  In the code it
> has type ‘text-config’, which means list of file-like objects IIUC, no?
>
>> +@item @code{load-paths} (default: @code{'()})
>> +Additional load paths to add to Emacs' @code{load-path} variable.  Lines
>> +will be inserted at the beginning of @file{early-init.el}.
>
> Nitpick: I think this should be ‘load-path’ (singular), because it’s one
> search path (i.e., a list of directories).
>
> And: s/Additional load paths/Additional directories/
>
>> +@end table
>> +@end deftp
>
> Would be nice to have a couple of commented examples here, like you had
> in the first message in this thread.  :-)
>
>> +@deftp {Data Type} home-emacs-extension
>> +The extension record for @code{home-emacs-service-type}.
>
> Would be nice to have a sentence above, like “This service type can be
> extended with @code{home-emacs-extension} records, described below:”.
>
>> +@table @asis
>> +@item @code{packages} (default: @code{'()})
>> +Additional packages required by the Emacs configuration.
>> +
>> +@item @code{init-file} (default: @code{'()})
>> +Configuration text or files to include in @file{init.el}.
>> +
>> +@item @code{early-init-file} (default: @code{'()})
>> +Configuration text or files to include in @file{early-init.el}.
>> +
>> +@item @code{load-paths} (default: @code{'()})
>
> Ditto.
>
>> +@end deftp
>
> Would be great to have an example of that too.  :-)
>
> Thank you!
>
> Ludo’.
>
>
>

Thanks for the feedback, Ludo!

I'll make the requested changes and send them later today.  I may also
try adding some tests to ensure that the output is what we expect.
There seems to be a `tests/services` folder, should I add a
`tests/home-services` folder to match?

Ludovic Courtès <ludo@gnu.org> writes:

> It would be nice if you could start the section with a few sentences
> explaining the rationale and what’s being described here.

Will do, I'll look at other services to get an idea of the best way to
do this.

> What about accepting sexps (or gexps) instead of strings?  As in:
>
>   (init-file '((require 'whatever) (setq something t)))
>
> Also I find it confusing that it’s either text or files.  In the code it
> has type ‘text-config’, which means list of file-like objects IIUC, no?

Yes, this was a misunderstanding on my part!

Regarding using s-expressions for this, it would certainly look cleaner.
Andrew raises a good concern about it in his response, I'll take a look
at what RDE does for this and see if I can adopt a similar approach.

> Nitpick: I think this should be ‘load-path’ (singular), because it’s one
> search path (i.e., a list of directories).
>
> And: s/Additional load paths/Additional directories/

Will change both of these, thanks!

> Would be nice to have a couple of commented examples here, like you had
> in the first message in this thread.  :-)

Yep, I'll add examples for all the use cases here.

> Would be nice to have a sentence above, like “This service type can be
> extended with @code{home-emacs-extension} records, described below:”.

Will describe and give an example of how to extend the service!

David

Hi,

Andrew Tropin <andrew@trop.in> skribis:

>> What about accepting sexps (or gexps) instead of strings?  As in:
>>
>>   (init-file '((require 'whatever) (setq something t)))
>
> A quick minor note on this approach: it won't be possible to use
> #'elisp-function inside such configuration because it will be
> interpreted by guile reader, but actually rde lives without this
> functionality completely ok.

Specifically:

  (write '#'x)
  |= (syntax x)

But we can use (guix read-print) and ensure that it prints #'.

> Do we want something like this possible?
>
> (init-file `((require 'whatever)
>              (setq something t)
>              (load ,(local-file "old-init.el")))

It’d be nice.  In that case, we’ll want it to be a gexp though:

  #~((require 'whatever) (load #$(local-file …)))

Thanks,
Ludo’.

On 2023-01-17 10:02, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>>> What about accepting sexps (or gexps) instead of strings?  As in:
>>>
>>>   (init-file '((require 'whatever) (setq something t)))
>>
>> A quick minor note on this approach: it won't be possible to use
>> #'elisp-function inside such configuration because it will be
>> interpreted by guile reader, but actually rde lives without this
>> functionality completely ok.
>
> Specifically:
>
>   (write '#'x)
>   |= (syntax x)
>
> But we can use (guix read-print) and ensure that it prints #'.
>

Do you have any links to docs/sample implementations on the topic of
extending guile reader, so we have an example to start with?  Does guix
workflow language do something like that?

I think it will be cool to hook up a custom reader, ideally comment
preserving, for emacs lisp inside scheme files.

>> Do we want something like this possible?
>>
>> (init-file `((require 'whatever)
>>              (setq something t)
>>              (load ,(local-file "old-init.el")))
>
> It’d be nice.  In that case, we’ll want it to be a gexp though:
>
>   #~((require 'whatever) (load #$(local-file …)))
>

gexps are nice, but do we really need/want them here?  Do you have any
thoughts on what are the benifits over quasiquotes in this case?  Maybe
some examples?

Hi,

Andrew Tropin <andrew@trop.in> skribis:

> On 2023-01-17 10:02, Ludovic Courtès wrote:
>
>> Hi,
>>
>> Andrew Tropin <andrew@trop.in> skribis:
>>
>>>> What about accepting sexps (or gexps) instead of strings?  As in:
>>>>
>>>>   (init-file '((require 'whatever) (setq something t)))
>>>
>>> A quick minor note on this approach: it won't be possible to use
>>> #'elisp-function inside such configuration because it will be
>>> interpreted by guile reader, but actually rde lives without this
>>> functionality completely ok.
>>
>> Specifically:
>>
>>   (write '#'x)
>>   |= (syntax x)
>>
>> But we can use (guix read-print) and ensure that it prints #'.
>>
>
> Do you have any links to docs/sample implementations on the topic of
> extending guile reader, so we have an example to start with?

It’s not the reader but rather the writer that we’d want to tweak.

In (guix read-print), ‘pretty-print-with-comments’ already special cases
quasiquote etc. so that it prints ‘`’ (backtick) and not ‘quasiquote'.
We’d add clauses for ‘syntax’ and ‘quasisyntax’.

> I think it will be cool to hook up a custom reader, ideally comment
> preserving, for emacs lisp inside scheme files.

(guix read-print) is what you want.  :-)

>>> Do we want something like this possible?
>>>
>>> (init-file `((require 'whatever)
>>>              (setq something t)
>>>              (load ,(local-file "old-init.el")))
>>
>> It’d be nice.  In that case, we’ll want it to be a gexp though:
>>
>>   #~((require 'whatever) (load #$(local-file …)))
>>
>
> gexps are nice, but do we really need/want them here?  Do you have any
> thoughts on what are the benifits over quasiquotes in this case?  Maybe
> some examples?

The benefit in the example above is that the gexp would actually work
whereas the sexp wouldn’t :-), unless there’s code somewhere to manually
traverse the sexp adn replace the <local-file> record with its store
item (which is what gexps are about).

I hope that makes sense!

Ludo’.

On 2023-01-23 11:18, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> On 2023-01-17 10:02, Ludovic Courtès wrote:
>>
>>> Hi,
>>>
>>> Andrew Tropin <andrew@trop.in> skribis:
>>>
>>>>> What about accepting sexps (or gexps) instead of strings?  As in:
>>>>>
>>>>>   (init-file '((require 'whatever) (setq something t)))
>>>>
>>>> A quick minor note on this approach: it won't be possible to use
>>>> #'elisp-function inside such configuration because it will be
>>>> interpreted by guile reader, but actually rde lives without this
>>>> functionality completely ok.
>>>
>>> Specifically:
>>>
>>>   (write '#'x)
>>>   |= (syntax x)
>>>
>>> But we can use (guix read-print) and ensure that it prints #'.
>>>
>>
>> Do you have any links to docs/sample implementations on the topic of
>> extending guile reader, so we have an example to start with?
>
> It’s not the reader but rather the writer that we’d want to tweak.

Right, it already can read #'x as (syntax x) and we can print it
properly later, but AFAIK comments are ignored by the default reader.
So I would expect to do something (very roughly) like this:

--8<---------------cut here---------------start------------->8---
(parameterize (((@@ (guix gexp) read-procedure) read-with-comments))
  #~(list 'hello ; Comment I would like to preserve during serialization
          'guix))
--8<---------------cut here---------------end--------------->8---

Of course it doesn't work, but I hope demonstrates the idea.

>
> In (guix read-print), ‘pretty-print-with-comments’ already special
> cases quasiquote etc. so that it prints ‘`’ (backtick) and not
> ‘quasiquote'.  We’d add clauses for ‘syntax’ and ‘quasisyntax’.
>

It seems ice-9 pretty-print also preserves backticks, but I see that
pretty-print-with-comments also preserves gexps, which is cool.  Adding
syntax will make it even cooler.

>> I think it will be cool to hook up a custom reader, ideally comment
>> preserving, for emacs lisp inside scheme files.
>
> (guix read-print) is what you want.  :-)
>

Can you give a hint on how to use it for preserving comments, please?

>>>> Do we want something like this possible?
>>>>
>>>> (init-file `((require 'whatever)
>>>>              (setq something t)
>>>>              (load ,(local-file "old-init.el")))
>>>
>>> It’d be nice.  In that case, we’ll want it to be a gexp though:
>>>
>>>   #~((require 'whatever) (load #$(local-file …)))
>>>
>>
>> gexps are nice, but do we really need/want them here?  Do you have any
>> thoughts on what are the benifits over quasiquotes in this case?  Maybe
>> some examples?
>
> The benefit in the example above is that the gexp would actually work
> whereas the sexp wouldn’t :-), unless there’s code somewhere to manually
> traverse the sexp adn replace the <local-file> record with its store
> item (which is what gexps are about).
>
> I hope that makes sense!

With this simple serializer we already achieved quite good results: 
https://git.sr.ht/~abcdw/rde/tree/388d3ad95e8607543df3dcdf26d058b610e77389/src/rde/serializers/lisp.scm#L35

For this input
--8<---------------cut here---------------start------------->8---
`((load ,(local-file "./feature-lists.scm"))
  ,#~(format #f "hello") ; top level gexps are evaluated
  (list ,#~(format #f "hello")) ; nested gexps are not
  ,#~";; hacky comment"
  ;; comment, which is not preserved
  #'hi-fn ; incorrectly serialized, but fixable by alternative
          ; pretty-print
  )
--8<---------------cut here---------------end--------------->8---

it provides quite satisfying results:
--8<---------------cut here---------------start------------->8---
(load "/gnu/store/xb6ma0mcgg1zzq645s63arvy3qskmbiz-feature-lists.scm")
hello
(list (format #f "hello"))
;; hacky comment
(syntax hi-fn)
--8<---------------cut here---------------end--------------->8---

It's a little incosistent (top level gexp are evaluated, but nested are
not), comments are not preserved and #' serialized incorrectly, but
other than that it works very good.

WDYT about overall approach used here?  or we can do it radically
better?

Ludovic Courtès <ludo@gnu.org> writes:

> Specifically:
>
>   (write '#'x)
>   |= (syntax x)
>
> But we can use (guix read-print) and ensure that it prints #'.

The way I get around this in my config is adding

#+begin_source emacs-lisp
;; #' exports a scheme (syntax ...) form. Treat this as a
;; (function ...) form.
(defalias 'syntax 'function)
#+end_source

This is a very hacky solution, but if you wanted to not modify the
reader, you could add this to the beginning of init.el with the service.

--
Reily Siegel

Hi Andrew,

Andrew Tropin <andrew@trop.in> skribis:

>>> I think it will be cool to hook up a custom reader, ideally comment
>>> preserving, for emacs lisp inside scheme files.
>>
>> (guix read-print) is what you want.  :-)
>>
>
> Can you give a hint on how to use it for preserving comments, please?

It can be used like this:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix read-print)
scheme@(guile-user)> (pretty-print-with-comments (current-output-port) `(list foo ,(comment ";ooh!\n" #t) bar))
(list foo ;ooh!
      bar)$5 = 10
scheme@(guile-user)> (call-with-input-string "(list foo ;oh!\nbar)" read-with-comments)
$6 = (list foo #<<comment> str: ";oh!\n" margin?: #t> bar)
--8<---------------cut here---------------end--------------->8---

There’s a <comment> record type.

Now let’s see perhaps what we need to get ‘home-emacs-service-type’
merged, and what we can keep as future work.  Thoughts?

Ludo’.

Andrew Tropin <andrew@trop.in> writes:

> On 2023-01-23 11:18, Ludovic Courtès wrote:
>
>> Hi,
>>
>> Andrew Tropin <andrew@trop.in> skribis:
>>
>>> On 2023-01-17 10:02, Ludovic Courtès wrote:
>>>
>>>> Hi,
>>>>
>>>> Andrew Tropin <andrew@trop.in> skribis:
>>>>
>>>>>> What about accepting sexps (or gexps) instead of strings?  As in:
>>>>>>
>>>>>>   (init-file '((require 'whatever) (setq something t)))
>>>>>
>>>>> A quick minor note on this approach: it won't be possible to use
>>>>> #'elisp-function inside such configuration because it will be
>>>>> interpreted by guile reader, but actually rde lives without this
>>>>> functionality completely ok.
>>>>
>>>> Specifically:
>>>>
>>>>   (write '#'x)
>>>>   |= (syntax x)
>>>>
>>>> But we can use (guix read-print) and ensure that it prints #'.
>>>>
>>>
>>> Do you have any links to docs/sample implementations on the topic of
>>> extending guile reader, so we have an example to start with?
>>
>> It’s not the reader but rather the writer that we’d want to tweak.
>
> Right, it already can read #'x as (syntax x) and we can print it
> properly later, but AFAIK comments are ignored by the default reader.
> So I would expect to do something (very roughly) like this:
>
> --8<---------------cut here---------------start------------->8---
> (parameterize (((@@ (guix gexp) read-procedure) read-with-comments))
>   #~(list 'hello ; Comment I would like to preserve during serialization
>           'guix))
> --8<---------------cut here---------------end--------------->8---
>
> Of course it doesn't work, but I hope demonstrates the idea.
>
>>
>> In (guix read-print), ‘pretty-print-with-comments’ already special
>> cases quasiquote etc. so that it prints ‘`’ (backtick) and not
>> ‘quasiquote'.  We’d add clauses for ‘syntax’ and ‘quasisyntax’.
>>
>
> It seems ice-9 pretty-print also preserves backticks, but I see that
> pretty-print-with-comments also preserves gexps, which is cool.  Adding
> syntax will make it even cooler.
>
>>> I think it will be cool to hook up a custom reader, ideally comment
>>> preserving, for emacs lisp inside scheme files.
>>
>> (guix read-print) is what you want.  :-)
>>
>
> Can you give a hint on how to use it for preserving comments, please?
>
>>>>> Do we want something like this possible?
>>>>>
>>>>> (init-file `((require 'whatever)
>>>>>              (setq something t)
>>>>>              (load ,(local-file "old-init.el")))
>>>>
>>>> It’d be nice.  In that case, we’ll want it to be a gexp though:
>>>>
>>>>   #~((require 'whatever) (load #$(local-file …)))
>>>>
>>>
>>> gexps are nice, but do we really need/want them here?  Do you have any
>>> thoughts on what are the benifits over quasiquotes in this case?  Maybe
>>> some examples?
>>
>> The benefit in the example above is that the gexp would actually work
>> whereas the sexp wouldn’t :-), unless there’s code somewhere to manually
>> traverse the sexp adn replace the <local-file> record with its store
>> item (which is what gexps are about).
>>
>> I hope that makes sense!
>
> With this simple serializer we already achieved quite good results: 
> https://git.sr.ht/~abcdw/rde/tree/388d3ad95e8607543df3dcdf26d058b610e77389/src/rde/serializers/lisp.scm#L35
>
> For this input
> --8<---------------cut here---------------start------------->8---
> `((load ,(local-file "./feature-lists.scm"))
>   ,#~(format #f "hello") ; top level gexps are evaluated
>   (list ,#~(format #f "hello")) ; nested gexps are not
>   ,#~";; hacky comment"
>   ;; comment, which is not preserved
>   #'hi-fn ; incorrectly serialized, but fixable by alternative
>           ; pretty-print
>   )
> --8<---------------cut here---------------end--------------->8---
>
> it provides quite satisfying results:
> --8<---------------cut here---------------start------------->8---
> (load "/gnu/store/xb6ma0mcgg1zzq645s63arvy3qskmbiz-feature-lists.scm")
> hello
> (list (format #f "hello"))
> ;; hacky comment
> (syntax hi-fn)
> --8<---------------cut here---------------end--------------->8---
>
> It's a little incosistent (top level gexp are evaluated, but nested are
> not), comments are not preserved and #' serialized incorrectly, but
> other than that it works very good.
>
> WDYT about overall approach used here?  or we can do it radically
> better?

Not saying it's better in any particular way, but I have had this locally
for all my elisp-read-by-guile-written-back-to-elisp needs:

--8<---------------cut here---------------start------------->8---
(define-module (jlicht build elisp-write)
  #:use-module (ice-9 match)
  #:use-module (srfi srfi-1)
  #:export (elisp-write))

(define (elisp-write in-list? exp port)
  "Stack-blowing implementation that writes guile's internal elisp
representation to something that can be parsed by Emacs."
  ;; Definitions from (language elisp parser)'s quotation-symbols: 
  (define symbol-strings
    '((#{`}# . "`")
      (#{,}# . ",")
      (#{,@}# . ",@")))
  (define (elisp-symbol? sym)
    (assq sym symbol-strings))
  (define (write-elisp-symbol sym port)
    (format port "~A" (assq-ref symbol-strings sym)))
  
  (match exp
    (((? elisp-symbol? sym) rest)
     (write-elisp-symbol sym port)
     (elisp-write in-list? rest port))
    ;; Vector expression
    (#(vs ...)
     (format port "[")
     (elisp-write #t vs port)
     (format port "]"))
    ;; Guile elisp implementation detail
    ('(%set-lexical-binding-mode #f) 'skip)
    ;; List walker
    ((e ...)
     (when (not in-list?) (format port "("))
     (unless (null? e)
       (elisp-write #f (car e) port)
       (for-each (lambda (v)
                   (format port " ")
                   (elisp-write #f v port)) (cdr e)))
     (when (not in-list?) (format port ")")))
    ;; dotted pair
    ((and (? pair?) (? dotted-list? l))
     (format port "(")
     (elisp-write #t (drop-right l 0) port)
     (format port " . ")
     (elisp-write #t (take-right l 0) port)
     (format port ")"))
    ;; Print simple primitives
    (_ (write exp port))))
--8<---------------cut here---------------end--------------->8---

On the reader side I just use guile's elisp reader:

--8<---------------cut here---------------start------------->8---
(define-module (jlicht test elisp)
  #:use-module (language elisp parser)
  #:use-module (jlicht build elisp-write)
  #:use-module (srfi srfi-26)
  #:use-module (srfi srfi-64))

(eval-when (expand load eval)
  (read-hash-extend #\e (lambda (chr port) (read-elisp port))))

(set! test-log-to-file #f)

(define (roundtrip expr)
  (let ((written (call-with-output-string (cut elisp-write #f expr <>))))
    (call-with-input-string written read-elisp)))

(define-syntax test-roundtrip-equals
  (syntax-rules ()
    ((_ expr)
     (let ((e1 (roundtrip expr)))
       (test-equal e1 (roundtrip e1))))))

(define runner (test-runner-simple))

(test-with-runner runner
  (test-begin "roundtrip-elisp-fixed-point")
  (test-roundtrip-equals 12)
  (test-roundtrip-equals "hello")
  (test-roundtrip-equals '#e#'my-fn)
  (test-roundtrip-equals '#e[a b c])
  (test-roundtrip-equals '#e`(+ 1 2 ,@(a b) ,c))
  (test-end "roundtrip-elisp-fixed-point"))

(exit (test-runner-fail-count runner))
--8<---------------cut here---------------end--------------->8---

I've also hooked it up in combination with a sequence of calls to
`scheme-file' -> `computed-file' called `elisp-file', but that's a bit
more hacky and less relevant to the current discussion.

- Jelle

On 2023-02-01 12:59, Jelle Licht wrote:

> Andrew Tropin <andrew@trop.in> writes:
>
>> On 2023-01-23 11:18, Ludovic Courtès wrote:
>>
>>> Hi,
>>>
>>> Andrew Tropin <andrew@trop.in> skribis:
>>>
>>>> On 2023-01-17 10:02, Ludovic Courtès wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Andrew Tropin <andrew@trop.in> skribis:
>>>>>
>>>>>>> What about accepting sexps (or gexps) instead of strings?  As in:
>>>>>>>
>>>>>>>   (init-file '((require 'whatever) (setq something t)))
>>>>>>
>>>>>> A quick minor note on this approach: it won't be possible to use
>>>>>> #'elisp-function inside such configuration because it will be
>>>>>> interpreted by guile reader, but actually rde lives without this
>>>>>> functionality completely ok.
>>>>>
>>>>> Specifically:
>>>>>
>>>>>   (write '#'x)
>>>>>   |= (syntax x)
>>>>>
>>>>> But we can use (guix read-print) and ensure that it prints #'.
>>>>>
>>>>
>>>> Do you have any links to docs/sample implementations on the topic of
>>>> extending guile reader, so we have an example to start with?
>>>
>>> It’s not the reader but rather the writer that we’d want to tweak.
>>
>> Right, it already can read #'x as (syntax x) and we can print it
>> properly later, but AFAIK comments are ignored by the default reader.
>> So I would expect to do something (very roughly) like this:
>>
>> --8<---------------cut here---------------start------------->8---
>> (parameterize (((@@ (guix gexp) read-procedure) read-with-comments))
>>   #~(list 'hello ; Comment I would like to preserve during serialization
>>           'guix))
>> --8<---------------cut here---------------end--------------->8---
>>
>> Of course it doesn't work, but I hope demonstrates the idea.
>>
>>>
>>> In (guix read-print), ‘pretty-print-with-comments’ already special
>>> cases quasiquote etc. so that it prints ‘`’ (backtick) and not
>>> ‘quasiquote'.  We’d add clauses for ‘syntax’ and ‘quasisyntax’.
>>>
>>
>> It seems ice-9 pretty-print also preserves backticks, but I see that
>> pretty-print-with-comments also preserves gexps, which is cool.  Adding
>> syntax will make it even cooler.
>>
>>>> I think it will be cool to hook up a custom reader, ideally comment
>>>> preserving, for emacs lisp inside scheme files.
>>>
>>> (guix read-print) is what you want.  :-)
>>>
>>
>> Can you give a hint on how to use it for preserving comments, please?
>>
>>>>>> Do we want something like this possible?
>>>>>>
>>>>>> (init-file `((require 'whatever)
>>>>>>              (setq something t)
>>>>>>              (load ,(local-file "old-init.el")))
>>>>>
>>>>> It’d be nice.  In that case, we’ll want it to be a gexp though:
>>>>>
>>>>>   #~((require 'whatever) (load #$(local-file …)))
>>>>>
>>>>
>>>> gexps are nice, but do we really need/want them here?  Do you have any
>>>> thoughts on what are the benifits over quasiquotes in this case?  Maybe
>>>> some examples?
>>>
>>> The benefit in the example above is that the gexp would actually work
>>> whereas the sexp wouldn’t :-), unless there’s code somewhere to manually
>>> traverse the sexp adn replace the <local-file> record with its store
>>> item (which is what gexps are about).
>>>
>>> I hope that makes sense!
>>
>> With this simple serializer we already achieved quite good results: 
>> https://git.sr.ht/~abcdw/rde/tree/388d3ad95e8607543df3dcdf26d058b610e77389/src/rde/serializers/lisp.scm#L35
>>
>> For this input
>> --8<---------------cut here---------------start------------->8---
>> `((load ,(local-file "./feature-lists.scm"))
>>   ,#~(format #f "hello") ; top level gexps are evaluated
>>   (list ,#~(format #f "hello")) ; nested gexps are not
>>   ,#~";; hacky comment"
>>   ;; comment, which is not preserved
>>   #'hi-fn ; incorrectly serialized, but fixable by alternative
>>           ; pretty-print
>>   )
>> --8<---------------cut here---------------end--------------->8---
>>
>> it provides quite satisfying results:
>> --8<---------------cut here---------------start------------->8---
>> (load "/gnu/store/xb6ma0mcgg1zzq645s63arvy3qskmbiz-feature-lists.scm")
>> hello
>> (list (format #f "hello"))
>> ;; hacky comment
>> (syntax hi-fn)
>> --8<---------------cut here---------------end--------------->8---
>>
>> It's a little incosistent (top level gexp are evaluated, but nested are
>> not), comments are not preserved and #' serialized incorrectly, but
>> other than that it works very good.
>>
>> WDYT about overall approach used here?  or we can do it radically
>> better?
>
> Not saying it's better in any particular way, but I have had this locally
> for all my elisp-read-by-guile-written-back-to-elisp needs:

I saw it in guix-home-manager and probably you've made the thread on
rde-devel too.  I tried some parts of this code, but didn't succeed to
get a complete working out of it, now I have a little more knowledge and
hope will get better results :)

>
> --8<---------------cut here---------------start------------->8---
> (define-module (jlicht build elisp-write)
>   #:use-module (ice-9 match)
>   #:use-module (srfi srfi-1)
>   #:export (elisp-write))
>
> (define (elisp-write in-list? exp port)
>   "Stack-blowing implementation that writes guile's internal elisp
> representation to something that can be parsed by Emacs."
>   ;; Definitions from (language elisp parser)'s quotation-symbols: 
>   (define symbol-strings
>     '((#{`}# . "`")
>       (#{,}# . ",")
>       (#{,@}# . ",@")))
>   (define (elisp-symbol? sym)
>     (assq sym symbol-strings))
>   (define (write-elisp-symbol sym port)
>     (format port "~A" (assq-ref symbol-strings sym)))
>   
>   (match exp
>     (((? elisp-symbol? sym) rest)
>      (write-elisp-symbol sym port)
>      (elisp-write in-list? rest port))
>     ;; Vector expression
>     (#(vs ...)
>      (format port "[")
>      (elisp-write #t vs port)
>      (format port "]"))
>     ;; Guile elisp implementation detail
>     ('(%set-lexical-binding-mode #f) 'skip)
>     ;; List walker
>     ((e ...)
>      (when (not in-list?) (format port "("))
>      (unless (null? e)
>        (elisp-write #f (car e) port)
>        (for-each (lambda (v)
>                    (format port " ")
>                    (elisp-write #f v port)) (cdr e)))
>      (when (not in-list?) (format port ")")))
>     ;; dotted pair
>     ((and (? pair?) (? dotted-list? l))
>      (format port "(")
>      (elisp-write #t (drop-right l 0) port)
>      (format port " . ")
>      (elisp-write #t (take-right l 0) port)
>      (format port ")"))
>     ;; Print simple primitives
>     (_ (write exp port))))
> --8<---------------cut here---------------end--------------->8---
>
> On the reader side I just use guile's elisp reader:
>
> --8<---------------cut here---------------start------------->8---
> (define-module (jlicht test elisp)
>   #:use-module (language elisp parser)
>   #:use-module (jlicht build elisp-write)
>   #:use-module (srfi srfi-26)
>   #:use-module (srfi srfi-64))
>
> (eval-when (expand load eval)
>   (read-hash-extend #\e (lambda (chr port) (read-elisp port))))

That's what I was looking for.  If you have any links related to the
topic of the reader extension, please let me know.

>
> (set! test-log-to-file #f)
>
> (define (roundtrip expr)
>   (let ((written (call-with-output-string (cut elisp-write #f expr <>))))
>     (call-with-input-string written read-elisp)))
>
> (define-syntax test-roundtrip-equals
>   (syntax-rules ()
>     ((_ expr)
>      (let ((e1 (roundtrip expr)))
>        (test-equal e1 (roundtrip e1))))))
>
> (define runner (test-runner-simple))
>
> (test-with-runner runner
>   (test-begin "roundtrip-elisp-fixed-point")
>   (test-roundtrip-equals 12)
>   (test-roundtrip-equals "hello")
>   (test-roundtrip-equals '#e#'my-fn)
>   (test-roundtrip-equals '#e[a b c])
>   (test-roundtrip-equals '#e`(+ 1 2 ,@(a b) ,c))

It would be cool to make elisp-unquote for #e, but I think I can take a
look at ungexp to understand how to implement it.

>   (test-end "roundtrip-elisp-fixed-point"))
>
> (exit (test-runner-fail-count runner))
> --8<---------------cut here---------------end--------------->8---
>
> I've also hooked it up in combination with a sequence of calls to
> `scheme-file' -> `computed-file' called `elisp-file', but that's a bit
> more hacky and less relevant to the current discussion.
>
> - Jelle

Thank you very much!

On 2023-01-31 17:26, Ludovic Courtès wrote:

> Hi Andrew,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>>>> I think it will be cool to hook up a custom reader, ideally comment
>>>> preserving, for emacs lisp inside scheme files.
>>>
>>> (guix read-print) is what you want.  :-)
>>>
>>
>> Can you give a hint on how to use it for preserving comments, please?
>
> It can be used like this:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,use(guix read-print)
> scheme@(guile-user)> (pretty-print-with-comments (current-output-port) `(list foo ,(comment ";ooh!\n" #t) bar))
> (list foo ;ooh!
>       bar)$5 = 10
> scheme@(guile-user)> (call-with-input-string "(list foo ;oh!\nbar)" read-with-comments)
> $6 = (list foo #<<comment> str: ";oh!\n" margin?: #t> bar)
> --8<---------------cut here---------------end--------------->8---
>
> There’s a <comment> record type.

Yep, I already experimented with it, but it's not exactly what I'm
looking for, Jelle gave a few ideas and code snippets which looks closer
to what I searching.  Pretty printer and read function are useful, but
not directly related to my question about reader.

>
> Now let’s see perhaps what we need to get ‘home-emacs-service-type’
> merged, and what we can keep as future work.  Thoughts?

We have not perfect, but working quite good implementation of lisp
serializer in rde, which we use in rde's home-emacs-service-type:
https://git.sr.ht/~abcdw/rde/tree/d0ea604282c9aeb0b121f51979373b4aa40f9bcb/item/tests/rde/serializers/lisp-test.scm
https://git.sr.ht/~abcdw/rde/tree/d0ea604282c9aeb0b121f51979373b4aa40f9bcb/item/src/rde/home/services/emacs.scm#L93

But I'm not completely satisfyied with it and don't want to upstream it
in current state, I plan to experiment with Jelle's code and get a
feeling of how his approach works, also want to dive into reader
extensions topic.  If I get satisfying solution I will share it.  It can
take quite a while, so don't expect it to happen anytime soon; it can,
but unlikely :) If anyone want to work in parallel and propose
alternative implementation, I would be glad to give a feedback on it.

Ludovic Courtès <ludo@gnu.org> writes:

> Now let’s see perhaps what we need to get ‘home-emacs-service-type’
> merged, and what we can keep as future work.  Thoughts?

Sorry for the long delay in getting back to this!  To summarize what
we've discussed so far:

- It's possibly best to use g-expressions for the init.el file contents
  because it gives ultimate flexibility on how one can describe their
  Emacs configuration in Scheme while pulling in files from their local
  configuration folder.  Are we concerned whether this may be harder for
  users to understand and adopt?

- We'll postpone any work to ensure that comments and #'function
  references can be properly represented so that we can get the basic
  `home-emacs-service' merged for now.  Future patches will improve on
  that situation.

Is that accurate?  Either way, I'll spend some time today responding to
the feedback so that we can get this merged.

Thanks!

David

Hi David,

David Wilson <david@daviwil.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Now let’s see perhaps what we need to get ‘home-emacs-service-type’
>> merged, and what we can keep as future work.  Thoughts?
>
> Sorry for the long delay in getting back to this!  To summarize what
> we've discussed so far:
>
> - It's possibly best to use g-expressions for the init.el file contents
>   because it gives ultimate flexibility on how one can describe their
>   Emacs configuration in Scheme while pulling in files from their local
>   configuration folder.  Are we concerned whether this may be harder for
>   users to understand and adopt?

Ease of use should always be a concern IMO.  I’d expect that writing
gexps will feel more convenient than in sexps-in-Scheme-strings for the
target Elisp audience.

> - We'll postpone any work to ensure that comments and #'function
>   references can be properly represented so that we can get the basic
>   `home-emacs-service' merged for now.  Future patches will improve on
>   that situation.
>
> Is that accurate?  Either way, I'll spend some time today responding to
> the feedback so that we can get this merged.

Sounds good to me!

Ludo’.