[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#55420] [PATCH 0/2] Add a function to parse emacs elisp's package he
[bug#55420] [PATCH 0/2] Add a function to parse emacs elisp's package header
Sun, 05 Jun 2022 00:42:34 +0000
Ludovic Courtès <firstname.lastname@example.org> writes:
> Fredrik Salomonsson <email@example.com> skribis:
>> Here is what I have so far:
>> (define-condition-type &emacs-batch-error &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 ()
>> (%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)))))
> 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
> Another option is to not try to capture stderr: after all, that’ll get
> printed on the screen anyway.
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
- 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
Wrong type (expecting exact integer): #<&emacs-batch-error…>
Took me a while to figure that one out. But now all is good. The tests