[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
- Re: Proposal: Forwards-Compatibility Library for Emacs, (continued)
- Re: Proposal: Forwards-Compatibility Library for Emacs, Lars Ingebrigtsen, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, João Távora, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, Stefan Monnier, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, Philip Kaludercic, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, Stefan Monnier, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, Philip Kaludercic, 2021/09/22
- Re: Proposal: Forwards-Compatibility Library for Emacs, Stefan Monnier, 2021/09/22
- Re: Proposal: Forwards-Compatibility Library for Emacs,
Philip Kaludercic <=
- Re: Proposal: Forwards-Compatibility Library for Emacs, Stefan Monnier, 2021/09/22
- Re: Proposal: Forwards-Compatibility Library for Emacs, Lars Ingebrigtsen, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, João Távora, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, Lars Ingebrigtsen, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, João Távora, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, Lars Ingebrigtsen, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, João Távora, 2021/09/21
- Re: Proposal: Forwards-Compatibility Library for Emacs, Philip Kaludercic, 2021/09/22
- Re: Proposal: Forwards-Compatibility Library for Emacs, João Távora, 2021/09/22
- Re: Proposal: Forwards-Compatibility Library for Emacs, Arthur Miller, 2021/09/22