bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Maxim Cournoyer
Subject: bug#41732: issue with emacs-lua-mode and emacs-next
Date: Wed, 17 Jun 2020 00:34:23 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]