Re: A new wip-emacs branch

[Leo Prikler <leo.prikler@student.tugraz.at>]

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