GNU bug report logs - #66554
[PATCH] Add the public API of Compat to the core

Previous Next

Full log

Message #181 received at 66554 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> daniel-mendler.de, stefankangas <at> gmail.com, monnier <at> iro.umontreal.ca,
 66554 <at> debbugs.gnu.org
Subject: Re: bug#66554: [PATCH] Add the public API of Compat to the core
Date: Tue, 06 Feb 2024 19:59:09 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: mail <at> daniel-mendler.de,  66554 <at> debbugs.gnu.org,  stefankangas <at> gmail.com,
>>   monnier <at> iro.umontreal.ca
>> Date: Tue, 06 Feb 2024 19:10:32 +0000
>> 
>> >> +@defmac compat-call fun &rest args
>> >> +This macro calls the compatibility function @var{fun} with @var{args}.
>> >> +Many functions provided by Compat can be called directly without this
>> >> +macro.  However in the case where Compat provides an alternative
>> >> +version of an existing function, the function call has to go through
>> >> +@code{compat-call}.
>> >> +@end defmac
>> >
>> > This description left me without understanding when I need to use
>> > compat-call and when I can just call FUN.  Can you explain more?
>> 
>> The intention was for this paragraph to catch that case,
>> 
>>   However in the case where Compat provides an alternative version of an
>>   existing function, the function call has to go through
>>   @code{compat-call}.
>> 
>> though the real information is to be found in the Compat manual, where
>> the functions that have to be called via compat-call are documented.
>> 
>> Should the above sentence be rephrased to give a general feeling for
>> when this is the case
>> 
>>   However in the case where Compat provides an alternative version of an
>>   existing function, the function call has to go through
>>   @code{compat-call}.  This is the case when, for example the signature
>>   changes between versions, preventing older versions of Emacs from
>>   using optional arguments introduced in newer releases.
>> 
>> or should we just refer to the external manual?
>
> Let me try to make my point more clear: I'd prefer that the reader
> emerges from reading this description with a practical way of knowing
> when to call the function directly and when to call it via
> 'compat-call'.  If that's not easy to understand, perhaps we should
> tell that 'compat-call' should always be used, to avoid some rare
> corner cases where a direct call will not do, and be done?

I don't think we should recommend always using `compat-call', that would
make code unreadable.  What definitions have to be called via
`compat-call' really depends on how they were defined in Compat.  I
don't know of a better rule to describe it without copying the
documentation from the Compat manual (that wouldn't be a good idea
either, because it wouldn't stay up to date).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.