Allow for easily rewriting Emacs packages to use emacs-next

  • Open
  • quality assurance status badge
Details
4 participants
  • Liliana Marie Prikler
  • Maxim Cournoyer
  • Mekeor Melire
  • Simon Tournier
Owner
unassigned
Submitted by
Mekeor Melire
Severity
normal
M
M
Mekeor Melire wrote on 6 Jun 2023 09:11
Emacs Packages should have an output built with emacs-next(-minimal)
(address . bug-guix@gnu.org)
87pm696o2j.fsf@posteo.de
Hello dear Guix community,

if I understand correctly, all Emacs-packages that are packaged in
Guix proper, are built with Emacs version 28 (or more precisely,
emacs-minimal@28, emacs@28, emacs-no-x@28, emacs-no-x-toolkit@28
or emacs-wide-int@28 (except emacs-jsdoc which is and needs to be
built with emacs-next@29)). (You may grep the Guix repository for
":emacs" to find out by yourself.)

When using these Emacs-packages with emacs-next* (i.e. version 29
or 30), this can lead to misbehavior because Emacs will still
prefer the compiled .elc or .eln files which may depend on version
28 specifics.

My concrete experience is that, when using emacs-next-tree-sitter
and emacs-consult packages, evaluating (require 'consult-register)
fails because it has emacs-major-version-specific code:
(A workaround is to instead evaluate (load
"consult-register.el").)

I propose:

1. Introduce a package emacs-next-minimal.

2. For all Emacs-packages, create one output corresponding to each
Emacs major-version packaged in Guix proper. For example, the
output "emacs-next" would be built with emacs-next-minimal.

What do you think? I'd guess this should be hard to implement,
right?

Kindly
Mekeor
L
L
Liliana Marie Prikler wrote on 6 Jun 2023 18:07
86d39d60b16eeeaed7d149773864f322ab109a78.camel@gmail.com
Hi Mekeor,

Am Dienstag, dem 06.06.2023 um 07:11 +0000 schrieb Mekeor Melire:
Toggle quote (8 lines)
> Hello dear Guix community,
>
> if I understand correctly, all Emacs-packages that are packaged in
> Guix proper, are built with Emacs version 28 (or more precisely,
> emacs-minimal@28, emacs@28, emacs-no-x@28, emacs-no-x-toolkit@28
> or emacs-wide-int@28 (except emacs-jsdoc which is and needs to be
> built with emacs-next@29)). (You may grep the Guix repository for
> ":emacs" to find out by yourself.)
Emacs packages other than emacs-minimal should be the exception rather
than the norm.

Toggle quote (4 lines)
> When using these Emacs-packages with emacs-next* (i.e. version 29
> or 30), this can lead to misbehavior because Emacs will still
> prefer the compiled .elc or .eln files which may depend on version
> 28 specifics.
It should not prefer the .eln files, which get put into a unique
directory per Emacs – yes, that ought to include different versions of
the emacs package itself built with inputs that had their hashes
changed. In any case, the version number itself (28 vs 29) is enough
to turn .eln loading away.

For .elc, the behaviour is indeed as you described, but that's rather
due to the fact that bytecode ought to be forward-compatible. The
packages you describe below thus invoke (IIUC) undefined behaviour.

Toggle quote (18 lines)
> My concrete experience is that, when using emacs-next-tree-sitter
> and emacs-consult packages, evaluating (require 'consult-register)
> fails because it has emacs-major-version-specific code:
> https://github.com/minad/consult/blob/3c0f87ebd20b25f03568fb9ef8fd36b5a2a6eb84/consult-register.el#L82
>  
> (A workaround is to instead evaluate (load
> "consult-register.el").)
>
> I propose:
>
> 1. Introduce a package emacs-next-minimal.
>
> 2. For all Emacs-packages, create one output corresponding to each
> Emacs major-version packaged in Guix proper. For example, the
> output "emacs-next" would be built with emacs-next-minimal.
>
> What do you think? I'd guess this should be hard to implement,
> right?
This would unnecessarily complicate things over at emacs-build-system.
Now, emacs-next-minimal itself might be worthwhile (I don't see a
strong reason as to why, though), but since native compilation was
introduced to Guix, the recommendation was to compile packages ahead of
time rather than using the built-in JIT. To do so, add 
--with-input=emacs-minimal=emacs-next
or use a semantically equivalent options->transformation.

As for a long-term solution to the problem, I do think we could make
the situation easier by providing dedicated alternatives (e.g. "emacs-
next-consult") or using parameterized packages (which is a larger TODO
than emacs-build-system, however). As a member of the emacs-team, I do
have to sadly report that we have yet to start the most serious work
for making emacs-next the new emacs.

Cheers
M
M
Maxim Cournoyer wrote on 4 Oct 2023 04:20
Re: bug#63920: Emacs Packages should have an output built with emacs-next(-minimal)
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87h6n75dro.fsf@gmail.com
retitle 63920 Allow for easily rewriting Emacs packages to use emacs-next
quit

Hello Mekeor,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

Toggle quote (21 lines)
>> (A workaround is to instead evaluate (load
>> "consult-register.el").)
>>
>> I propose:
>>
>> 1. Introduce a package emacs-next-minimal.
>>
>> 2. For all Emacs-packages, create one output corresponding to each
>> Emacs major-version packaged in Guix proper. For example, the
>> output "emacs-next" would be built with emacs-next-minimal.
>>
>> What do you think? I'd guess this should be hard to implement,
>> right?
> This would unnecessarily complicate things over at emacs-build-system.
> Now, emacs-next-minimal itself might be worthwhile (I don't see a
> strong reason as to why, though), but since native compilation was
> introduced to Guix, the recommendation was to compile packages ahead of
> time rather than using the built-in JIT. To do so, add 
> --with-input=emacs-minimal=emacs-next
> or use a semantically equivalent options->transformation.

I agree adding multiple outputs would make things complicated and messy,
and should thus not be the approach pursued. I think this should be
feasible via package rewriting procedures, like we had in the past for
Python 2 with package-for-python2 or similar, which users can apply to
their Emacs package collection in a manifest file.

A version of it for Emacs has been shared to guix-devel in the past, it
could be reworked, it had some problems still.

I'm renaming the issue to something that should serve as a reminder to
someone to implement this.

--
Thanks,
Maxim
S
S
Simon Tournier wrote on 4 Oct 2023 11:14
Re: bug#63920: Allow for easily rewriting Emacs packages to use emacs-next
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
877co23g2o.fsf_-_@gmail.com
Hi,

On Tue, 03 Oct 2023 at 22:20, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Toggle quote (6 lines)
> I agree adding multiple outputs would make things complicated and messy,
> and should thus not be the approach pursued. I think this should be
> feasible via package rewriting procedures, like we had in the past for
> Python 2 with package-for-python2 or similar, which users can apply to
> their Emacs package collection in a manifest file.

For the record, it remembers these related or similar discussions:


Cheers,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 63920@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 63920
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch