emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: Forwards-Compatibility Library for Emacs


From: Philip Kaludercic
Subject: Re: Proposal: Forwards-Compatibility Library for Emacs
Date: Wed, 22 Sep 2021 06:48:30 +0000

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
>

-- 
        Philip Kaludercic



reply via email to

[Prev in Thread] Current Thread [Next in Thread]