GNU bug report logs - #63920
Allow for easily rewriting Emacs packages to use emacs-next

Previous Next

Full log

View this message in rfc822 format

From: Mekeor Melire <mekeor <at> posteo.de>
To: 63920 <at> debbugs.gnu.org
Subject: bug#63920: Emacs Packages should have an output built with emacs-next(-minimal)
Date: Tue, 06 Jun 2023 07:11:28 +0000

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 <at> 28, emacs <at> 28, emacs-no-x <at> 28, emacs-no-x-toolkit <at> 28 
or emacs-wide-int <at> 28 (except emacs-jsdoc which is and needs to be 
built with emacs-next <at> 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: 
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?

Kindly
Mekeor

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.