all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Carlo Zancanaro <carlo@zancanaro.id.au>
To: Leo Prikler <leo.prikler@student.tugraz.at>
Cc: guix-devel@gnu.org
Subject: Re: A new wip-emacs branch
Date: Thu, 08 Apr 2021 13:17:44 +1000	[thread overview]
Message-ID: <87y2dt4g87.fsf@zancanaro.id.au> (raw)
In-Reply-To: <506adf4a0893b51bdc5cdbc02bbd4c34952279b2.camel@student.tugraz.at>

Hi Leo!

Thanks so much for working to improve Emacs packaging in Guix! I 
have a question and a comment about your approach on the wip-emacs 
branch.

On Tue, Apr 06 2021, Leo Prikler wrote:
> Emacs now gets its core lisp path from the wrapper rather than 
> the search path and there's a new profile hook adding all 
> top-level subdirectories to a subdirs.el, that gets loaded at 
> startup.

This sounds great in terms of Emacs starting in an already 
established profile, but one key use case for me is to be able to 
install new packages without restarting Emacs. Usually I can do 
this in eshell by running

  $ guix install emacs-magit # shell command
  ...
  $ guix-emacs-autoload-packages # emacs command
  ...

I just tried this in a fresh profile with a Guix built from 
wip-emacs, but it didn't seem to work. It's possible that I've 
done something wrong (I'm doing it with time-machine, which adds 
its own complexities), but are you expecting this to work? It 
looks like guix-emacs wasn't loaded, and it wasn't on the load 
path, but I haven't had a chance to investigate further than that.

> Extending PATH in the same wrapper as EMACSLOADPATH seems to be 
> a fairly cheap option, however.

I'm not supportive of this, because extending PATH would also 
change the binaries that are available through Emacs' shells, 
which I use a lot. This would mean that either (a) the Emacs 
packages can shadow what I've explicitly installed in my profile, 
potentially leading to me running unexpected versions of programs, 
or (b) installing something else in my profile might break 
something in Emacs because the version has changed. This isn't 
likely to be a major problem for coreutils and gzip, assuming 
they're stable enough, but it is a problem in general. In my view 
either patching the Emacs libraries (to avoid the conflict) or 
propagating inputs (to expose the potential conflict while 
building the profile) are better options.

Thanks again!

Carlo


  parent reply	other threads:[~2021-04-08  3:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01  8:00 A new wip-emacs branch Leo Prikler
2021-04-01 12:21 ` pinoaffe
2021-04-03 11:37 ` Xinglu Chen
2021-04-03 11:57   ` Xinglu Chen
2021-04-03 15:30     ` Leo Prikler
2021-04-04  9:32       ` Xinglu Chen
2021-04-04 10:53         ` Leo Prikler
2021-04-06  9:06 ` Leo Prikler
2021-04-06 18:21   ` Xinglu Chen
2021-04-06 21:32     ` Leo Prikler
2021-04-07 10:07       ` Xinglu Chen
2021-04-07 17:54   ` Leo Prikler
2021-04-08  3:17   ` Carlo Zancanaro [this message]
2021-04-08  7:49     ` Leo Prikler
2021-04-08 14:05       ` Carlo Zancanaro

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2dt4g87.fsf@zancanaro.id.au \
    --to=carlo@zancanaro.id.au \
    --cc=guix-devel@gnu.org \
    --cc=leo.prikler@student.tugraz.at \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.