From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Morgan Smith <morgan.j.smith@outlook.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix@gmail.com>,
70632@debbugs.gnu.org, Andrew Tropin <andrew@trop.in>
Subject: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for newer emacs.
Date: Thu, 02 May 2024 06:24:00 +0200 [thread overview]
Message-ID: <518c80a73207138ede449fb24c72ac4b79764b1e.camel@gmail.com> (raw)
In-Reply-To: <CH3PR84MB34248523A04EC53481BB9740C5192@CH3PR84MB3424.NAMPRD84.PROD.OUTLOOK.COM>
Am Mittwoch, dem 01.05.2024 um 16:06 -0400 schrieb Morgan Smith:
>
> I still feel like I'm conceptually missing something here. Emacs 30
> doesn't actually exist, right? We are currently on Emacs 29.
> emacs-next is the closest thing we have to Emacs 30. Regardless of
> if we create a new file or use my phase I sent, we will only be
> rebuilding the emacs-next stuff. The current emacs (29) is being
> left alone.
>
> >
> [...]
> Ok I think I now sort of see your point. You don't want a build up
> of legacy support code in our files. I do understand and support
> that and will send a patch of that nature if you would like.
> However, I do think at least supporting all of the current Emacs
> packages in guix is a nice thing to do.
>
> It is my personal opinion, that we should have the file support Emacs
> 29 and 30 for simplicity sake. But again, if you disagree with me
> (which is valid), I'll send you a patch creating a new file.
TL;DR: If we do a new file or a phase, we only rebuild emacs-next. If
we modify the file in-place, we rebuild emacs, because it uses it.
Between a phase and a new file, a new file is preferable, because we
can then 'mv' it over the old one.
> In guix/build/emacs-utils.scm:emacs-generate-autoloads, there is a
> condition to support emacs 28. I don't think we ever use that path
> anymore but it is nice to have a robust function that "just works".
> Espiaclly back when we did have emacs 28 and 29 packages in guix.
This is somewhat legacy code that has grown that way back when Emacs 29
was emacs-next. There was no good reason to drop it with the switch,
but come Emacs 30, 31, and maintainability might be one.
Cheers
next prev parent reply other threads:[~2024-05-02 4:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-28 17:07 [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for newer emacs Morgan Smith
2024-04-28 17:40 ` [bug#70632] [PATCH v2] " Morgan Smith
2024-04-29 18:44 ` [bug#70632] [PATCH 1/2] " Liliana Marie Prikler
2024-04-29 20:43 ` Morgan Smith
2024-04-29 21:38 ` Liliana Marie Prikler
2024-05-01 16:32 ` Morgan Smith
2024-05-01 16:46 ` Liliana Marie Prikler
2024-05-01 20:06 ` Morgan Smith
2024-05-02 4:24 ` Liliana Marie Prikler [this message]
2024-05-08 18:48 ` Morgan Smith
2024-07-07 6:36 ` bug#70632: " Liliana Marie Prikler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=518c80a73207138ede449fb24c72ac4b79764b1e.camel@gmail.com \
--to=liliana.prikler@gmail.com \
--cc=70632@debbugs.gnu.org \
--cc=andrew@trop.in \
--cc=cox.katherine.e+guix@gmail.com \
--cc=morgan.j.smith@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).