Use `guix repl` instead of Geiser.
In both Nyxt
and Helm System Packages
I've successfully managed to use the Guix REPL to bind Guix interaction with
Emacs Lisp and Common Lisp. It works like a charm, it's fast, requires zero
setup and no dependency other than a guix
executable.
Possible improvements:
-
use reader macros to read
#t
and#f
directly instead of the'\#t
and\#f
workarounds. I know how to do this in Common Lisp, not sure about Emacs Lisp. -
For now
guix repl
needs to be fed a file, hence the clumsy temporary file creation. Ifguix repl
supported reading from the standard input, we could work around this problem. See https://issues.guix.info/issue/44612.
Now why would we want to move away from Geiser? In my opinion, it brings few benefits and costs us a lot.
Indeed, the *Guix REPL*
buffer
- should not be required to build packages,
- does not work to build packages because Geiser chokes on large outputs (emacs-geiser/geiser#9 (closed)),
- cannot interrupt some operations (emacs-geiser/geiser#11 (closed)).
The benefits are few as I've experienced them:
-
Traces are not interactive, which makes them not so useful: emacs-geiser/geiser#10 (closed).
-
Guix traces are hard to read anyways (I guess this is mostly due to our client / daemon architecture).
The aforementioned issues seem to be rooted in the Geiser internals and possibly hard to solve. Looks like there are here to stay for a while, unless someone wants to roll up their sleeves and fix these.
I'd like insist: in the current state of Geiser, we cannot leverage it
reliably in Emacs-Guix. We need to talk to Guix directly, e.g. with
guix repl
like I've done in Nyxt.