From: Antero Mejr via Guix-patches via <guix-patches@gnu.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: 62848@debbugs.gnu.org, maxim.cournoyer@gmail.com
Subject: [bug#62848] [PATCH v2] environment: Add --remote option and emacsclient-eshell backend.
Date: Wed, 08 Nov 2023 15:34:28 +0000 [thread overview]
Message-ID: <87h6lwuum3.fsf@mailbox.org> (raw)
In-Reply-To: <16e985a5a6cc331daecfb58a1a737e6c6f76fa32.camel@gmail.com> (Liliana Marie Prikler's message of "Wed, 08 Nov 2023 06:29:03 +0100")
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> You have merged two changes into one patch imho. I think it'd be
> better if you swapped the wording first and then added the emacsclient
> code.
Fixed in updated patch set.
> Interestingly, this still won't support emacs sans client IIUC as we
> anyhow have to spawn a new process. Can we (perhaps in cooperation
> with guix-emacs) make it so that 'guix shell' spawned from eshell does
> "the right thing"?
Not 100% sure what you mean, but I do not think it is possible to start
eshell (or interact with an existing eshell) without using emacsclient
or starting a new emacs process. Starting a new emacs process is
cumbersome and doesn't make sense to me - I wouldn't want to start
another instance of emacs just to use a guix shell environment.
Currently, running guix shell in eshellwill invoke $SHELL, which seems
like the "right thing" but isn't very useful, since then you lose all
the eshell features.
The intention of this patch is that the user will have an emacs server
already running, via the forthcoming 'home-emacs-service-type' service
or some other method. Then guix shell can communicate with that server
to set up the environment in a new eshell buffer.
prev parent reply other threads:[~2023-11-08 15:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-15 1:44 [bug#62848] [PATCH] environment: Add --remote option and emacsclient-eshell backend Antero Mejr via Guix-patches via
2023-09-01 13:26 ` Maxim Cournoyer
2023-11-07 22:30 ` [bug#62848] [PATCH v2] " Antero Mejr via Guix-patches via
2023-11-08 5:29 ` Liliana Marie Prikler
2023-11-08 15:19 ` [bug#62848] [PATCH 1/2] guix: Rename white-list to allow-list Antero Mejr via Guix-patches via
2023-11-08 15:21 ` [bug#62848] [PATCH 2/2] environment: Add --remote option and emacsclient-eshell backend Antero Mejr via Guix-patches via
2023-11-08 19:32 ` Liliana Marie Prikler
2023-11-08 15:34 ` Antero Mejr via Guix-patches via [this message]
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=87h6lwuum3.fsf@mailbox.org \
--to=guix-patches@gnu.org \
--cc=62848@debbugs.gnu.org \
--cc=antero@mailbox.org \
--cc=liliana.prikler@gmail.com \
--cc=maxim.cournoyer@gmail.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).