[dimpase]

Fixes #4691.

The Emacs package copy could run before the build-tree emacs/M2-symbols.el was generated: the relative dependency could resolve to the checked-in source file instead. Use the explicit build-tree path so grammar generation finishes before the copy runs.

Emacs itself is not used to generate the package. The earlier CMake and Autotools checks for the Emacs executable have been removed; the final diff is a one-line CMake dependency fix.

Validation: reproduced the original copy failure with both Unix Makefiles and Ninja in an isolated editor-build harness using an existing M2 executable. Both builds pass with the fix, including regeneration after deleting the build-tree symbols file. A failing Emacs stub was not invoked. No full M2 rebuild was performed.

This is independent of #4725: that PR handles submodule source availability, while this change fixes generated-file ordering.

🤖 gpt-6-astra worked on this 🤖

[dimpase]

oops, this might have a wrong base? @d-torrance ?

[dimpase]

OK, now the base is fine. @d-torrance - who can review this?

[d-torrance]

I don't think detecting the presence of Emacs during the build is the right fix for #4691, or even something we should be doing at all. We don't actually call the Emacs binary anywhere during the build, so there's no reason to require it.

The root cause of #4691 looks to be something different (No such file or directory when trying to copy a file.)

[dimpase]

OK, @d-torrance - this is just 1-liner now.

[dimpase]

@d-torrance @mikestillman - do we want to make the emacs interface a proper M2 package? This would allow to get rid of the git submodule, I suppose.

[d-torrance]

I would love to get rid of the submodule! I've got some ideas to distribute the emacs package MELPA-style from the website (we can't get in actual MELPA unless we agree to rename the package from M2 - they don't like capital letters) and have setupEmacs install that

[dimpase]

thus, on the user side this would be via installPackage, right?

Or you'd rather do everything from emacs then?

[d-torrance]

Probably still setupEmacs, which is in Core

[dimpase]

you mean M2's core?

[d-torrance]

Yeah, exactly. Right now it writes to the user's .emacs file to ensure that Emacs knows how to load the package. We could instead have it add an "M2ELPA" package repo and install the M2 package if it's not available (probably using use-package for modern Emacs and a fallback for backwards compatibility).

[dimpase]

🤖
A follow-up plan: move responsibility for Emacs support entirely into Macaulay2/M2-emacs, and remove the Emacs submodule from M2. This should be two coordinated PRs, preparing the independent package before removing the bundled copy.

The starting point is good: M2-emacs already supports Emacs package managers, contains generated symbols and help files, and has its own symbol-generation script.

1. Make M2-emacs fully self-contained.

   • Verify installation, autoloads, .m2 file recognition, and updates through Emacs.
   • Provide configuration for locating the M2 executable and its documentation, replacing the useful work currently done by setupEmacs().
   • Keep installation and editing usable without an M2 executable; require it only for running computations.
   • Maintain generated symbols in M2-emacs, refreshed using an external M2 during development or release preparation, not during user installation.
   • Move ownership of Emacs-specific instructions there, avoiding circular dependence on M2 documentation generation.

2. Establish the distribution path.

   • Test the existing Emacs 30 use-package :vc installation.
   • Prepare and submit a MELPA recipe.
   • Provide a downloadable package archive for offline installation and older supported Emacs versions.
   • Document compatibility with M2 versions and provide instructions for distribution maintainers, including Gentoo.

3. Remove Emacs bundling from M2.

   • Delete the submodule and its .gitmodules entry.
   • Remove CMake and Autotools generation, copying, installation, and submodule-update rules.
   • Remove Emacs outputs from the shared grammar generator, preserving Prism, Vim, and Pygments generation.
   • Update CI, Docker builds, source archives, RPM packaging, and installation-layout settings.
   • Adjust Avoid checking out unused CMake dependency submodules #4725's selection logic and tests so they no longer require the Emacs submodule.

4. Handle setupEmacs() compatibility explicitly.

   • Remove its configuration-writing implementation from core.
   • Initially retain a small deprecated setupEmacs() function that prints the new installation instructions without editing files.
   • Stop setup() from configuring Emacs.
   • Document how users remove the old generated configuration, which could otherwise load an outdated bundled interface. Do not silently rewrite existing user configuration.
   • Remove the compatibility function in a later release.

5. Validate both sides before removing the submodule.

   • Install the Emacs package into a clean Emacs profile; test editing, completion, starting M2, sending code, and documentation access.
   • Test installation without M2, then execution with an installed M2.
   • Build and install M2 with CMake and Autotools from clean checkouts and source archives, with no Emacs submodule present.
   • Verify that other editor assets still build and that M2 neither downloads nor installs Emacs support.

Merge order: independent package and tested installation instructions first; M2 removal second. MELPA acceptance can proceed separately because direct installation from Emacs already provides a migration path. The fix in #4692 remains useful for builds before this transition.

🤖 gpt-6-astra worked on this 🤖

[dimpase]

PRs coming up

[dimpase]

@d-torrance - this PR is now an 1-liner, easy to review

[d-torrance]

Looks good to me -- thanks!

The bug this fixes was a regression caused by me in Macaulay2/M2-emacs#87, when we started commiting M2-symbols.el instead of the gzipped M2-symbols.el.gz (this way, it gets byte-compiled when installing the Emacs package). Having a copy in the source directory satisfied the dependency to copy from the build directory, which caused an error if we hadn't built it yet.

[MichaelABurr]

Looks good to me