bug#41732: issue with emacs-lua-mode and emacs-next

[zimoun]

Dear Maxim,

On Sun, 7 Jun 2020 at 06:39, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> Some people have been adding emacs-next-something packages (IIRC); I
> think it's OK for the big, complicated packages that need effort to
> port, but otherwise I wouldn't like seeing this happening for all
> packages.

I agree.  I am not suggesting to duplicate all the packages with
'emacs-next-something'.  There is already enough to do with the
current ones. :-)


> > Well, I am not suggesting to duplicate all the Emacs packages with
> > something like 'emacs-next-<package>' because it is too much.  I am
> > suggesting to provide 'package-with-emacs-next' and then for example
> > in my manifest file I would use this new procedure to generate
> > on-the-fly these next packages; as an expert Emacs mode.
>
> That sounds like a good idea; provide a way for users to rewrite their
> package at the level of their manifest file (which is already possible
> IIUC).

I propose to provide 'package-with-emacs-next' for the people in the
experimental mood. :-)  For example, the manifest looks like:

--8<---------------cut here---------------start------------->8---
(use-modules (guix build-system emacs)
             (gnu packages emacs)
             (gnu packages emacs-xyz))

(packages->manifest
 (cons emacs-next
       (map
        package-with-emacs-next
        (list
         emacs-lua-mode
         emacs-magit))))
--8<---------------cut here---------------end--------------->8---

Then the expert uses it with:

   guix package -m manifest.scm

Well, the attached patch does that.  And maybe, an entry to the
Cookbook could be worth.


> > I do not know if this proposal makes sense.  Probably not. :-)
> > (My regular Emacs is the current version and I very rarely use
> > emacs-next because I started Emacs with 23 therefore 24 was already a
> > so-nice improvement. :-))
>
> It does make sense. For those who would like to see our base Emacs
> package be updated to emacs-next, we need to iron out all the packages
> currently failing to build with it.  It is easy to try, by modifying
> slightly a local Guix checkout:
>
> --8<---------------cut here---------------start------------->8---
> 1 file changed, 1 insertion(+), 1 deletion(-)
> guix/build-system/emacs.scm | 2 +-
>
> modified   guix/build-system/emacs.scm
> @@ -52,7 +52,7 @@
>    "Return the default Emacs package."
>    ;; Lazily resolve the binding to avoid a circular dependency.
>    (let ((emacs-mod (resolve-interface '(gnu packages emacs))))
> -    (module-ref emacs-mod 'emacs-minimal)))
> +    (module-ref emacs-mod 'emacs-next)))
>
>  (define* (lower name
>                  #:key source inputs native-inputs outputs system target
>
> --8<---------------cut here---------------end--------------->8---

What I propose simplifies because it avoids to recompile all Guix and
to use ./pre-inst-env.
Well, I do not know.  It is an half-cooked proposal. :-)

And the added 'package-with-explicit-emacs' procedure allows to use
any Emacs as the VM, so for example, it could be cool to see what
happens with REmacs (which is not packaged but that's another story
:-)).
Or for example with Gccemacs.


All the best,
simon

ps:
Note that 'package-with-explicite-emacs' and
'package-with-explicit-python' should be refactored, another story.
:-)

0001-DRAFT-build-system-emacs-Add-new-package-with-emacs-.patch
Description: Text Data