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