Re: Proposal: Forwards-Compatibility Library for Emacs

[Stefan Monnier]

My conclusion is that it all depends and it can't really be decided in
the abstract.  So, if you show a prototype things will be much
more clear.


        Stefan


Philip Kaludercic [2021-09-22 06:48:30] wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I am not sure how this would help provide forwards compatibility for
>>> older versions? Are you proposing that instead of using
>>> file-name-concat, libraries use compat28-file-name-concat that is
>>> defined in a library for older versions?
>>
>> Yes.
>>
>>> My intuition would be that this wouldn't be worth the effort, seeing as
>>> most people would probably hesitate to use such long names.
>>
>> If the function is important enough that the author would otherwise make
>> its own local function, then I think they'd be happy to use that
>> slightly longer name rather than having their own local definition.
>>
>> If not, then it's probably just as well if they simply don't use it
>> (and that should avoid having the compatibility library accrue
>> too many definitions of too little value).
>
> This I'd describe as compatibility for convenience, but there are also
> examples where core ELPA implement general algorithms and functionality
> that could be used elsewhere too (project--buffers-to-kill and
> project--kill-buffer-check were mentioned as one example last year). But
> they cannot be factored out, because that would raise the minimal
> required version. The complementary example are external packages that
> hesitate to use newer functionality, for the same reason (I already gave
> the example of the second optional "interactive" argument). The
> infrastructure may not exist, but for anyone before Emacs 28, this could
> just be ignored away, while newer users get to keep it.
>
>>         Stefan
>>