bug#66554: [PATCH] Add the public API of Compat to the core

[Daniel Mendler]

Daniel Mendler <mail@daniel-mendler.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Philip Kaludercic <philipk@posteo.net>
>>> Cc: mail@daniel-mendler.de,  66554@debbugs.gnu.org,  stefankangas@gmail.com,
>>>   monnier@iro.umontreal.ca
>>> Date: Sat, 10 Feb 2024 16:46:30 +0000
>>> 
>>> I might be mistaken, but from a cursory peak at package.el, specifically
>>> `package-activate-1', the Info search path is only updated if the
>>> package is activated.  If the core-package takes priority over an
>>> external package, the external package shouldn't get activated.
>>> 
>>> This hasn't been a problem in the past, because core packages don't come
>>> with their own manuals, but this is an exception since core-Compat is
>>> not really the same code as ELPA-Compat.
>>> 
>>> One way to fix this, would be to explain how to disable a package via
>>> `package-load-list' in the Compat manual.  I'll have to try it out, but
>>> if it works, I think that solution should be acceptable.
>>
>> Another way to fix this is simply to include the Compat manual in
>> emacs.git.
>
> No, this won't be useful. The Compat manual available at a given time is
> not relevant for the Emacs version developed at that time. If we would
> include the manual Compat 30 in Emacs 30, the manual will document
> functionality already present and documented in the Emacs 30 manual
> itself. The Compat 30 manual is only relevant for Emacs versions 29 and
> older.

Well, thinking more about it, for developers of :core packages (also
published on ELPA) the manual could still be helpful since the manual
will provide a list of functions with their calling conventions. However
if the Compat manual is included in Emacs itself it will get outdated
quickly, so it is better to refer to the newest version available on
ELPA.

Daniel