bug#63920: Emacs Packages should have an output built with emacs-next(-minimal)

[Liliana Marie Prikler]

Hi Mekeor,

Am Dienstag, dem 06.06.2023 um 07:11 +0000 schrieb Mekeor Melire:
> 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.  

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

> 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