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

  This is a series of refreshing commits for emacs-guix.

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

This is still a WIP, I'd still like to replace old references to
guix-environment by references to guix shell at least.  I'm not able
to test all changes, since guix-command seems to be broken (before
this patch series I mean).

Thus, I invite users of emacs-guix to try that series and report any
bug that could have been caused by it.

Nicolas Graves (5):
  Switch to transient
  Improve most docstrings
  Remove dash dependency, introduce llama library
  Use a development channel instead of guix.scm
  Update NEWS

 .guix-channel                              |   3 +
 NEWS                                       |  10 +
 README                                     |   2 +-
 guix.scm => channel/emacs-guix-channel.scm |  69 +++----
 channel/emacs-guix-channel.scm.next        | 104 ++++++++++
 configure.ac                               |  32 +--
 doc/emacs-guix.texi                        |  59 +++---
 doc/htmlxref.cnf                           |   6 +-
 elisp/guix-about.el                        |   2 +-
 elisp/guix-build-config.el.in              |   7 +-
 elisp/guix-build-log.el                    |  28 +--
 elisp/guix-command.el                      | 162 ++++++++-------
 elisp/guix-config.el                       |   2 +-
 elisp/guix-default-config.el               |   2 +-
 elisp/guix-external.el                     |  12 +-
 elisp/guix-geiser.el                       |   9 +-
 elisp/guix-graph.el                        |   2 +-
 elisp/guix-guile.el                        |   6 +-
 elisp/guix-help-vars.el                    |  37 ++--
 elisp/guix-help.el                         |  15 +-
 elisp/guix-license.el                      |   3 +-
 elisp/guix-misc.el                         |  24 ++-
 elisp/guix-package.el                      |   2 +-
 elisp/guix-pcomplete.el                    |  15 +-
 elisp/guix-popup.el                        | 227 ---------------------
 elisp/guix-prettify.el                     |   4 +-
 elisp/guix-profiles.el                     |  32 +--
 elisp/guix-read.el                         |   8 +-
 elisp/guix-repl.el                         |  43 ++--
 elisp/guix-transient.el                    | 187 +++++++++++++++++
 elisp/guix-ui-generation.el                |  62 +++---
 elisp/guix-ui-license.el                   |  18 +-
 elisp/guix-ui-lint-checker.el              |  15 +-
 elisp/guix-ui-messages.el                  |  16 +-
 elisp/guix-ui-package-location.el          |   6 +-
 elisp/guix-ui-package.el                   | 104 +++++-----
 elisp/guix-ui-profile.el                   |  65 +++---
 elisp/guix-ui-service-location.el          |   6 +-
 elisp/guix-ui-service.el                   |  32 ++-
 elisp/guix-ui-store-item.el                |  46 +++--
 elisp/guix-ui-system-generation.el         |  24 ++-
 elisp/guix-ui-system.el                    |  17 +-
 elisp/guix-ui.el                           |  16 +-
 elisp/guix-utils.el                        |  92 ++++-----
 elisp/guix.el                              |   2 +-
 elisp/local.mk                             |  10 +-
 46 files changed, 895 insertions(+), 750 deletions(-)
 create mode 100644 .guix-channel
 rename guix.scm => channel/emacs-guix-channel.scm (50%)
 create mode 100644 channel/emacs-guix-channel.scm.next
 delete mode 100644 elisp/guix-popup.el
 create mode 100644 elisp/guix-transient.el
  

Hello,

Nicolas Graves <ngraves@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?

> This is still a WIP, I'd still like to replace old references to
> guix-environment by references to guix shell at least.  I'm not able
> to test all changes, since guix-command seems to be broken (before
> this patch series I mean).
>
> Thus, I invite users of emacs-guix to try that series and report any
> bug that could have been caused by it.

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

Ludo’.
  

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

> Hello,
>
> Nicolas Graves <ngraves@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!
  

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

Would you rather create an emacs-guix-next package and call users to try
it, or rather just make this update?

I ask because the new development channel should adapt to how we'll
include that in guix (is modify-inputs necessary or not ?)

Nicolas
  

On 2025-03-09 22:05, Ludovic Courtès wrote:
>
>> - 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.

My point here is that I would prefer a new transient menu in this *Guix
package info* instead of sparse buttons, since it's already based on
transient.  I agree the view is more pleasant, but I think it's quite
likely that the emacs-bui package will not be developped
again. `rec-mode` is probably too rough, I'll try and find an
intermediary alternative.
  

Interested on testing !

> Thus, I invite users of emacs-guix to try that series and report any
> bug that could have been caused by it.

Cloned the sr.ht repo, changed branch to arei, but there is no guix.scm
file to install with

    guix package --install-from-file=guix.scm

right ?