[Top][All Lists]

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

Re: Imports / inclusion of s.el into Emacs

From: Dmitry Gutov
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Thu, 7 May 2020 22:29:31 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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.

reply via email to

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