guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reviving Emacs-Guix


From: zimoun
Subject: Re: Reviving Emacs-Guix
Date: Sat, 14 Nov 2020 17:56:40 +0100

Hi Pierre,

On Sat, 14 Nov 2020 at 16:59, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
>
>> Is it possible to currently build the packages using Emacs-Guix?
>>
>> And if you talk about ‘guix-devel-build-package-source‘, it needs before
>> to ’run-geiser’, I guess.
>
> Yes, using guix-devel-build-package-source, or even building by writing
> Scheme code in the Guix REPL.

Maybe I am missing the obvious but how the « pipe to “guix repl” »
approach could be an interactive REPL?


>>> - https://gitlab.com/emacs-geiser/geiser/-/issues/9
>>
>> 8 months is bunch of time but not a while. :-)
>
> Actually 9 months, but the issue has been there forever.

Yes, as any issue before being reported. ;-)


> The problem is the Schemers are just painfully dealing with the status
> quo.  I believe we need to address this.  Geiser is lagging behind by
> far, compared to what SLIME, SLY, racket-mode and CIDER can offer.

I do not understand your point.  You are mixing 2 topics:

 - Emacs front-end for Guix
 - Scheme mode for Emacs

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.

If your point is: shared code from « pipe to “guix repl” » could be used
both for an Emacs front-end and a Nyxt one, then maybe… And even I am
not convinced.


>>> - https://gitlab.com/emacs-geiser/geiser/-/issues/11
>>
>> 3 weeks is not a while, neither. ;-)
>
> Which 3 weeks?  I think you looked at Maxim's comment :p  The issue was
> also opened 9 months ago.

Right, I misread. :-)


>> For all what “guix-popup” does, maybe pipe to “guix repl” should
>> simplify.  But I do not see how one could work interactively without
>> Geiser; for example piping to “guix repl” can not fix your concern about
>> “Traces are not interactive”, fixing Geiser can.
>
> Yes, but my point is that since traces are mostly useless as it is now,
> we don't lose any benefit by using `guix repl'.
>
> 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?  For example, persistence between 2
calls.  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.

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

Today, the real issue with Emacs-Guix is not Geiser, at all.  The usage
is often annoying because Emacs-Guix is in low-maintenance mode.


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

Cheers,
simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]