unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Carlo Zancanaro <carlo@zancanaro.id.au>
Cc: guix-devel@gnu.org
Subject: Re: A new wip-emacs branch
Date: Thu, 08 Apr 2021 09:49:43 +0200	[thread overview]
Message-ID: <a27bfe54c1cecf68d01b36018bce80a7fd558968.camel@student.tugraz.at> (raw)
In-Reply-To: <87y2dt4g87.fsf@zancanaro.id.au>

Hi Carlo,

Am Donnerstag, den 08.04.2021, 13:17 +1000 schrieb Carlo Zancanaro:
> 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.
guix-emacs should still be loaded by site-start.el, which also
initially loads your autoloads.  What changes for "Guix in Emacs
modifying Emacs", is that you'll probably have to reload the subdirs.el
file before autoloading the packages.
The following snippet in (normal-top-level) seems to be responsible for
setting up the load-path during init:

    ;; Look in each dir in load-path for a subdirs.el file.  If we
    ;; find one, load it, which will add the appropriate subdirs of
    ;; that dir into load-path.  This needs to be done before setting
    ;; the locale environment, because the latter might need to load
    ;; some support files.
    ;; Look for a leim-list.el file too.  Loading it will register
    ;; available input methods.
    (let ((tail load-path)
          (lispdir (expand-file-name "../lisp" data-directory))
          dir)
      (while tail
        (setq dir (car tail))
        (let ((default-directory dir))
          (load (expand-file-name "subdirs.el") t t t))
        ;; Do not scan standard directories that won't contain a leim-
list.el.
        ;; https://lists.gnu.org/r/emacs-devel/2009-10/msg00502.html
        ;; (Except the preloaded one in lisp/leim.)
        (or (string-prefix-p lispdir dir)
            (let ((default-directory dir))
              (load (expand-file-name "leim-list.el") t t t)))
        ;; We don't use a dolist loop and we put this "setq-cdr"
command at
        ;; the end, because the subdirs.el files may add elements to
the end
        ;; of load-path and we want to take it into account.
        (setq tail (cdr tail))))

Perhaps we should extract it as a whole/some bits of it into a guix-
emacs procedure, that is normally not called?

> > 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.
I don't think I agree with you here.  For one, I'd suffix PATH like
EMACSLOADPATH, so (a) will not happen.  Recall, that in (b) you're
describing the status quo.  Yes, you will be able to bork Emacs by
installing a malicious version of coreutils into your PATH, but that'd
also happen if you did so currently.  The only difference, is that you
currently also bork it, if you don't have any coreutils at all, which
is typically only the case in pure environments or containers.

As for Emacs libraries written in Elisp, I'm kinda split.  I'm not even
sure if they should have a fallback when your environment is borked
tbh.  Consider Geiser for example.  To correctly set up Geiser+Guile,
you would not only Guile to be installed, but also GUILE_LOAD_PATH to
be set to a meaningful value.  This can be done with Guix environments
by adding Guile, but doing so without Guile and its search paths from
elisp is somewhat difficult.  I also enjoy being able to hack with
Geiser in Guile 3, even though the package builds against Guile 2.2,
without needing to install a different one.

Obviously, there are exceptions to this, that we can argue on a case by
case basis, but to summarize, I don't think hardcoding paths throughout
Emacs is a good idea.

Regards,
Leo



  reply	other threads:[~2021-04-08  7:50 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
2021-04-08  7:49     ` Leo Prikler [this message]
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

  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=a27bfe54c1cecf68d01b36018bce80a7fd558968.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=carlo@zancanaro.id.au \
    --cc=guix-devel@gnu.org \
    /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).