Re: Imports / inclusion of s.el into Emacs

[Dmitry Gutov]

On 07.05.2020 05:44, Richard Stallman wrote:

>    > Richard, Eli: please decide wether you want s.el into ELPA or not.
>
> In its current form, I think it would be a grave mistake to include
> s.el in ELPA.  Its purpose is to make Emacs Lisp mimic object-oriented
> languages which are alien to Emacs Lisp.

No, its purpose is to mimic Clojure, which is a modern Lisp and a 
functional language. Not any more object oriented than CL.

> See my message to Stefan for a change that would make s.sl ok to add.
>
>    > I'm not sure why there's this sudden turnaround on this issue, maybe
>    > I'm missing something.
>
> I don't think there was a turnaround.  We never decided to include
> s.el in GNU ELPA.
>
> Before yesterday, we were talking about a different question: whether
> to adopt the s.el functions and their names in Emacs Lisp.  When I saw
> concretely what those actually were, I said no.

Are you saying that no decision, no matter how minor, should be 
considered "undecided" until you have personally weighed in?

Stefan has been responsible for GNU ELPA from the outset, and has been 
doing almost all the work on it. Both technical and social.

> Then yesterday I saw a message proposing to include s.el in ELPA, and
> _presuming_ that that was ok.  I responded no, saying that it would
> send Emacs Lisp down the same wrong path.  We should not have code in
> Emacs that uses string-prepend instead of concat.  We should fix that
> code to use concat.

I'm sorry, but you sound confused. No code in Emacs would use 
string-prepend because it's not in the cards for addition. *Some* code 
in GNU ELPA could start using s-prepend after s.el is added. But not in 
Emacs itself.

>    > This is a bit embarassing for me to have done the work of getting
>    > magnars to agree to put it there just to be refused at the last
>    > minute,
>
> I am sorry for your disappointment, because I feel for your eagerness
> to make a change you consider an improvement.  But we have to make the
> decision that is right.
>
> There is no need for you to feel embarrassed.  The people you talked
> with will understand that there is no reason to blame or criticize you
> for this.

I think this decision will do nothing to improve the community's 
reputation of emacs-devel (which has been improving in the recent years, 
but is still not stellar).

And overriding a fellow developer's decision in his area of 
responsibility *is* likely to affect his reputation. That seems to be 
not very ethical of you.

Note that I personally hold no love for s/f/dash.el, and use none of 
them in my projects.