zimoun <zimon.toutoune@gmail.com> writes:

>> `guix-popup` is only one of the many functions of emacs-guix.  I was not
>> talking about it.
>
> About which one are you talking?  Except “build” that we already
> discussed above.

I've raised mostly 2 issues in this conversation, the ones I've
mentioned on GitLab, sorry if that was unclear :)

- https://gitlab.com/emacs-geiser/geiser/-/issues/9
  Geiser chokes on big outputs, so guix-devel-build-package-definition
  is not usable.

  Proposed solution: Use a non-Geiser comint mode like IELM or M-x
  shell.
  Or Eshell (not a comint-mode though).

- https://gitlab.com/emacs-geiser/geiser/-/issues/11

  This one can seriously hang your Emacs when calling
  `geiser-mode-switch-to-repl-and-enter` from a .scm of an
  not-fully-built Guix.

  I remember hitting this issue with emacs-guix, but I can't remember a
  recipe.
  So maybe this has nothing to do with emacs-guix after all, but let's
  keep it in mind in case it comes up again.


Then I remembered another one:

- https://gitlab.com/emacs-guix/emacs-guix/-/issues/8

  It's unclear to me whether this one is due to Geiser or not.
  I can still reproduce it today.

> That’s a feature as Ludo and Ricardo said. From my opinion too.
>
> What’s wrong with the sequence:

Nothing wrong!

> Ok, but that the same story as ’build’.  Right?

Yes.

>> This is not persistence that's needed for the emacs-guix commands.
>
> Wait, you said « emacs-guix never relies on persistence if I'm not
> mistaken. » which is wrong because everything is sent to *Guix REPL*
> (Geiser) reachable with “M-x guix-switch-to-repl“ as shown above.

It does not _rely_ on it, in the sense that it's not necessary, it could
work very well without it.

>>>> My suggestion indeed lacks persistence, but at least it works for now
>>>> until we figure out something better.
>>>
>>> Now you convinced me that Emacs-Guix needs love.  Well the “it works” in
>>> « at least it works for now » is meaningless for me
>>
>> Why?  A program that works is meaningful I believe.
>
> Which program are you talking about?

Helm-System-Packages and Nyxt are 2 example programs that can talk to
Guix reliably.

Not saying we should use them instead, of course.
But this technique is worth exploring to make Emacs-Guix more reliable.

> Maybe.  It should be addressed action by action.  Instead of thrashing
> Geiser.  IMHO.

I didn't mean to thrash (or did you mean "trash"?) Geiser, sorry if that
came across this way.

I just wanted to highlight some hard-to-fix (design?) issue with Geiser
that come in the way of Emacs-Guix, so _in the context of Emacs Guix_, I
believe that leveraging other means of communicating with Guix can be a
good idea, at least for some operations like building packages.

> What are the « among other things »?

For instance:

- https://gitlab.com/emacs-guix/emacs-guix/-/merge_requests/8

- Channels support
  https://gitlab.com/emacs-guix/emacs-guix/-/issues/17

The above has nothing to do with Geiser of course, as you
said, the fix is love! :)

Cheers!

--
Pierre Neidhardt
https://ambrevar.xyz/