[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#42333: Emacs: error on guix-emacs-autoload-packages

From: Alexandru-Sergiu Marton
Subject: bug#42333: Emacs: error on guix-emacs-autoload-packages
Date: Sun, 19 Jul 2020 22:48:53 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi, sorry for the long time it took to reply.

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> If you could come with a minimal reproducer, I could have a look.
> Otherwise, I'm afraid there's too many variables to keep track
> (emacs-doom, possible conflicts with Org when installed from different
> places, etc.).

I managed to gather more information as I found another person who had
the same problems as me.

Steps to reproduce:
- Install emacs and emacs-telega with guix
- Install Doom Emacs (https://github.com/hlissner/doom-emacs)
- Start Emacs and try M-x telega RET

This should give you an error saying something along the lines of "No
file or directory." Even if it doesn't give you this exact same error,
check what I say below about load-path.

It seems that Doom plays with Emacs' load-path. Telega is just a
concrete example of an Emacs package installed with Guix that isn't
working. You should be able to find problems with many others.

When checking the value of the environment variable EMACSLOADPATH, both
the result from the shell (through echo $EMACSLOADPATH) and from Emacs
(through (getenv "EMACSLOADPATH")) seem to be equal. What is not right
is that the load-path Emacs Lisp variable doesn't contain the paths from

What fixed it for me and the other person was adding this line at the
end of our config.el (Doom's config file):

--8<---------------cut here---------------start------------->8---
(mapc (lambda (p) (add-load-path! p)) (split-string (getenv "EMACSLOADPATH") 
--8<---------------cut here---------------end--------------->8---

This is a hack but gets the job done for now.

I thought about this problem being caused by Doom's envvars file, but
that file contains the correct value of EMACSLOADPATH and we saw that
querying that environment variable from inside Emacs gives the correct

Finding the root of this problem will be beneficial to a lot of
potential Guix users that might ditch it if they see their beloved Emacs
config doesn't work well with packages installed from Guix.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]