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

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

[Fredrik Salomonsson]

[-- Attachment #1.1: Type: text/plain, Size: 794 bytes --]

Hi,

When I launch emacs (emacs-next) with the emacs-lua-mode package, I'm
getting this error
"Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’"

It works when I let emacs download it from melpa. I tried updating
emacs-lua-mode to 20200508, which is the same version as on melpa.

Still the same issue.

Could this be an issue that it's using emacs-minimal-26.3 to byte compile
the files? Where I'm using emacs-next aka emasc-27.0. Judging by this issue
[1] the rx package has gone through some changes in 27.0.

My emacs config is here: https://github.com/plattfot/dotemacs/tree/emacs27
I've attached the backtrace and the patch for the latest emacs-lua-mode.

Thanks

[1] https://github.com/immerrr/lua-mode/issues/153
-- 
s/Fred[re]+i[ck]+/Fredrik/g

[-- Attachment #1.2: Type: text/html, Size: 1284 bytes --]

[-- Attachment #2: emacs-lua-mode.backtrace --]
[-- Type: application/octet-stream, Size: 2354 bytes --]

Debugger entered--Lisp error: (error "Unknown rx form ‘symbol’")
  signal(error ("Unknown rx form ‘symbol’"))
  error("Unknown rx form `%s'" symbol)
  rx--translate-form((symbol "local"))
  rx--translate((symbol "local"))
  mapcar(rx--translate ((symbol "local") ws+))
  rx--translate-seq(((symbol "local") ws+))
  rx--translate-rep("?" t ((symbol "local") ws+))
  rx--translate-form((32 (symbol "local") ws+))
  rx--translate((32 (symbol "local") ws+))
  mapcar(rx--translate (bol (32 (symbol "local") ws+) lua-funcheader))
  rx--translate-seq((bol (32 (symbol "local") ws+) lua-funcheader))
  rx--translate-form((: bol (32 (symbol "local") ws+) lua-funcheader))
  rx--translate((: bol (32 (symbol "local") ws+) lua-funcheader))
  rx-to-string((: bol (32 (symbol "local") ws+) lua-funcheader) nil)
  lua-rx-to-string((: bol (32 (symbol "local") ws+) lua-funcheader))
  (defvar lua--beginning-of-defun-re (lua-rx-to-string '(: bol (32 (symbol "local") ws+) lua-funcheader)) ("/home/plattfot/.guix-profile/share/emacs/site-lisp..." . 43496))
  require(lua-mode nil t)
  (not (require 'lua-mode nil t))
  (if (not (require 'lua-mode nil t)) (display-warning 'use-package (format "Cannot load %s" 'lua-mode) :error))
  (condition-case err (if (not (require 'lua-mode nil t)) (display-warning 'use-package (format "Cannot load %s" 'lua-mode) :error)) ((debug error) (funcall use-package--warning28 :catch err)))
  eval-buffer(#<buffer  *load*-564058> nil "/home/plattfot/.config/emacs/init.d/configuration...." nil t)  ; Reading at buffer position 13216
  load-with-code-conversion("/home/plattfot/.config/emacs/init.d/configuration...." "/home/plattfot/.config/emacs/init.d/configuration...." nil nil)
  load("/home/plattfot/.config/emacs/init.d/configuration...." nil nil t)
  load-file("~/.config/emacs/init.d/configuration.el")
  org-babel-load-file("~/.config/emacs/init.d/configuration.org")
  eval-buffer(#<buffer  *load*> nil "/home/plattfot/.config/emacs/init.el" nil t)  ; Reading at buffer position 81
  load-with-code-conversion("/home/plattfot/.config/emacs/init.el" "/home/plattfot/.config/emacs/init.el" t t)
  load("/home/plattfot/.config/emacs/init" noerror nomessage)
  startup--load-user-init-file(#f(compiled-function () #<bytecode 0x97d559>) #f(compiled-function () #<bytecode 0x984959>) t)
  command-line()
  normal-top-level()

[-- Attachment #3: 0001-gnu-emacs-lua-mode-Update-to-20200508-0.35b6e4c.patch --]
[-- Type: text/x-patch, Size: 1921 bytes --]

From 1ef949ea0a9bdec2bdf42c0314b8e8e01acff72d Mon Sep 17 00:00:00 2001
From: Fredrik Salomonsson <plattfot@gmail.com>
Date: Fri, 5 Jun 2020 19:39:37 -0700
Subject: [PATCH] gnu: emacs-lua-mode: Update to 20200508-0.35b6e4c.

* gnu/packages/emacs-xyz.scm (emacs-lua-mode): Update to 20200508-0.35b6e4c.
---
 gnu/packages/emacs-xyz.scm | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 6110374281..e2d91918e8 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -8292,11 +8292,11 @@ using package inferred style.")
       (license license:gpl3+))))
 
 (define-public emacs-lua-mode
-  (let ((commit "1f596a93b3f1caadd7bba01030f8c179b029600b")
-        (revision "1"))
+  (let ((commit "35b6e4c20b8b4eaf783ccc8e613d0dd06dbd165c")
+        (revision "0"))
     (package
       (name "emacs-lua-mode")
-      (version (git-version "20191204" revision commit))
+      (version (git-version "20200508" revision commit))
       (home-page "https://github.com/immerrr/lua-mode/")
       (source (origin
                 (method git-fetch)
@@ -8306,14 +8306,14 @@ using package inferred style.")
                 (file-name (git-file-name name version))
                 (sha256
                  (base32
-                  "0i4adlaik3qjx1wkb7rwk2clvj7ci2g8pm0siyb3yk90r6z5mspi"))))
+                  "1hai6rqjm5py0bp57nhggmj9qigwdj3a46ngacpnjc1qmy9kkgfk"))))
       (build-system emacs-build-system)
       (arguments
        `(#:tests? #t
-	 #:test-command '("buttercup" "-l" "lua-mode.el")))
+         #:test-command '("buttercup" "-l" "lua-mode.el")))
       (native-inputs
        `(("emacs-buttercup" ,emacs-buttercup)
-	 ("lua" ,lua)))
+         ("lua" ,lua)))
       (synopsis "Major mode for lua")
       (description
        "This Emacs package provides a mode for @uref{https://www.lua.org/,
-- 
2.26.2

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

[Fredrik Salomonsson via web]

Forgot to say which guix version I'm using:

guix (GNU Guix) ba6d3612550f5d978c4b5b1df122444f8fb29377

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

[Nicolas Goaziou]

Hello,

Fredrik Salomonsson <plattfot@gmail.com> writes:

> When I launch emacs (emacs-next) with the emacs-lua-mode package, I'm
> getting this error
> "Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’"
>
> It works when I let emacs download it from melpa. I tried updating
> emacs-lua-mode to 20200508, which is the same version as on melpa.
>
> Still the same issue.
>
> Could this be an issue that it's using emacs-minimal-26.3 to byte compile
> the files? Where I'm using emacs-next aka emasc-27.0. Judging by this issue
> [1] the rx package has gone through some changes in 27.0.

This seems to be reported upstream as 

             https://github.com/immerrr/lua-mode/issues/155

You may be right. Files byte-compiled with Emacs 26 may not be
compatible with Emacs 27.

I don't know what can be done on Guix's side, tho.

> I've attached the backtrace and the patch for the latest
> emacs-lua-mode.

Could you send another bug report for the package update?

Regards,

-- 
Nicolas Goaziou

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

[zimoun]

Dear Nicolas,

On Sat, 6 Jun 2020 at 10:11, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> You may be right. Files byte-compiled with Emacs 26 may not be
> compatible with Emacs 27.
>
> I don't know what can be done on Guix's side, tho.

Somehow, one needs to change the Emacs version used by the Emacs
toolchain to bytecompile, right?
I do not know if it makes sense, but we could add something like
'package-with-emacs-next' similar to 'package-with-python2' or
'package-with-ocam4.07'.
WDYT?


All the best,
simon

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

[Nicolas Goaziou]

Hello,

zimoun <zimon.toutoune@gmail.com> writes:

> Somehow, one needs to change the Emacs version used by the Emacs
> toolchain to bytecompile, right?
> I do not know if it makes sense, but we could add something like
> 'package-with-emacs-next' similar to 'package-with-python2' or
> 'package-with-ocam4.07'.
> WDYT?

This sounds like serious overhead for a single package. Maybe we could
try to prevent byte-compilation for the package and see what happens?

Regards,

-- 
Nicolas Goaziou

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

[zimoun]

Dear Nicolas,

On Sat, 6 Jun 2020 at 16:13, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:

> > Somehow, one needs to change the Emacs version used by the Emacs
> > toolchain to bytecompile, right?
> > I do not know if it makes sense, but we could add something like
> > 'package-with-emacs-next' similar to 'package-with-python2' or
> > 'package-with-ocam4.07'.
> > WDYT?
>
> This sounds like serious overhead for a single package. Maybe we could
> try to prevent byte-compilation for the package and see what happens?

Maybe I miss the issue.  From my understanding, all the Emacs packages
are byte-compiled with the current Emacs.  Therefore, "guix install
emacs-next emacs-foo" and then "M-x foo" works by luck -- well because
the Emacs VM is stable. :-)
And I do not know how to rebuild all my Emacs packages using
'emacs-next' instead of the current Emacs.  Maybe I miss something.

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.

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. :-))

All the best,
simon

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

[Maxim Cournoyer]

Hello,

zimoun <zimon.toutoune@gmail.com> writes:

> Dear Nicolas,
>
> On Sat, 6 Jun 2020 at 16:13, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>
>> > Somehow, one needs to change the Emacs version used by the Emacs
>> > toolchain to bytecompile, right?
>> > I do not know if it makes sense, but we could add something like
>> > 'package-with-emacs-next' similar to 'package-with-python2' or
>> > 'package-with-ocam4.07'.
>> > WDYT?
>>
>> This sounds like serious overhead for a single package. Maybe we could
>> try to prevent byte-compilation for the package and see what happens?
>
> Maybe I miss the issue.  From my understanding, all the Emacs packages
> are byte-compiled with the current Emacs.  Therefore, "guix install
> emacs-next emacs-foo" and then "M-x foo" works by luck -- well because
> the Emacs VM is stable. :-)

That's a good description of the situation.  There's no warranty that
emacs-something works with emacs-next unless it was packaged to be
compiled specifically with emacs-next instead of the default emacs package
(currently 26.3).

> And I do not know how to rebuild all my Emacs packages using
> 'emacs-next' instead of the current Emacs.  Maybe I miss something.

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.

> 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 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---

Maxim

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

[zimoun]

[-- Attachment #1: Type: text/plain, Size: 3320 bytes --]

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.
:-)

[-- Attachment #2: 0001-DRAFT-build-system-emacs-Add-new-package-with-emacs-.patch --]
[-- Type: text/x-patch, Size: 4162 bytes --]

From 4038b0c53d5066facceea3c159a6510fa8a625d6 Mon Sep 17 00:00:00 2001
From: zimoun <zimon.toutoune@gmail.com>
Date: Sun, 7 Jun 2020 11:07:08 +0200
Subject: [PATCH] DRAFT: build-system: emacs: Add new
 'package-with-emacs-next'procedure.

* guix/build-system/emacs.scm: Add 'default-emacs-next'.
* guix/build-system/emacs.scm: Add 'package-with-emacs-next'.
---
 guix/build-system/emacs.scm | 66 +++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/guix/build-system/emacs.scm b/guix/build-system/emacs.scm
index ef6d1b3397..8732678dca 100644
--- a/guix/build-system/emacs.scm
+++ b/guix/build-system/emacs.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015 Federico Beffa <beffa@fbengineering.ch>
+;;; Copyright © 2020 Simon Tournier <zimon.toutoune@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -29,6 +30,7 @@
   #:use-module (ice-9 match)
   #:use-module (srfi srfi-26)
   #:export (%emacs-build-system-modules
+            package-with-emacs-next
             emacs-build
             emacs-build-system)
   #:re-export (%default-include         ;for convenience
@@ -54,6 +56,70 @@
   (let ((emacs-mod (resolve-interface '(gnu packages emacs))))
     (module-ref emacs-mod 'emacs-minimal)))
 
+(define (default-emacs-next)
+  "Return the default Emacs-next package."
+  (let ((emacs-mod (resolve-interface '(gnu packages emacs))))
+    (module-ref emacs-mod 'emacs-next)))
+
+(define* (package-with-explicit-emacs emacs old-prefix new-prefix
+                                       #:key variant-property)
+  "Return a procedure of one argument, P.  The procedure creates a package with
+the same fields as P, which is assumed to use EMACS-BUILD-SYSTEM, such that
+it is compiled with EMACS instead.  The inputs are changed recursively
+accordingly.  If the name of P starts with OLD-PREFIX, this is replaced by
+NEW-PREFIX; otherwise, NEW-PREFIX is prepended to the name.
+
+When VARIANT-PROPERTY is present, it is used as a key to search for
+pre-defined variants of this transformation recorded in the 'properties' field
+of packages.  The property value must be the promise of a package.  This is a
+convenient way for package writers to force the transformation to use
+pre-defined variants."
+  (define package-variant
+    (if variant-property
+        (lambda (package)
+          (assq-ref (package-properties package)
+                    variant-property))
+        (const #f)))
+
+  (define (transform p)
+    (cond
+     ;; If VARIANT-PROPERTY is present, use that.
+     ((package-variant p)
+      => force)
+
+     ;; Otherwise build the new package object graph.
+     ((eq? (package-build-system p) emacs-build-system)
+      (package
+        (inherit p)
+        (location (package-location p))
+        (name (let ((name (package-name p)))
+                (string-append new-prefix
+                               (if (string-prefix? old-prefix name)
+                                   (substring name
+                                              (string-length old-prefix))
+                                   name))))
+        (arguments
+         (let ((emacs (if (promise? emacs)
+                           (force emacs)
+                           emacs)))
+           (ensure-keyword-arguments (package-arguments p)
+                                     `(#:emacs ,emacs))))))
+     (else p)))
+
+  (define (cut? p)
+    (or (not (eq? (package-build-system p) emacs-build-system))
+        (package-variant p)))
+
+  (package-mapping transform cut?))
+
+(define package-with-emacs-next
+  ;; Note: delay call to 'default-emacs-next' until after the 'arguments' field
+  ;; of packages is accessed to avoid a circular dependency when evaluating
+  ;; the top-level of (gnu packages emacs).
+  (package-with-explicit-emacs (delay (default-emacs-next))
+                                "emacs-" "emacs-next-"
+                                #:variant-property 'emacs-next-variant))
+
 (define* (lower name
                 #:key source inputs native-inputs outputs system target
                 (emacs (default-emacs))
-- 
2.26.2

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

[Maxim Cournoyer]

Hello Simon!

Sorry for my delayed answer.

zimoun <zimon.toutoune@gmail.com> writes:

> 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:
>
> (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))))
>
> 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.

That's really nice!  Thank you for providing it.  I've tried it in my
manifest, by stitching a couple manifests objects together
`concatenate-manifests' like so:

--8<---------------cut here---------------start------------->8---
(concatenate-manifests
 (list
 ;;; Emacs packages.
  (packages->manifest
   (cons emacs-next
         (map package-with-emacs-next
              (map specification->package
                   '("emacs-auctex"
                     "emacs-bash-completion"
                     [...]
                     "emacs-yasnippet"
                     "emacs-yasnippet-snippets")))))

  ;; Other software.
  (specifications->manifest
   '("adb"
     [...]   
     "arc-icon-theme"
     "arc-theme"
     ...))))
--8<---------------cut here---------------end--------------->8---

And after a couple fixes on master, I was able to build my profile with
my Emacs packages collection built against Emacs 27!  I'm now having
some issues due to the apparent renaming of the generated autoload
files.  I haven't had the time to look for a fix yet.  It breaks at
least Helm (and probably others), as it cannot find its own autoload
file.

next-helm-autoloads.el ->
/gnu/store/fnwalhxi94fhr8h2dfg602zd9plarwx0-emacs-next-helm-3.6.2/share/emacs/site-lisp/next-helm-autoloads.el

(instead of helm-autoloads.el)

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

I wholly agree!  It seems these have much in common.  Perhaps (guix
packages) could be a new home for the factored out bits.

To be continued!

Maxim

bug#41732: New ’package-with-emacs-next’ procedure

[zimoun]

Dear Maxim,

On Wed, 17 Jun 2020 at 00:34, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:

> Sorry for my delayed answer.

Sorry, I have missed your answer.


>> I propose to provide 'package-with-emacs-next' for the people in the
>> experimental mood. :-)  For example, the manifest looks like:
>>
>> (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))))
>>
>> 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.
>
> That's really nice!  Thank you for providing it.  I've tried it in my
> manifest, by stitching a couple manifests objects together
> `concatenate-manifests' like so:
>
> (concatenate-manifests
>  (list
>  ;;; Emacs packages.
>   (packages->manifest
>    (cons emacs-next
>          (map package-with-emacs-next
>               (map specification->package
>                    '("emacs-auctex"
>                      "emacs-bash-completion"
>                      [...]
>                      "emacs-yasnippet"
>                      "emacs-yasnippet-snippets")))))
>
>   ;; Other software.
>   (specifications->manifest
>    '("adb"
>      [...]
>      "arc-icon-theme"
>      "arc-theme"
>      ...))))
>
> And after a couple fixes on master, I was able to build my profile with
> my Emacs packages collection built against Emacs 27!  I'm now having
> some issues due to the apparent renaming of the generated autoload
> files.  I haven't had the time to look for a fix yet.  It breaks at
> least Helm (and probably others), as it cannot find its own autoload
> file.
>
> next-helm-autoloads.el ->
> /gnu/store/fnwalhxi94fhr8h2dfg602zd9plarwx0-emacs-next-helm-3.6.2/share/emacs/site-lisp/next-helm-autoloads.el
>
> (instead of helm-autoloads.el)

What do you think to add this ’package-with-emacs-next’?
It should help when upgrading Emacs: detect which packages break, report
upstream or fix, etc.  Helm is a good example.

Couple of days before emacs-next becomes the new emacs, an announcement
of the coming soon switch on guix-devel and a call for testing and
report issues.

If it appears to you a good idea, I can rebase the patch and resubmit
it, and add an example to the Cooking book.


>> Note that 'package-with-explicite-emacs' and
>> 'package-with-explicit-python' should be refactored, another story.
>> :-)
>
> I wholly agree!  It seems these have much in common.  Perhaps (guix
> packages) could be a new home for the factored out bits.

The story is long. :-)

There is ’package-with-explicit-python’ and also
’package-with-explicit-ocaml’, I would like to have
’package-with-explicit-c-compiler’ too to rebuild C packages with any
version of GCC or even Clang.  One way to achieve is “package parameter”
but the consensus on the topic has not been reached.  Therefore
’package-with-explicit-<name-it>’ seems a working short term workaround
waiting something more “elegant“.  But yeah, maybe the 3
’package-with-explicit-{python,ocaml,emacs}’ could be refactored; I do
not know.


All the best,
simon

bug#41732: New ’package-with-emacs-next’ procedure

[zimoun]

Dear,

On Wed, 16 Sep 2020 at 16:51, zimoun <zimon.toutoune@gmail.com> wrote:

>>> I propose to provide 'package-with-emacs-next' for the people in the
>>> experimental mood. :-)  For example, the manifest looks like:
>>>
>>> (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))))
>>>
>>> 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 withdraw the patch proposal since the patch set #43578 [1] fulfills
the request.  Now, for recompiling all the Emacs packages of one
manifest.scm file with the emacs-next package (changing the Emacs VM),
it is as easy as:

--8<---------------cut here---------------start------------->8---
guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
--8<---------------cut here---------------end--------------->8---

Before closing, what do you think adding something in the manual or the
cookbook will be worth?  It could be useful when switching the Emacs
version –– for example the last 26 to 27.

[1] <http://issues.guix.gnu.org/issue/43578>

All the best,
simon

bug#41732: New ’package-with-emacs-next’ procedure

[Nicolas Goaziou]

Hello,

zimoun <zimon.toutoune@gmail.com> writes:

> I withdraw the patch proposal since the patch set #43578 [1] fulfills
> the request.  Now, for recompiling all the Emacs packages of one
> manifest.scm file with the emacs-next package (changing the Emacs VM),
> it is as easy as:
>
> --8<---------------cut here---------------start------------->8---
> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
> --8<---------------cut here---------------end--------------->8---

Some Emacs packages rely on emacs package, not on emacs-minimal. IIUC,
the command above could give surprising results in this case. Maybe the
documentation/cookbook could warn about this caveat.

Regards,
-- 
Nicolas Goaziou

bug#41732: New ’package-with-emacs-next’ procedure

[Maxim Cournoyer]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> zimoun <zimon.toutoune@gmail.com> writes:
>
>> I withdraw the patch proposal since the patch set #43578 [1] fulfills
>> the request.  Now, for recompiling all the Emacs packages of one
>> manifest.scm file with the emacs-next package (changing the Emacs VM),
>> it is as easy as:
>>
>> --8<---------------cut here---------------start------------->8---
>> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
>> --8<---------------cut here---------------end--------------->8---
>
> Some Emacs packages rely on emacs package, not on emacs-minimal. IIUC,
> the command above could give surprising results in this case. Maybe the
> documentation/cookbook could warn about this caveat.

Perhaps then,

--8<---------------cut here---------------start------------->8---
guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
     --with-input=emacs=emacs-next
--8<---------------cut here---------------end--------------->8---

I haven't tried myself.

Maxim

bug#41732: New ’package-with-emacs-next’ procedure

[Nicolas Goaziou]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Perhaps then,
>
> --8<---------------cut here---------------start------------->8---
> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
>      --with-input=emacs=emacs-next
> --8<---------------cut here---------------end--------------->8---

Possibly. And then Magit uses emacs-no-x as an input, so we may need to
also add --with-input=emacs-no-x=emacs-next to the command.

I'm just pointing out that the process is not as straightforward as it
might seem. So, it doesn't sound right to simply suggest

  guix build -m manifest.scm --with-input=emacs-minimal=emacs-next

in the manual/cookbook without caution.

Or maybe `package-with-emacs-next' could be more high-level, and handle
all of these cases. I don't know.

Regards,
-- 
Nicolas Goaziou

bug#41732: New ’package-with-emacs-next’ procedure

[Maxim Cournoyer]

Hello,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Possibly. And then Magit uses emacs-no-x as an input, so we may need to
> also add --with-input=emacs-no-x=emacs-next to the command.
>
> I'm just pointing out that the process is not as straightforward as it
> might seem. So, it doesn't sound right to simply suggest
>
>   guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
>
> in the manual/cookbook without caution.
>
> Or maybe `package-with-emacs-next' could be more high-level, and handle
> all of these cases. I don't know.

Yeah, that would probably me more convenient/robust to use, if it was
covering for all the weird cases one might forget.  I'd still be in
favor of having such a helper procedure.

Maxim

bug#41732: New ’package-with-emacs-next’ procedure

[zimoun]

Hi,

Thank you for your insights.

On Sun, 27 Sep 2020 at 15:12, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> > --8<---------------cut here---------------start------------->8---
> > guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
> >      --with-input=emacs=emacs-next
> > --8<---------------cut here---------------end--------------->8---
>
> Possibly. And then Magit uses emacs-no-x as an input, so we may need to
> also add --with-input=emacs-no-x=emacs-next to the command.

[...]

> Or maybe `package-with-emacs-next' could be more high-level, and handle
> all of these cases. I don't know.

I am not familiar with the Emacs build system.  Do the packages need
different flavors of the Emacs VM to be byte-compiled?
For example, the package emacs-magit drags emacs-no-x because of
emacs-libgit, why is emacs-minimal not enough here?

Well, the emacs-build-system depends (implicitly) on emacs-minimal,
only.  And the initial patch `package-with-emacs-next' was changing
this, only.  However, the package emacs-libgit is cmake-build-system
and the package emacs-no-x is an explicit dependency; which is another
story. :-)

Therefore, the `package-with-emacs-next' could replace the Emacs used
by the build system (emacs-minimal -> emacs-next-minimal) and also
traverse all the graph of dependencies and replace all the Emacs
variants (emacs-{minimal,xwidgets,no-x,no-x-toolkit,wide-int}) in
gnu/packages/emacs.scm by the package emacs-next.  I am not sure it
will work.  Maybe the Emacs variants should also be rebuilt inheriting
from emacs-next instead of emacs.  WDYT?

Does it make sense?


All the best,
simon