To answer all your points: `guix repl` woud only be used for queries,
not for transactions.

For the latter, sending shell crafted commands have worked well for me.
They can be sent to an M-x shell, Vterm or Eshell buffer.

Example: the user wants to build Emacs?
Make a dedicated "M-x shell" buffer and send "guix build emacs" there.

The great benefit is that the user is in a familiar environment and can
do stuff like "C-c C-c"

>> Actually 9 months, but the issue has been there forever.
>
> Yes, as any issue before being reported. ;-)

No, sometimes issue appear after features are implemented, or after
regressions.

It's not the case here: these issues exist since the beginning of
Geiser.
It's important, because it highlights design flaws.

> I do not understand your point.  You are mixing 2 topics:
>
>  - Emacs front-end for Guix
>  - Scheme mode for Emacs

I don't want to mix the 2, emacs-guix does.

I'm suggesting precisely this: don't mix up the Schemer environment with
emacs-guix because of the load of trouble it brings in.

> and then applying kind of transitivity: Geiser is poor (compared to
> SLIME or SLY) so it cannot be used for Guix at all.  Applying the same
> trick: the number of packages in Guix is poor (compared to Debian or
> Nix) so Guix cannot be used at all.

This is not what I'm saying ;)

>> We have 2 options:
>>
>> - Fixing Geiser, which might take a long time, leaving us with a broken
>>   emacs-guix for the time being.
>>   It's not even clear that it can be done without rewriting everything.
>>
>> - Or use `guix repl`, which is known to work, already has working code
>>   out there, and can be deployed in a week or two.
>>
>> I find the second option more attractive.
>
> You do not convince me.  Because you do not answer to the question: how
> one could work interactively without Geiser?  How «pipe to “guix repl”»
> could lead to interactive work?

See above.

> For example, persistence between 2
> calls.

emacs-guix never relies on persistence if I'm not mistaken.

My suggestion indeed lacks persistence, but at least it works for now
until we figure out something better.

> And solving that is somehow inheriting from ’comint-mode’ and so
> more less rewrite ’geiser-repl.el’; but Guix specific only.  Maybe I am
> missing the obvious.

Sorry I didn't get this part.

> Maybe «pipe to “guix repl”» could simplify what “guix-popup” does.
> Even, I am not convinced.

Not just that, but listing packages, package details, output listing,
profile listing, generation listing, etc.

Try it out in Nyxt, you'll see for yourself :)

> Today, the real issue with Emacs-Guix is not Geiser, at all.

Emacs-Guix can't install a package a package that needs to be built
because of Geiser.  So yes, Geiser is the issue.

> Well, at the end, the only judge is the effective code. ;-)

I have a proof of concept that works :)

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