Closed minad closed 7 months ago
Hi, thanks for flagging this!
Option 1 is probably a little more build machinery than would be ideal. The weekly updates in nix-emacs-ci
already take some manual intervention, so it's not necessarily a good example to follow.
Re. Option 2, I'd prefer to avoid automatic downloads at runtime.
Option 3 just sounds like an approach for doing Option 1.
On balance, here's what I might suggest:
compat
from package-lint
Struggling for time currently so I might not work on this myself imminently.
Thanks! I made a first attempt at https://github.com/purcell/package-lint/pull/262. For now I generated data/compat-symbols manually from my local Compat repository. If you like you could merge this soon to solve the imminent problem with Emacs 30 compat.el. We could later try to automatize the symbol extraction.
I think not many people are affected right now (only the ones with a very recent Emacs 30 and package-lint). But I am sure the issue will pop up at some point, either here or on the Compat issue tracker. The number of Emacs master users is surprisingly high, but there is likely also a selection bias, since users who compile their own Emacs may report issues earlier.
Hi Steve,
recently a stub of compat.el got added to Emacs. The stub has the version emacs-major-version.emacs-minor-version.9999 such that Compat is never installed, if the current Emacs version is new enough. This makes sense since in this case the functions provided by Emacs are sufficient and Compat cannot provide more. The idea is that Compat should be free to use if your Emacs is new enough. See https://github.com/emacs-mirror/emacs/commit/db195116a4279521e9cf03c52b7026032461e3e1.
Unfortunately this leads to a problem with the approach we've chosen in #227 for loading the list of symbols defined by Compat. Package-lint throws the error "compat package not installed", since Package-lint expects the "real" Compat package to be around.
There are these solutions to work around this problem:
What do you suggest? Thanks!