From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: bug#38273: emacs doesn't open files Date: Thu, 21 Nov 2019 22:46:28 -0500 Message-ID: <87lfs8fu97.fsf@gmail.com> References: <87zhgrv8kh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56038) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXzuS-0000nG-5M for bug-guix@gnu.org; Thu, 21 Nov 2019 22:47:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXzuQ-0006Al-QA for bug-guix@gnu.org; Thu, 21 Nov 2019 22:47:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:44777) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iXzuQ-0006Ae-M8 for bug-guix@gnu.org; Thu, 21 Nov 2019 22:47:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iXzuQ-0008SM-Fc for bug-guix@gnu.org; Thu, 21 Nov 2019 22:47:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: (zimoun's message of "Wed, 20 Nov 2019 18:19:51 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: zimoun Cc: 38273@debbugs.gnu.org, Jesse Gibbons Hello Zimoun, zimoun writes: > Hi Maxim, > > Thank you to looking. > > On Tue, 19 Nov 2019 at 22:51, Maxim Cournoyer = 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 =E2=94=94=E2=94=80=E2=94=80 share =E2=94=9C=E2=94=80=E2=94=80 doc =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 emacs-grep-a-lot-1.0.7 =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 COPYING =E2=94=94=E2=94=80=E2=94=80 emacs =E2=94=94=E2=94=80=E2=94=80 site-lisp =E2=94=94=E2=94=80=E2=94=80 guix.d =E2=94=94=E2=94=80=E2=94=80 grep-a-lot-1.0.7 =E2=94=9C=E2=94=80=E2=94=80 grep-a-lot-autoloads.el =E2=94=9C=E2=94=80=E2=94=80 grep-a-lot.el =E2=94=94=E2=94=80=E2=94=80 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