Hi, all. The following is also posted on the Aquamacs GitHub issue trackers at https://github.com/aquamacs-emacs/aquamacs-emacs/issues/211
This note is the beginning of a discussion about how to get Aquamacs updated to a current version of the main Emacs distribution.
The next planned release of Aquamacs is 3.6, which should be in beta soon. It has many bug fixes to the current codebase, which is based on Emacs 25.3. Right now, there is no plan for a 3.7 release, but it could happen if needed.
The next major release, tentatively called 4.0, will be Aquamacs based on Emacs 28. It's a big jump, and there will probably be some messy parts.
There are a couple of ways to approach this, and I'd appreciate any thoughts about what might work best. Whichever way we approach it, I want to try to maintain the git history as best we can.
The core Emacs code for the Mac has changed a lot since Aquamacs was first created, and diverged because there were different ideas at different times. I'd like to end up bringing them closer together, without sacrificing places where Aquamacs has improvements. Ultimately, it would be nice if Aquamacs was a fairly clean add-on to the base Emacs, but there's a lot of work to get there.
If I were undertaking the update entirely on my own, I would be tempted to run a giant merge with the current Emacs code, hack through the merge conflicts, and the debug the result.
If some of you are interested in helping out, we can approach it a different way.
In rough terms, we have the following big areas of Aquamacs code:
1. Aquamacs-specific addons and configuration in Lisp code
2. Bundled packages from elsewhere (e.g, AUCTeX, ESS)
3. Aquamacs changes to base Emacs Lisp code
4. Aquamacs changes to base Emacs C/Objective C code
5. Other changes around the edges (documentation, auxiliary files, etc.)I
With a group working on it, we could break it out by focusing small pieces of work on the Aquamacs features and Lisp files, stubbing out anything that needs a new or changed interface in the C/Obj-C code. Similarly, we could work on more isolated pieces of the merging the C/Obj-C code, although some of it will of course be a bit tangled.
Or you might have some other ideas about how to approach this. I haven't mapped out any of this in detail yet, but I'm interested in any thoughts about how to go about it, and in finding out if anyone is interested in working on it.