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 18:54:54 +0000

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 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.

I attached a prototype to the first message?

>         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
>>>
>

-- 
        Philip Kaludercic



reply via email to

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