guix-devel
[Top][All Lists]
Advanced

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

Re: Reviving Emacs-Guix


From: Pierre Neidhardt
Subject: Re: Reviving Emacs-Guix
Date: Sat, 14 Nov 2020 20:15:44 +0100

Indeed, lots of misunderstandings in here.

I think it's because we are not talking about the same use cases of
Emacs-Guix.

The main issue I was talking about (there are many other issues indeed)
is that of _installing and building packages_ from Emacs Guix.

Run guix-devel-build-package-definition on a package definition.  If no
substitute is available, it will try to build the package in a REPL.  If
the build output is too long (happens very often!) it will choke Geiser.

WARNING: this might hang your emacs ;)

Does that make more sense?

> On one hand you are saying that Geiser is the issue of Emacs-Guix.  You
> raise issue with build (which ’guix-popup’ does not do).

`guix-popup` is only one of the many functions of emacs-guix.  I was not
talking about it.

> And issues about Geiser proper, compared to SLY or SLIME, and Geiser
> allows to work interactively (*Guix REPL*).

Misunderstanding: many emacs-guix commands run stuff in the *Guix REPL*
for the user.  (E.g. guix-devel-build-package-definition.)

I was not talking about the user interactive themselves with the
*Guix REPL*.  I think that's the confusion ;)

> On the other hand, you say that « pipe to “guix repl” » would not tackle
> the issues you raise about interactive-ness.

Indeed, I was not talking about REPL interactivity.

>> To answer all your points: `guix repl` woud only be used for queries,
>> not for transactions.
>
> AFAIU, guix-popup already does that.
>
> The annoyance that popups time to time are not related to Geiser but
> related the low-maintenance mode.  IMHO.

Add a breakpoint to `guix-geiser-eval`, you'll see.  Almost every
emacs-guix command depends on it.

Geiser is at the lowest level of all of Emacs-Guix.

>> Example: the user wants to build Emacs?
>> Make a dedicated "M-x shell" buffer and send "guix build emacs" there.
>
> Euh?  You can do the same with anything.  Simply use something else.
> I do not understand.

Hmm?  Why would I use something else?

To be more explicit, the "build packages passed as argument" could be
implemented by popping up a shell buffer and automatically executing

--8<---------------cut here---------------start------------->8---
$ guix install package-1 package-2...
--8<---------------cut here---------------end--------------->8---

in it.  In short, use `M-x shell` or equivalent instead of Geiser.

> What are the issues of Geiser that are blocking in guix-popup?

Try building a package as I suggested in the beginning.

>> emacs-guix never relies on persistence if I'm not mistaken.
>
> M-x guix-switch-to-repl

This is not persistence that's needed for the emacs-guix commands.

The commands to list generations, package info, etc. do no need
persistence.

>> 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.

> so instead I am going to report what Emacs-Guix fails and what I would
> like to have.  It will be more fruitful. ;-)

I've reported some of the issues, and I've concluded that some of them
would be resolved by not using Geiser to talk to Guix.

Of course fixing Geiser is an option, but it's a very rough road to take
I believe.

>>> 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.
>
> You are taking the part that more or less works in Emacs-Guix and want
> to replace it.  And the other part which is more broken, you remove it.

I think there is a misunderstanding.

Build a package does not work in Emacs Guix, and this is what I want
to fix, among other things.

I don't want to remove any feature from Emacs Guix.

For instance, we can keep the feature "switch to a Geiser REPL", while
at the same time not having _all_ actions depend on Geiser.

To sum up:

- Everything that needs Geiser (like "switch to REPL"), we keep.
- Everything else can use `guix repl` or direct shell invokations.

>>> 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.
>
> I do not know which version of Emacs-Guix you are using but all that is
> already available.  For example,
>
>    M-x guix-popup p L bro RET C-s ny RET RET
>    M-x guix-popup p N yxt$ RET
>    M-x guix-popup P a
>    M-x guix-popop P a
>    M-x guix-popop P l 2 RET
>
> etc.  And it works!

Try guix-devel-build-package-definition ;)


>> Emacs-Guix can't install a package a package that needs to be built
>> because of Geiser.  So yes, Geiser is the issue.
>
> The dirty-fix in the kind of “guix repl” fashion is easy: run
> “(guix-build args)” and expose the output in a specific buffer.
> Whatever.

It won't work, because the user must be able to interrupt the process.
So instead of re-inventing the wheel, it's better to let an Emacs mode
that already support process interruption do the job.

Cheers!

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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