GNU bug report logs - #55013
Guix-emacs doesn't work

Previous Next

Full log

Message #44 received at 55013 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: Giovanni Biscuolo <g <at> xelera.eu>, 55013 <at> debbugs.gnu.org,
 Jan Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: Guix-emacs doesn't work
Date: Sat, 25 Mar 2023 21:00:07 +0000

------- Original Message -------
On Monday, March 20th, 2023 at 7:09 PM, Ricardo Wurmus <rekado <at> elephly.net> wrote:


> 
> 
> Hi,
> 
> this no longer seems to be a problem. Can you please confirm that this
> issue can be closed now?

I can confirm that the emacs-guix package is still broken.

## Steps to reproduce
1. launch Emacs in a container:
  $ guix shell -C --no-cwd --expose=/gnu --expose=/var --share=/tmp  -E DISPLAY emacs emacs-guix -- emacs
2. run M-x guix-installed-packages

### Expected result
A list of installed packages should appear.

### Actual result
In *Messages* buffer:
> guix-geiser-eval: Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Unbound variable: %max-returned-list-size

## My Guix version
$ guix --version | grep guix
guix (GNU Guix) 51f8a7aced70b7f79037bd99019dddaea07ced25

## Discussion

When I was working to create an Emacs Guix package (https://github.com/ryanprior/emacs-guix-packaging) to support my own workflows, folks were critical of how I run Guix commands in the shell and parse the output instead of building on the Emacs Guix package and its Guile REPL approach. But in practice, this package has never worked for me, I always get REPL errors.

Since then, I have often discussed emacs-guix with other Emacs users in the community and thus realized I'm far from the only one who's never once got it to work. Today, despite the efforts of multiple engineers, it remains reproducibly broken.

My inclination would be to remove entirely the dependency on Geiser and the Guix REPL, opting instead to connect to a guix-ui service over a stable HTTP API. The API endpoints would be documented and tested as part of the formal interface to Guix, and the Emacs package would become a client of that interface.

Whether you like my alternative or not, do most Guix maintainers have confidence in the current approach and think emacs-guix just needs a bugfix here or there, or does anyone else get the impression that it's unsound and needs a new approach?

Ryan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.