unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / Atom feed
* bug#41732: issue with emacs-lua-mode and emacs-next
@ 2020-06-06  3:14 Fredrik Salomonsson
  2020-06-06  3:17 ` Fredrik Salomonsson via web
  2020-06-06  8:10 ` Nicolas Goaziou
  0 siblings, 2 replies; 10+ messages in thread
From: Fredrik Salomonsson @ 2020-06-06  3:14 UTC (permalink / raw)
  To: 41732


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

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: issue with emacs-lua-mode and emacs-next
  2020-06-06  3:14 bug#41732: issue with emacs-lua-mode and emacs-next Fredrik Salomonsson
@ 2020-06-06  3:17 ` Fredrik Salomonsson via web
  2020-06-06  8:10 ` Nicolas Goaziou
  1 sibling, 0 replies; 10+ messages in thread
From: Fredrik Salomonsson via web @ 2020-06-06  3:17 UTC (permalink / raw)
  To: 41732

Forgot to say which guix version I'm using:

guix (GNU Guix) ba6d3612550f5d978c4b5b1df122444f8fb29377






^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: issue with emacs-lua-mode and emacs-next
  2020-06-06  3:14 bug#41732: issue with emacs-lua-mode and emacs-next Fredrik Salomonsson
  2020-06-06  3:17 ` Fredrik Salomonsson via web
@ 2020-06-06  8:10 ` Nicolas Goaziou
  2020-06-06 10:26   ` zimoun
  1 sibling, 1 reply; 10+ messages in thread
From: Nicolas Goaziou @ 2020-06-06  8:10 UTC (permalink / raw)
  To: Fredrik Salomonsson; +Cc: 41732

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: issue with emacs-lua-mode and emacs-next
  2020-06-06  8:10 ` Nicolas Goaziou
@ 2020-06-06 10:26   ` zimoun
  2020-06-06 14:13     ` Nicolas Goaziou
  0 siblings, 1 reply; 10+ messages in thread
From: zimoun @ 2020-06-06 10:26 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: 41732, Fredrik Salomonsson

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: issue with emacs-lua-mode and emacs-next
  2020-06-06 10:26   ` zimoun
@ 2020-06-06 14:13     ` Nicolas Goaziou
  2020-06-06 15:30       ` zimoun
  0 siblings, 1 reply; 10+ messages in thread
From: Nicolas Goaziou @ 2020-06-06 14:13 UTC (permalink / raw)
  To: zimoun; +Cc: 41732, Fredrik Salomonsson

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: issue with emacs-lua-mode and emacs-next
  2020-06-06 14:13     ` Nicolas Goaziou
@ 2020-06-06 15:30       ` zimoun
  2020-06-07  4:39         ` Maxim Cournoyer
  0 siblings, 1 reply; 10+ messages in thread
From: zimoun @ 2020-06-06 15:30 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: 41732, Fredrik Salomonsson

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: issue with emacs-lua-mode and emacs-next
  2020-06-06 15:30       ` zimoun
@ 2020-06-07  4:39         ` Maxim Cournoyer
  2020-06-07  9:31           ` zimoun
  0 siblings, 1 reply; 10+ messages in thread
From: Maxim Cournoyer @ 2020-06-07  4:39 UTC (permalink / raw)
  To: zimoun; +Cc: 41732, Fredrik Salomonsson, Nicolas Goaziou

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: issue with emacs-lua-mode and emacs-next
  2020-06-07  4:39         ` Maxim Cournoyer
@ 2020-06-07  9:31           ` zimoun
  2020-06-17  4:34             ` Maxim Cournoyer
  0 siblings, 1 reply; 10+ messages in thread
From: zimoun @ 2020-06-07  9:31 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 41732, Fredrik Salomonsson, Nicolas Goaziou

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: issue with emacs-lua-mode and emacs-next
  2020-06-07  9:31           ` zimoun
@ 2020-06-17  4:34             ` Maxim Cournoyer
  2020-09-16 14:51               ` bug#41732: New ’package-with-emacs-next’ procedure zimoun
  0 siblings, 1 reply; 10+ messages in thread
From: Maxim Cournoyer @ 2020-06-17  4:34 UTC (permalink / raw)
  To: zimoun; +Cc: 41732, Fredrik Salomonsson, Nicolas Goaziou

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#41732: New ’package-with-emacs-next’ procedure
  2020-06-17  4:34             ` Maxim Cournoyer
@ 2020-09-16 14:51               ` zimoun
  0 siblings, 0 replies; 10+ messages in thread
From: zimoun @ 2020-09-16 14:51 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 41732, Fredrik Salomonsson, Nicolas Goaziou

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-09-16 14:52 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-06  3:14 bug#41732: issue with emacs-lua-mode and emacs-next Fredrik Salomonsson
2020-06-06  3:17 ` Fredrik Salomonsson via web
2020-06-06  8:10 ` Nicolas Goaziou
2020-06-06 10:26   ` zimoun
2020-06-06 14:13     ` Nicolas Goaziou
2020-06-06 15:30       ` zimoun
2020-06-07  4:39         ` Maxim Cournoyer
2020-06-07  9:31           ` zimoun
2020-06-17  4:34             ` Maxim Cournoyer
2020-09-16 14:51               ` bug#41732: New ’package-with-emacs-next’ procedure zimoun

unofficial mirror of bug-guix@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-bugs/0 guix-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-bugs guix-bugs/ https://yhetil.org/guix-bugs \
		bug-guix@gnu.org
	public-inbox-index guix-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.bugs
	nntp://news.gmane.io/gmane.comp.gnu.guix.bugs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git