emacs-guix: shell commands broken

Recipe:

1. M-x guix

2. c (for "guix shell commands)

bt:

```

Debugger entered--Lisp error: (error "Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception:\n/home/christopher/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm:176:7: Unknown # object: \"#~\"\n\nEntering a new prompt. Type `,bt' for a backtrace or `,q' to continue.")

signal(error ("Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception:\n/home/christopher/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm:176:7: Unknown # object: \"#~\"\n\nEntering a new prompt. Type `,bt' for a backtrace or `,q' to continue."))

error("Error in evaluating guile expression: %s" "ice-9/boot-9.scm:1685:16: In procedure raise-exception:\n/home/christopher/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm:176:7: Unknown # object: \"#~\"\n\nEntering a new prompt. Type `,bt' for a backtrace or `,q' to continue.")

guix-geiser-eval("(help-string )" #<buffer *Guix Internal REPL*>)

guix-geiser-eval-read("(help-string )" #<buffer *Guix Internal REPL*>)

guix-eval-read("(help-string )")

guix-help-string(nil)

guix-command-parse-arguments(nil)

guix-command--all-arguments(nil)

guix-command-all-arguments(nil)

guix-command-generate-popup(guix-command-popup nil)

guix-command(nil)

funcall-interactively(guix-command nil)

call-interactively(guix-command)

magit-invoke-popup-action(99)

funcall-interactively(magit-invoke-popup-action 99)

call-interactively(magit-invoke-popup-action nil nil)

command-execute(magit-invoke-popup-action)

```

I noticed this issue using Emacs 30 pretest, and my normal init.el, but I also see the same error running the Emacs 29.4 binary with the -q option.

Here is my system information:

```

christopher@theoden

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

OS: Guix System x86_64

Host: OptiPlex 9020 00

Kernel: 5.15.166-gnu

Uptime: 7 days, 23 hours, 42 mins

Packages: 167 (guix-system), 251 (guix-user)

Shell: bash 5.1.16

Resolution: 1920x1080

DE: GNOME

Theme: Adwaita [GTK2/3]

Icons: Adwaita [GTK2/3]

Terminal: guix

CPU: Intel i5-4570 (4) @ 3.600GHz

GPU: AMD ATI Radeon HD 8490 / R5 235X OEM

GPU: Intel HD Graphics

Memory: 4203MiB / 15914MiB

```

``` M-x version

GNU Emacs 30.0.91 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-09-23

```

``` guix describe

Generation 145 Sep 13 2024 07:30:24 (current)

guix 013bda5

repository URL: https://git.savannah.gnu.org/git/guix.git

branch: master

commit: 013bda5e2c53bcf1d9093286c3658b95f5e32c09

```

--

? Christopher Howard

? gemini://gem.librehacker.com

? http://gem.librehacker.com

?????? ??? ????? ?? ????? ??? ????

In studying the bt and the code, it seems like the problem is here, in

/home/christopher/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm

around line 176

```

(define (invoke-command store machine command)

"Invoke COMMAND, a list of strings, on MACHINE. Display its output (if any)

and its error code if it's non-zero. Return true if COMMAND succeeded, false

otherwise."

(define invocation

#~(begin

(use-modules (ice-9 match)

(ice-9 rdelim)

(srfi srfi-11))

```

For some reason the "#~" g-expression syntax is not being recognized here, as far as I can tell without knowing much about g-expressions. I see that the (guix gexp) module is being used, so I suppose it must have something to do with the way the syntax is being used (misused?)

--

Christopher Howard

Christopher Howard <christopher@librehacker.com> writes:

In case relevant, on a foreign distribution with on Emacs 29.4 and

emacs-guix installed via MELPA (using the same commit emacs-guix uses

for upstream) I am unable to reproduce the issue.

However, the below allows me to observe the issue:

#+begin_src sh

guix shell emacs emacs-guix guix -- emacs -q

#+end_src

--

Suhail

I've been trying to look into this more, though my knowledge of guile and the guix scheme code is, frankly, quite limited. However, it seems like what is happening is that the guile/guix REPL chokes as soon as it come across its first gexp in guix/scripts/deploy.scm, line 176

Now, deploy.scm does load the gexp module:

However, the code in guix/gexp.scm that extends the reader is defined in an "(eval-when (expand load eval)" block, beginning at line 2267, with the read-hash-extend calls starting at line 2341. So, is maybe there some subtle bug at work here with the reader syntax not actually being loaded up when the *Guix Internal REPL* tries to run the guix shell code? Could someone highly knoweable in that subject take a look at this block of gexp.scm code again? I see some special code in the block for 3.0.8, so maybe something broke on transition to 3.0.9...?

--

Christopher Howard

With some exploration, I figured out I can make the popup work again by doing the following from inside *Guix Internal REPL*:

```

scheme@(emacs-guix)> ,m (guix gexp)

scheme@(guix gexp)> (read-hash-extend #\~ read-gexp)

(read-hash-extend #\$ read-ungexp)

(read-hash-extend #\+ (cut read-ungexp <> <> #t))

$12 = ((#\. . #<procedure 7f4a564aa3d0 at ice-9/boot-9.scm:2251:18 (c port)>))

$13 = ((#\~ . #<procedure read-gexp (chr port)>) (#\. . #<procedure 7f4a564aa3d0 at ice-9/boot-9.scm:2251:18 (c port)>))

$14 = ((#\$ . #<procedure read-ungexp (chr port #:optional native?)>) (#\~ . #<procedure read-gexp (chr port)>) (#\. . #<procedure 7f4a564aa3d0 at ice-9/boot-9.scm:2251:18 (c port)>))

scheme@(guix gexp)> ,m emacs-guix

```

I.e., if I drop into the (guix gexp) and run read-hash-extend myself. After that, I can successfully run M-x guix c. (The popup itself seems to have something else wrong with it, but we'll leave that for another bug report...)

It seems worth noting that I do have access to other variables and such inside the eval-when block, though I'm not sure what that tells us:

```

scheme@(emacs-guix)> ,m (guix gexp)

scheme@(guix gexp)> read-syntax-redefined?

$15 = #t

```

--

Christopher Howard

Feels like I'm shouting into the void here, but continuing to upload my troubleshooting notes anyway...

So, there seems to be some difference here between the *Guix REPL* buffer and the *Guix Internal REPL* buffer. From a fresh *Guix REPL*, I can run the commands with no problem:

```

scheme@(emacs-guix)> (help-string)

$12 = "Usage: ...snipped for brevity..."

$13 = ""

scheme@(emacs-guix)> ,m (guix scripts deploy)

scheme@(guix scripts deploy)> #~()

$14 = #<gexp () 7ff5757f60f0>

```

However, if I try the same thing from *Guix Internal REPL*, I get errors:

```

scheme@(emacs-guix) [1]> ,m (guix scripts deploy)

scheme@(guix scripts deploy) [1]> #~()

While reading expression:

socket:49:3: Unknown # object: "#~"

scheme@(guix scripts deploy) [1]> ,re

While executing meta-command:

/home/christopher/.config/guix/current/share/guile/site/3.0/guix/scripts/deploy.scm:176:7: Unknown # object: "#~"

```

I can get it to work if I reload (guix gexp) manually:

```

scheme@(guix scripts deploy) [1]> ,re (guix gexp)

scheme@(guix scripts deploy) [1]> #~()

$15 = #<gexp () socket:74:0 7ff56da2cba0>

scheme@(guix scripts deploy) [1]> ,m (emacs-guix)

scheme@(emacs-guix) [1]> (help-string)

$16 = "Usage: ...snipped for brevity..."

$17 = ""

```

And then after that the guix pop up also works.

So, I still don't know why the reader syntax is not loading correctly in the internal buffer, but at least it appears to be limited to just that buffer.

--

Christopher Howard

I've attached a patch for the emacs-guix source which works around this issue. It modifies the REPL starting process for the Internal REPL, so that the (guix gexp) module is explicitly (re)loaded, which allows to reader syntax to work when the other modules load. I do not know why this should be necessary.

I wondered if there is some subtle difference here when dealing with a REPL that is accessed over a socket, as is the case with the Internal REPL. But I can't reproduce the problem on the command-line, outside of emacs-guix, using sockets.

With this patch, the "guix shell command" popup opens, though I see there is something wrong with the popup itself. It does not ask for a command to run, and the popup options only attempt to run an empty command. But I could investigate that in a separate bug.

Troubleshooting/testing was done with GNU Emacs 30.0.92 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-10-29.

--

Christopher Howard