bug#38273: emacs doesn't open files

[Maxim Cournoyer]

Hello Zimoun,

zimoun <address@hidden> writes:

> Hi Maxim,
>
> Thank you to looking.
>
> On Tue, 19 Nov 2019 at 22:51, Maxim Cournoyer <address@hidden> wrote:
>
>> Did you sort out your issue?  Perhaps logging out then back in could
>> define the missing EMACSLOADPATH environment variable? Or manually
>> sourcing your current profile's etc/profile and starting Emacs from that
>> shell?
>
> Yes, sourcing the current etc/profile fixes the issue.
>
> Therefore, EMACSLOADPATH should be the culprit and I had done a
> mistake, not enough investigating before reporting. My bad! Sorry!

There's no need to be sorry; that's a pitfall many are likely to
encounter sooner or later.  I'm thinking one common place it'd bite
users would be when they use their desktop manager's application
launcher to start Emacs:  in this case, the EMACSLOADPATH would be taken
from what it was at the time they logged in their session, and would
never be refreshed until the next login.

Example of use case:

1. The user logs in.
2. The user starts Emacs using their DM's application launcher.
3. The user runs 'guix install emacs-paredit in a terminal.
4. The user try "M-x paredit" in their Emacs, only to find out it doesn't
exist.
5. User restart Emacs (again launching it from their application
launcher), but it still doesn't find the `paredit function.

The reason the above use case doesn't work is because the EMACSLOADPATH
environment variable inherited by the desktop manager is fixed and not
refreshed by 'guix install'.  It only gets refreshed when the user logs
out then back in.

This use case could work if all of our packages would be installed to a
single, such as some packages already do (emacs-magit and
emacs-guix) both live under share/emacs/site-lisp.  If all the packages
were installed there, Emacs would find newly installed packages and the
EMACSLOADPATH not being refreshed wouldn't be as much of a problem.

Examples of packages that depend on the EMACSLOADPATH being refreshed
are the packages installed to their own namespaced directory the
share/emacs/site-lisp/guix.d prefix.  One such example is
'emacs-grep-a-lot':

--8<---------------cut here---------------start------------->8---
tree /gnu/store/vhk1ljc45jn465xk3lqx0030qlkp53ws-emacs-grep-a-lot-1.0.7
/gnu/store/vhk1ljc45jn465xk3lqx0030qlkp53ws-emacs-grep-a-lot-1.0.7
└── share
    ├── doc
    │   └── emacs-grep-a-lot-1.0.7
    │       └── COPYING
    └── emacs
        └── site-lisp
            └── guix.d
                └── grep-a-lot-1.0.7
                    ├── grep-a-lot-autoloads.el
                    ├── grep-a-lot.el
                    └── grep-a-lot.elc
--8<---------------cut here---------------end--------------->8---

The motivation for the above layout was to make sure the package files
wouldn't clash together.  I'm not sure if this motivation is truly
important, given that all the Emacs symbols are global and must already
be uniquely named to avoid clashes (the common thing to do is to use a
prefix named after the package for every procedure/variables defined);
I'd expect the same rigor to be employed when naming the package files.

So, there's a couple things we could do to make the life of users
better:

1) Deprecate the use of guix.d and adapt the emacs-build-system so that
it stops producing it.
2) Contribute a patch to Emacs so that the directories present in the
EMACSLOADPATH would be searched recursively for packages.
3) Do nothing and expect the users to use the
'guix-set-emacs-environment' (from emacs-guix) to source their user
profile so that EMACSLOADPATH is refreshed, then issue
'guix-emacs-autoload-packages' (from the site-start.el shipped with our
Emacs package).

The third option seems like too complicated and bothersome to be worth
explaining to newcomers, so I'd personally go for either 1 or 2.

What do you think?

Maxim