From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:32970) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWZwF-0001LU-VP for guix-patches@gnu.org; Mon, 18 Nov 2019 00:51:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWZwE-0006sM-KD for guix-patches@gnu.org; Mon, 18 Nov 2019 00:51:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:34231) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iWZwE-0006sC-06 for guix-patches@gnu.org; Mon, 18 Nov 2019 00:51:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iWZwD-00086C-QK for guix-patches@gnu.org; Mon, 18 Nov 2019 00:51:01 -0500 Subject: [bug#38015] Emacs in multiple profiles Resent-Message-ID: From: Maxim Cournoyer References: <9c395fd0-9458-7894-af8b-9294d212c60b@fastmail.net> <87a7uyd7qy.fsf@gmail.com> <874ll51mq3.fsf@gmail.com> <87zi2t4jgh.fsf@gmail.com> <877ep4z44b.fsf@gmail.com> <87tv88ihzc.fsf@ambrevar.xyz> <878spgo7ex.fsf@gmail.com> <87o8yccwtq.fsf@ambrevar.xyz> <871rv1ed8v.fsf@gmail.com> <87mudpm5nt.fsf@ambrevar.xyz> <874kzscpgs.fsf@gmail.com> <87eeyvespq.fsf@ambrevar.xyz> <87zhhhbhzl.fsf@gmail.com> <877e4l5c9h.fsf@ambrevar.xyz> <87mudgb4v5.fsf@gmail.com> <875zjp1xsf.fsf@gmail.com> <87ftittvht.fsf@ambrevar.xyz> <87eeyc452y.fsf@gmail.com> Date: Mon, 18 Nov 2019 14:50:32 +0900 In-Reply-To: <87eeyc452y.fsf@gmail.com> (Chris Marusich's message of "Tue, 12 Nov 2019 23:18:29 -0800") Message-ID: <87r225u40n.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Chris Marusich Cc: myglc2@gmail.com, 38015@debbugs.gnu.org, Pierre Neidhardt , help-guix@gnu.org, Alex Kost Hello Chris, Chris Marusich writes: [...] I've skipped your previous questions, as I believe they were well answered by Pierre (thank you, Pierre!). >> Subject: [PATCH 2/3] build-system: emacs: Simplify the SET-EMACS-LOAD-PATH >> phase. >> >> +(define* (add-source-to-load-path #:key dummy #:allow-other-keys) >> + "Augment the EMACSLOADPATH environment variable with the source directory." >> (let* ((source-directory (getcwd)) >> - (input-elisp-directories (input-directories->el-directories >> - (inputs->directories inputs))) >> - (emacs-load-path-value >> - (string-join >> - (append input-elisp-directories (list source-directory)) >> - ":" 'suffix))) >> + (emacs-load-path-value (string-append (getenv "EMACSLOADPATH") ":" >> + source-directory))) >> (setenv "EMACSLOADPATH" emacs-load-path-value) >> - (format #t "environment variable `EMACSLOADPATH' set to ~a\n" >> - emacs-load-path-value))) >> + (format #t "source directory ~s appended to the `EMACSLOADPATH' \ >> +environment variable\n" source-directory))) > > It looks like the change is as follows: previously, we added multiple > directories, including the source-directory, to the load path; after > this change, we append just the source-directory to the EMACSLOADPATH. > Can you remind me why we don't need to add the other elisp directories > to the EMACSLOADPATH, too? It seems to work, so I'm probably just > missing something obvious. The magic is in the set-paths phase that is inherited from the gnu-build-system. It uses the search path specification now specified in the Emacs package to set the EMACSLOADPATH environment variable itself. When building Elisp packages, it is useful to add the current source directory to that environment variable, so that 'require' directives are able to find the package's own modules (say, when running its test suite). >> Subject: [PATCH 3/3] gnu: emacs: Adapt the autoloads auxiliary code to use >> EMACSLOADPATH. > > As far as I can tell, this looks good to me, too. > > Finally: do you anticipate that this will cause any user-visible or > backwards-incompatible changes that we should mention in the Guix > channel's news file (and in the Guix NEWS file)? Thanks for the review! I can't anticipate any user-visible changes except the current (incorrect) behavior. This change is now live on master, with commit 47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c. Thanks for testing :-). Maxim From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: Re: [bug#38015] Emacs in multiple profiles Date: Mon, 18 Nov 2019 14:50:32 +0900 Message-ID: <87r225u40n.fsf@gmail.com> References: <9c395fd0-9458-7894-af8b-9294d212c60b@fastmail.net> <87a7uyd7qy.fsf@gmail.com> <874ll51mq3.fsf@gmail.com> <87zi2t4jgh.fsf@gmail.com> <877ep4z44b.fsf@gmail.com> <87tv88ihzc.fsf@ambrevar.xyz> <878spgo7ex.fsf@gmail.com> <87o8yccwtq.fsf@ambrevar.xyz> <871rv1ed8v.fsf@gmail.com> <87mudpm5nt.fsf@ambrevar.xyz> <874kzscpgs.fsf@gmail.com> <87eeyvespq.fsf@ambrevar.xyz> <87zhhhbhzl.fsf@gmail.com> <877e4l5c9h.fsf@ambrevar.xyz> <87mudgb4v5.fsf@gmail.com> <875zjp1xsf.fsf@gmail.com> <87ftittvht.fsf@ambrevar.xyz> <87eeyc452y.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:32896) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWZvp-0000w9-9A for help-guix@gnu.org; Mon, 18 Nov 2019 00:50:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWZvo-0006fr-2A for help-guix@gnu.org; Mon, 18 Nov 2019 00:50:37 -0500 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]:38955) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iWZvn-0006fC-US for help-guix@gnu.org; Mon, 18 Nov 2019 00:50:36 -0500 Received: by mail-qt1-x844.google.com with SMTP id t8so18952151qtc.6 for ; Sun, 17 Nov 2019 21:50:35 -0800 (PST) In-Reply-To: <87eeyc452y.fsf@gmail.com> (Chris Marusich's message of "Tue, 12 Nov 2019 23:18:29 -0800") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Chris Marusich Cc: myglc2@gmail.com, 38015@debbugs.gnu.org, help-guix@gnu.org, Alex Kost Hello Chris, Chris Marusich writes: [...] I've skipped your previous questions, as I believe they were well answered by Pierre (thank you, Pierre!). >> Subject: [PATCH 2/3] build-system: emacs: Simplify the SET-EMACS-LOAD-PATH >> phase. >> >> +(define* (add-source-to-load-path #:key dummy #:allow-other-keys) >> + "Augment the EMACSLOADPATH environment variable with the source directory." >> (let* ((source-directory (getcwd)) >> - (input-elisp-directories (input-directories->el-directories >> - (inputs->directories inputs))) >> - (emacs-load-path-value >> - (string-join >> - (append input-elisp-directories (list source-directory)) >> - ":" 'suffix))) >> + (emacs-load-path-value (string-append (getenv "EMACSLOADPATH") ":" >> + source-directory))) >> (setenv "EMACSLOADPATH" emacs-load-path-value) >> - (format #t "environment variable `EMACSLOADPATH' set to ~a\n" >> - emacs-load-path-value))) >> + (format #t "source directory ~s appended to the `EMACSLOADPATH' \ >> +environment variable\n" source-directory))) > > It looks like the change is as follows: previously, we added multiple > directories, including the source-directory, to the load path; after > this change, we append just the source-directory to the EMACSLOADPATH. > Can you remind me why we don't need to add the other elisp directories > to the EMACSLOADPATH, too? It seems to work, so I'm probably just > missing something obvious. The magic is in the set-paths phase that is inherited from the gnu-build-system. It uses the search path specification now specified in the Emacs package to set the EMACSLOADPATH environment variable itself. When building Elisp packages, it is useful to add the current source directory to that environment variable, so that 'require' directives are able to find the package's own modules (say, when running its test suite). >> Subject: [PATCH 3/3] gnu: emacs: Adapt the autoloads auxiliary code to use >> EMACSLOADPATH. > > As far as I can tell, this looks good to me, too. > > Finally: do you anticipate that this will cause any user-visible or > backwards-incompatible changes that we should mention in the Guix > channel's news file (and in the Guix NEWS file)? Thanks for the review! I can't anticipate any user-visible changes except the current (incorrect) behavior. This change is now live on master, with commit 47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c. Thanks for testing :-). Maxim