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

[Philip Kaludercic]

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:29:00 +0000
>> 
>> >> Note that Compat provides replacement functions with extended
>> >> functionality for functions that are already defined (@code{sort},
>> >> @code{assoc}, @dots{}).  These functions may have changed their
>> >> calling convention (additional optional arguments) or may have changed
>> >> their behavior.  These functions must be looked up explicitly with
>> >> @code{compat-function} or called explicitly with @code{compat-call}.
>> >> We call them ``Extended Definitions''.  In contrast, newly ``Added
>> >> Definitions'' can be called as usual.
>> >
>> > Thanks.  I suggest to copy the above paragraph to the ELisp reference
>> > manual, 
>> 
>> OK, can do.
>> 
>> >         and add a cross-reference to the Compat manual after it.
>> 
>> IIUC the cross-reference will be broken, unless the user has installed
>> Compat manually.
>
> I wouldn't be worried about that: the cross-reference is readable, and
> the reader will understand what it says even if it cannot be followed.
> We do that for other manuals, which belong to other packages that
> might not be installed.

OK.  I don't have access to the machine with the latest version of the
patch, but as soon as I get that going again, I'll update it and push
the change to master.

>> Moreover, if I am not mistaken, the documentation bundled with the
>> Compat package might not be loaded at all, if the package isn't
>> activated due to the versioning trick.
>
> What do you mean by "not loaded"?  If a package is installed, its Info
> manual is also installed, isn't it?  And if you mean the manual might
> not be on the Info search path, then that again goes back to the
> "package not installed" scenario, which I don't think we should worry
> about.

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.

> Thanks.

-- 
Philip Kaludercic