Ricardo Wurmus <rek...@elephly.net> writes:
> Is it *actually* broken? If it is and you can provide information on
> how to trigger the broken behavior we might be a step closer to fixing
> it.
I believe it's unclear how to ensure that it is configured
correctly. I.e., I believe the package mostly works when configured
correctly, but what the correct configuration is is unclear. It also
doesn't help that the discussions are fragmented across Gitlab,
issues.guix.gnu.org , IRC, and, now, this mailing list.
FWIW, I'll note below some things I tried and my observations below.
guix shell -C --no-cwd --expose=/gnu --expose=/var --share=/tmp -E DISPLAY -E
TERM emacs emacs-guix bash unzip -- emacs
With the above invocation, I was able to invoke M-x guix-popup, but
every subsequent command I tried after that resulted in failure (an
exception was raised).
Locally, in my host system, I was able to get most of the commands
working by simply ensuring that GUILE_LOAD_PATH had the specific
guix-module-union entry that was present in %load-path within
"guix repl". Doing so, every command from M-x guix-popup worked except
for M-x guix-command which would result in an exception.
The instructions on the Gitlab issue (cross-posted on
issues.guix.gnu.org) either have a typo or have
bit-rotted. Specifically, it's guix-config-guile-program and not
guix-guile-program that helps when overridden.
(with-eval-after-load 'guix-repl
(setq guix-config-guile-program '("guix" "repl")
guix-repl-use-server nil))
With the above configuration (or its equivalent use-package translation)
I was able to ensure that M-x guix-command no longer raised the
exception. It still doesn't quite work correctly (the specific guix
command to run isn't prompted for), but it's better than before.
IMO it would help to document the minimal configuration that's needed to
make emacs-guix work as intended. And for this to be testable via some
"guix shell -C" invocation which is also documented.
--
Suhail
