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

Previous Next

Full log

View this message in rfc822 format

From: Nicolas Graves <ngraves <at> ngraves.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 76699 <at> debbugs.gnu.org
Subject: [bug#76699] [PATCH emacs-guix 0/4] Refresh package emacs-guix
Date: Sun, 09 Mar 2025 00:25:02 +0100

On 2025-03-08 17:57, Ludovic Courtès wrote:

> Hello,
>
> Nicolas Graves <ngraves <at> ngraves.fr> skribis:
>
>> This is a series of refreshing commits for emacs-guix.
>
> Yay!
>
>> This is done in an effort to port emacs-guix to
>> guile-ares-rs/emacs-arei backend, currently in progress here :
>> https://git.sr.ht/~ngraves/emacs-guix
>
> 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/

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.

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

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.

> I haven’t tried it yet but it LGTM, except for patch #4.

Will look into that, thanks!

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) ;

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

IMHO, both would make it easier to maintain and extend the package, at the
cost of a little less "polish".  Sometimes less is more!

-- 
Best regards,
Nicolas Graves

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.