emacs-devel
[Top][All Lists]
Advanced

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

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]


From: Phillip Lord
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Tue, 12 May 2020 18:30:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Stefan Monnier <address@hidden>
>> Date: Mon, 11 May 2020 23:55:10 -0400
>> Cc: address@hidden, address@hidden, address@hidden,
>>  address@hidden, address@hidden
>> 
>> > I see the distinction, but either way it would cause the same problem.
>> > The problem is a second, incoherent set of string functions.
>> 
>> But it's a problem we can't solve, because the library is out there are
>> people use it.  Furthermore it's only hypothetical.
>
> It won't stay hypothetical if we allow incoherent packages into ELPA
> and start accepting their use in other packages and eventually in
> core.  People will ask us to use them more, people will ask us to
> document them, people will ask us to fix bugs in them, and eventually
> to use them in our own code.  In a word, people will rightfully expect
> us to take full responsibility on every such package.  The costs will
> come, I have no doubt about it.


Well, dash, f, and s are already been maintained, already being used,
already being fixed, documented (rather well, actually), and tested.

Perhaps, if the people doing this work saw that their work was
gratefully accepted, and allowed to continue doing it with the minimum
of fuss and not too much design by committee, then they would continue
doing it.

>> I'll just recommend people add MELPA to their `package-archives` and
>> move on.
>
> Please don't.

Please understand why.

Phil




reply via email to

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