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

[조성빈]

> 2020. 5. 12. 오전 1:26, Eli Zaretskii <address@hidden> 작성:
> 
> 
>> 
>> From: Stefan Monnier <address@hidden>
>> Cc: Philippe Vaucher <address@hidden>,
>>  address@hidden,  address@hidden,  address@hidden
>> Date: Sat, 09 May 2020 10:11:00 -0400
>> 
>>> I as a Emacs user would think s.el is a bad addition to ELPA -- it
>>> doesn't add anything special,
>> 
>> It is used by hundreds of packages.  So as long as it's not in GNU ELPA,
>> none of those hundreds of packages can be even considered for inclusion
>> into GNU ELPA.
>> 
>> That's the special that it adds.
> 
> So we are going to add s.el because it is used by hundreds of
> packages.  And then we will add some of those hundreds, and then we
> will add some more packages that use those other packages.  And so on
> and so forth.
> 
> But to what end, may I ask?  Those packages already exist and are
> available from MELPA, people are already using them, and installing a
> package from MELPA is no more effort than from ELPA.  So what is the
> purpose of adding them to ELPA as well, if all we are going to do is
> mimic the same procedures and requirements as MELPA?
> 
> GNU ELPA is (or was?) supposed to be an extension of Emacs.  Being an
> extension means the packages need to undergo almost the same quality
> control as the code in core.  Deferring such quality control to some
> imaginary future means simply that we decide not to do that: how can
> we seriously expect that the package authors will agree to changes to
> which they don't agree today, especially after so much time has passed
> and so many other ELPA packages already depend on them?  Those
> requirements are not arbitrary, they are supposed to keep Emacs easier
> to use, develop, and maintain.  By waiving those requirements today we
> in fact waive our ability to decide later whether or not to include a
> package in Emacs.  By that we actually remove the main, if not the
> only, reason to have ELPA at all.

Looks like everybody has a different idea of ELPA is. I personally viewed it as 
a blessed package repo, nothing that different from MELPA except that it’s the 
default, official one from Emacs. In that case, I want these packages in ELPA 
because I want my friend to try out rjsx-mode (which AFAIK is only in MELPA) by 
M-x package-install rjsx-mode without explaining what the init file is, why the 
state isn’t persistent, what package-archives is, how lisp works, etc...

So the point for me is that it’s the default. (And as an additional point is 
that an official GNU manual for a ‘How to make Emacs an IDE’ will probably 
never recommend MELPA nor any MELPA packages.)

However, I can fully understand your preferences. In that case, would adding 
MELPA or at least recommending MELPA to add them be possible in Emacs? 

>>> IOW, are you saying that the technical details of the package's
>>> implementation should not matter, for fear of sending the wrong
>>> message?
>> 
>> Pretty much, yes.  Not just "for fear", but because we do want to
>> encourage people to share their code (which can always be improved if
>> necessary).
> 
> They already share their code, on MELPA, on GitHub, on GitLab, etc.
> Why do we need to invest our efforts into one more repository "like
> that"?  It makes no sense at all.
>