[bug#76699] [PATCH emacs-guix 0/4] Refresh package emacs-guix

[Ludovic Courtès]

Hi,

Nicolas Graves <ngraves@ngraves.fr> skribis:

>> I remain fond of Geiser so I’m skeptical of this change.  Perhaps you
>> could explain a bit why you think it’s worthwhile?
>
> Both could exist together if we remain coordinated (hence first the
> effort to improve, before efforts to port ;), "port" here is not
> necessarily meant to replace.
>
> I'm not qualified enough myself to judge, let's say that I've been sold
> to ares/arei by the asynchronous/fluency/protocol guarantees. Andrew
> Tropin's talk on EmacsConf 2023 elaborate more on why the project was
> started in the first place.
>
> https://emacsconf.org/2023/talks/scheme/

OK, I should take a look.

> I've found it convenient to write and test scheme (a bit less finished
> on the user's side -- you still have to start the server manually) ; but
> overall I find it quite pleasant to use, simply write and evaluate the
> code I'm writing without having to write to copy/paste.

Agreed, same with Geiser and other such tools.

> What I would want such a package to do is also to have convenient
> features like:
> - guix packages recognition while developping (for embark actions)
> - guix-lint/flymake integration + embark action
> - guix-style embark action

Would be nice!

> I see this kind of things possible with ares ; I don't know geiser
> enough to know if it's possible / convenient / how to tackle them
> properly.

Geiser essentially talks to a running Guile REPL in a request/response
style.  Its downside is that it’s synchronous, and that’s something ares
probably improves on, but for the rest it’s really good.

> By the way, I would like to get rid of emacs-bui too, I think it adds a
> lot of complexity / it is one of the reasons emacs-guix is hard to
> maintain.  I was thinking about
>
> - rewriting the completing-read part // replacing the list mode
> functionality with a completing-read that would list synopses when
> present with packages like vertico/marginalia (so no more dedicated
> mode, just a more carefully written completing-read) ;

I’m not qualified enough to judge, but removing code can be nice.  :-)

> - replacing the guix-ui mode with its proper transient (on *Guix info*,
> hitting `h` almost spawns a transient-like menu, so it might be more
> maintainable with transient itself, and with a popping transient,
> there's no need for buttons), and probably a beautified read-only
> rec-mode like interface ; if we manage to inject recutils from scheme,
> it might be a lot less code to maintain in emacs-guix.

I’m not sure I’d rely on ‘rec-mode’ for this (I think the current
interface is more pleasant than a raw recutils record as view with
rec-mode, and it’s interactive too), but I don’t know.

Thanks,
Ludo’.