[PATCH 0/2] Add a function to parse emacs elisp's package header

When writing a guix.scm file for an emacs packages, I wanted a way to fetch

the version I specify in the header of the elisp file. I found that I could do

that with the lisp-mnt library in emacs. Unfortunately none of the emacs

utility functions in guix/build/emacs-utils.scm return the output of an

elisp expression.

With these two patches I aim to add that functionality.

I spilt it in two functions:

emacs-batch-script: Run an arbitrary elisp expression and return the output as

a string.

emacs-header-parse: Given a header section and a file it will return the value

of that section.

For example (emacs-header-parse "version" "path/to/an/elisp/package.el")

Reason for the spilt is that people might want to run other elisp snippets.

Fredrik Salomonsson (2):

guix: emacs-utils: Add emacs-batch-script.

guix: emacs-utils: Add emacs-header-parse.

guix/build/emacs-utils.scm | 22 ++++++++++++++++++++++

1 file changed, 22 insertions(+)

base-commit: 3935451f63c078cae9a928d87c6838ec3138abc0

--

2.36.0

---

guix/build/emacs-utils.scm | 13 +++++++++++++

1 file changed, 13 insertions(+)

---

guix/build/emacs-utils.scm | 9 +++++++++

1 file changed, 9 insertions(+)

Hi Fredrik,

The patches LGTM modulo cosmetic issues:

Fredrik Salomonsson <plattfot@posteo.net> skribis:

[...]

I suggest something like:

(let* ((pipe (open-pipe* …))

(output (read-string pipe))

(status (close-pipe pipe)))

(unless (zero? status)

;; Use SRFI-34 + either a &message condition or (better)

;; a dedicate SRFI-35 condition type for the error.

(raise (condition …)))

output)

That way, execution failures would be caught and reported.

Ludo’.

Fredrik Salomonsson <plattfot@posteo.net> skribis:

LGTM!

Could you send a v2 of these patches?

Thanks in advance,

Ludo’.

Hi Ludo,

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

Thank you for the feedback. I update the procedure to use a dedicated

SRFI-35 condition type. But I cannot figure out how to capture the error

message from emacs, as I want the condition type to contain both the

expression as well as the error you get from emacs.

Here is what I have so far:

(define-condition-type &emacs-batch-error &error

emacs-batch-error?

(expression emacs-batch-error-expression)

(message emacs-batch-error-message))

(define (emacs-batch-script expr)

"Execute the Elisp code EXPR in Emacs batch mode and return output."

(let* ((error-pipe (open-output-string))

(pipe (with-error-to-port error-pipe

(lambda ()

(open-pipe*

OPEN_READ

(%emacs) "--quick" "--batch"

(string-append "--eval=" (expr->string expr))))))

(output (read-string pipe))

(error (get-output-string error-pipe))

(status (close-pipe pipe)))

(unless (zero? status)

(raise (condition (&emacs-batch-error

(expression expr)

(message error)))))

output))

Here is the output when I test it out in the guix repl:

--------------------------------------------------------------------------------

scheme@(guix-user)> (use-modules (guix build emacs-utils))

(use-modules (guix build emacs-utils))

scheme@(guix-user)> (emacs-batch-script '(prog (princ "hello")))

(emacs-batch-script '(prog (princ "hello")))

ice-9/boot-9.scm:1685:16: In procedure raise-exception:

Wrong type (expecting exact integer): #<&emacs-batch-error expression: (prog (princ "hello")) message: "">

Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.

scheme@(guix-user) [1]>

--------------------------------------------------------------------------------

Note the message is empty in #<&emacs-batch-error…>. It should contain:

Debugger entered--Lisp error: (void-function prog)

(prog (princ "hello"))

command-line-1(("--eval=(prog (princ \"hello\"))"))

command-line()

normal-top-level()

Any idea what I'm doing wrong?

Thanks

--

s/Fred[re]+i[ck]+/Fredrik/g

Hi,

Fredrik Salomonsson <plattfot@posteo.net> skribis:

Unfortunately ‘open-pipe*’ is not smart enough to redirect stderr to a

non-file port (a string port in this case).

One way around it would be to merge stdout and stderr, like so:

(parameterize ((current-error-port (current-output-port)))

(open-pipe* …))

but then you get both on the same stream, which could be a problem for

instance if Emacs emits warnings and such.

You could work around it by establishing a second pipe:

(match (pipe)

((stderr-input . stderr-output)

(parameterize ((current-error-port stderr-output))

(open-pipe* …))))

Here you should be able to read, in the parent process, from

‘stderr-input’.

Another option is to not try to capture stderr: after all, that’ll get

printed on the screen anyway.

HTH,

Ludo’.

---

Makefile.am | 1 +

guix/build/emacs-utils.scm | 30 +++++++++++++++++++++++++++

tests/build-emacs-utils.scm | 41 +++++++++++++++++++++++++++++++++++++

3 files changed, 72 insertions(+)

create mode 100644 tests/build-emacs-utils.scm

"emacs-header-parse: fetch keywords", "emacs-header-parse: fetch

nonexistent author"): New tests.

---

guix/build/emacs-utils.scm | 9 +++++++++

tests/build-emacs-utils.scm | 30 ++++++++++++++++++++++++++++++

2 files changed, 39 insertions(+)

Hi Ludo,

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

I just sent in v2 of the patches. Changes are:

- emacs-batch-script will now raise an &emacs-batch-error if emacs batch

script fails. I opted to capture the stderr and package that up in the

condition. Thank you for the pointers! I removed the expression slot I

had in my prototype. It felt redundant, emacs error message should be

enough.

- tests/build-emacs-utils.scm: I added tests for the two new procedures.

It was good that I added the tests as I had missed to use (srfi srfi-34)

in build/emacs-utils.scm during my prototyping and that generated the

cryptic error:

Wrong type (expecting exact integer): #<&emacs-batch-error…>

Took me a while to figure that one out. But now all is good. The tests

are passing.

Thanks again.

--

s/Fred[re]+i[ck]+/Fredrik/g

Fredrik Salomonsson schreef op zo 05-06-2022 om 00:19 [+0000]:

IIUC, this can only be run if emacs is in $PATH when running the tests,

so sometimes the test needs to be skipped. As an example on how to do

this, see the "pypi->guix-package, wheels" test in tests/pypi.scm.

Greetings,

Maxime.

---

Makefile.am | 1 +

guix/build/emacs-utils.scm | 30 ++++++++++++++++++++++++++

tests/build-emacs-utils.scm | 43 +++++++++++++++++++++++++++++++++++++

3 files changed, 74 insertions(+)

create mode 100644 tests/build-emacs-utils.scm

"emacs-header-parse: fetch keywords", "emacs-header-parse: fetch

nonexistent author"): New tests.

---

guix/build/emacs-utils.scm | 9 +++++++++

tests/build-emacs-utils.scm | 27 ++++++++++++++++++++++++++-

2 files changed, 35 insertions(+), 1 deletion(-)

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

Yes, you are correct. All my tests started to fail when I added `--pure`

to my test command.

I just sent in a v3 of the patches when I skip the tests if emacs is not

in the PATH.

I also changed the tests for the `emacs-header-parse` to be wrapped by

`call-with-temporary-directory`. It felt wasteful to create and destroy that

file for each test when the file is static.

I opted to just have one test-skip and skip all five of them. Although

that migth be too fragile. Would be great to have something like:

(unless (which "emacs")

(test-skip "emacs-batch-script:")

(test-skip "emacs-header-parse:"))

But the docs just mention a counter or the full name of a test.

--

s/Fred[re]+i[ck]+/Fredrik/g

Hi Fredrik,

Fredrik Salomonsson <plattfot@posteo.net> skribis:

[...]

Thanks, applied. Apologies for the delay!

Ludo’.