GNU bug report logs - #28832
[PATCH 0/3] gnu: Add emacs-json-mode.

Previous Next

Full log

View this message in rfc822 format

From: Alex Kost <alezost <at> gmail.com>
To: Oleg Pykhalov <go.wigust <at> gmail.com>
Cc: 28832 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: [bug#28832] [PATCH 1/3] gnu: Add emacs-json-reformat.
Date: Fri, 22 Dec 2017 23:20:40 +0300

Oleg Pykhalov (2017-12-21 07:48 +0300) wrote:

> Hello Alex,
>
> Alex Kost <alezost <at> gmail.com> writes:
>
>> Oleg Pykhalov (2017-12-20 06:26 +0300) wrote:
[...]
>>> Maybe we just need to fix "geiser"?
>>
>> Sorry, I don't understand what you mean.  What is wrong with geiser and
>> why/how should it be fixed?
>
> Elisp files of Geiser are in different place than others Emacs
> packages.  There is no 'guix.d/geiser-0.9/'.

Oh, now I see what you mean.

> (for-each (match-lambda …) …) in 'setup-environment' will failed.
>
> Either we need to handle this case specific for Geiser or just
> change where it need to store Elisp files in 'geiser' package recipe.

It is not a specific Geiser case: installing *.el files in
"share/emacs/site-lisp/" is a common practice.  Actually, it is the
default place where automake wants to install elisp files (using
AM_PATH_LISPDIR macro), so whenever a package uses gnu-build-system,
most likely it will install elisp files to the site-lisp directory.  For
example, the following packages do this: bbdb, gettext, emms, magit,
emacs-wget, emacs-w3m, emacs-mmm-mode,...

>> Also do other non-"emacs-" packages (magit, emms) have the same problem?
>
> Hm,
>
>     /gnu/store/k9zrrzpdw0mld0lqyackba3kwbw41ipr-emacs-emms-4.3/share/emacs/site-lisp/
>     /gnu/store/zihybmvkccjb310fsxc2sad5j0w5vdi1-magit-2.11.0/share/emacs/stie-lisp/
>
> it seems that it will be easier to handle a case without
> 'guix.d/PACKAGE-VERSION/'.

I also think so, for example, 'emacs-inputs-el-directories' procedure
simply adds "/share/emacs/site-lisp" along with the "guix.d/..." directory.

[...]
>>>> I think we shouldn't rely on the assumption that all emacs inputs have
>>>> "emacs-" prefix
>>>
>>> Then, how to determine that a package is Emacs package?
>>
>> I don't know :-)  'emacs-inputs' is probably the best way.
>
> No :-), it only relies on "emacs-" prefix in store.
> emacs-inputs -> emacs-package? -> (string-prefix? "emacs-" name)

Yeah, I understand this.  I meant this is the best way we have at our
disposal.  I also don't know how to determine emacs packages without
"emacs-" prefix (well, maybe by looking for *.el files inside the
package store dir, not sure if it's suitable though).

>>> emacs inputs contain "emacs-minimal" and "source".
>>> So we actually need to remove "emacs-minimal" instead "emacs".
>>
>> or maybe both? since some packages uses 'emacs' instead of
>> 'emacs-minimal' (emacs-auctex, emacs-exwm, etc.).
>
> Not both, because 'emacs-inputs' removes all inputs without "emacs-"
> prefix, so 'emacs' too.

Oh right, sorry.

So to clarify the current situation, we have 2 problems:

1. 'emacs-package?' defines emacs package simply by checking "emacs-"
prefix, so it doesn't find such packages as magit or geiser.  This
problem does not relate directly to your patch; rather it is the problem
of the current 'emacs-build-system': if some emacs package depends on
'magit' or 'geiser' (currently there are no such packages),
emacs-build-system will not compile *.el files (because it will not find
'magit'/'geiser' needed for compilation).

2. Your patch handles only "/share/emacs/site-lisp/guix.d/<foo>/" but
not "/share/emacs/site-lisp/".

-- 
Alex

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.