From: zimoun <zimon.toutoune@gmail.com>
To: "Pierre Neidhardt" <mail@ambrevar.xyz>, "Ludovic Courtès" <ludo@gnu.org>
Cc: Development of GNU Guix and the GNU System distribution
<guix-devel@gnu.org>, Ryan Prior <ryanprior@hey.com>
Subject: Re: Reviving Emacs-Guix
Date: Sat, 14 Nov 2020 19:40:50 +0100 [thread overview]
Message-ID: <86pn4fye6l.fsf@gmail.com> (raw)
In-Reply-To: <87h7prx2ut.fsf@ambrevar.xyz>
Hi Pierre,
I do not understand your arguments. Even re-reading all the thread.
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). And issues
about Geiser proper, compared to SLY or SLIME, and Geiser allows to work
interactively (*Guix REPL*).
On the other hand, you say that « pipe to “guix repl” » would not tackle
the issues you raise about interactive-ness.
> 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.
> For the latter, sending shell crafted commands have worked well for me.
> They can be sent to an M-x shell, Vterm or Eshell buffer.
>
> 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.
>> I do not understand your point. You are mixing 2 topics:
>>
>> - Emacs front-end for Guix
>> - Scheme mode for Emacs
>
> I don't want to mix the 2, emacs-guix does.
>
> I'm suggesting precisely this: don't mix up the Schemer environment with
> emacs-guix because of the load of trouble it brings in.
>
>> 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.
>
> This is not what I'm saying ;)
What are the issues of Geiser that are blocking in guix-popup?
>> For example, persistence between 2
>> calls.
>
> emacs-guix never relies on persistence if I'm not mistaken.
M-x guix-switch-to-repl
> 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 so instead I am
going to report what Emacs-Guix fails and what I would like to have. It
will be more fruitful. ;-)
>> 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.
>> 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!
There is still room of improvements, though. :-)
And others are broken, for instance:
M-x guix-popup c
> Try it out in Nyxt, you'll see for yourself :)
You know that I am trying Nyxt time to time. :-)
However, I am not convinced that on your side you are trying Emacs-Guix
to see for yourself. ;-)
>> Today, the real issue with Emacs-Guix is not Geiser, at all.
>
> 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.
Thank you for sharing your views. Now I am convinced that Emacs-Guix
needs love. :-)
Cheers,
simon
next prev parent reply other threads:[~2020-11-14 18:41 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 5:07 Announcing emacs-guix-packaging Ryan Prior
2020-11-10 13:30 ` Pierre Neidhardt
2020-11-12 20:53 ` Ludovic Courtès
2020-11-13 1:28 ` Ryan Prior
2020-11-13 9:45 ` Pierre Neidhardt
2020-11-13 13:20 ` zimoun
2020-11-13 14:54 ` John Soo
2020-11-13 16:54 ` Reviving Emacs-Guix Ludovic Courtès
2020-11-13 17:13 ` John Soo
2020-11-13 18:42 ` zimoun
2020-11-16 8:56 ` Ludovic Courtès
2020-11-14 9:42 ` Pierre Neidhardt
2020-11-14 12:57 ` zimoun
2020-11-14 15:59 ` Pierre Neidhardt
2020-11-14 16:56 ` zimoun
2020-11-14 17:30 ` Pierre Neidhardt
2020-11-14 18:40 ` zimoun [this message]
2020-11-14 19:15 ` Pierre Neidhardt
2020-11-14 19:52 ` Ricardo Wurmus
2020-11-14 21:29 ` zimoun
2020-11-15 7:37 ` Pierre Neidhardt
2020-11-15 13:15 ` zimoun
2020-11-15 14:11 ` Pierre Neidhardt
2020-11-15 15:23 ` zimoun
2020-11-15 15:45 ` Pierre Neidhardt
2020-11-15 16:05 ` zimoun
2020-11-14 21:11 ` zimoun
2020-11-15 7:53 ` Pierre Neidhardt
2020-11-14 19:49 ` Ricardo Wurmus
2020-11-15 7:36 ` Pierre Neidhardt
2020-11-16 9:02 ` Ludovic Courtès
2020-11-16 9:18 ` Pierre Neidhardt
2020-11-16 12:01 ` zimoun
2020-11-16 12:20 ` Pierre Neidhardt
2020-11-16 12:47 ` zimoun
2020-11-17 7:53 ` Pierre Neidhardt
2020-11-13 12:31 ` Announcing emacs-guix-packaging zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86pn4fye6l.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=mail@ambrevar.xyz \
--cc=ryanprior@hey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).