From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Thu, 7 May 2020 22:29:31 +0300 Message-ID: <9a26332b-2e06-8d1f-9013-f50ba5a669be@yandex.ru> References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="66893"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: stefan@marxist.se, emacs-devel@gnu.org, joaotavora@gmail.com, pcr910303@icloud.com, eliz@gnu.org, drew.adams@oracle.com, monnier@iro.umontreal.ca To: rms@gnu.org, Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 07 21:33:12 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jWmGd-000HES-KY for ged-emacs-devel@m.gmane-mx.org; Thu, 07 May 2020 21:33:11 +0200 Original-Received: from localhost ([::1]:48162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWmGc-000704-Lt for ged-emacs-devel@m.gmane-mx.org; Thu, 07 May 2020 15:33:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWmDC-0004Dp-2w for emacs-devel@gnu.org; Thu, 07 May 2020 15:29:38 -0400 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:33580) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jWmDB-00060F-1G; Thu, 07 May 2020 15:29:37 -0400 Original-Received: by mail-wr1-x430.google.com with SMTP id h9so7795379wrt.0; Thu, 07 May 2020 12:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=D5HkGP3owgdcyV6mfKJ8hlxr8XDeV8eCorKNsY+e/I8=; b=NdrkAXrM9ye7F5NavbvvEwrBSzBSS4tOLUj67zRW1uUF3QrAMLb5INnpAI/pGlnELr A/79EZ69tufC1N/mrf5Bvw9fXGPyCjQeRE19ZCclRED9lullioNgdTumAE1ivmVJzpgY IPTX2LFBttFmZG05RwFCwOtFse9VGeBQpq9trMHlbEmlcE1h2Xm05x7tE37JjqJKewm3 4jrK1eGrFpEppeofVtxfS39P9avQLHhRMCEr7EsK/yFmmQwMMiL9MFaR9nnas+WHdQ/Q uc7NJJ/FLjMQe88ofwaGIe7ehK6IDlILAgYqdFn3JCTlhh+r0iNBc7B6jnoiQmK3dDNQ aVtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=D5HkGP3owgdcyV6mfKJ8hlxr8XDeV8eCorKNsY+e/I8=; b=QW3NW6D31OfrPh6J0UIjPeXAWzpiveM0vd/K2PaNt6xN9Jpv7FdKGksU+2b474D1nA ElEcCiqgHl9gU8zeMZozzyNz46xuzBe+sZcOHlr2/wICvp687a0Ajn2lvUlymZQJ9Q+d Y0vRALg4rFuCuRIsBpQnAuiwIVTfjX+wTiuE1LepKNiAfEyeQvb66Jw8Di6vcNsZutto IIMGIi06UogOl2mTdrKl9NhwIV8Wvkb06rXn89n4AZVSnzSeE6Wj/R2IBOHti2cZsUls MjlZG3fDYUlAqauINZPb7ajEt5OfisvNLYH1OnZ9c8XllB6GmJ9Pe/VOaZHPpFsucios oJJA== X-Gm-Message-State: AGi0PuZazLvvOG3WyNIqDdVefFc7zxtOrQoNMCWfFPJPoc2cjB6q883N 4aSvKtypDwz1kVBbyJWVdL4= X-Google-Smtp-Source: APiQypKe35tWwjIvsqLQGJdyVBlpv696ToloRUmqdWqfWMhkDmu1nDOCd+GXuceWhK5GkraJZOw0/g== X-Received: by 2002:a5d:414f:: with SMTP id c15mr17091137wrq.61.1588879774800; Thu, 07 May 2020 12:29:34 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id b66sm9722084wmh.12.2020.05.07.12.29.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 12:29:34 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=raaahh@gmail.com; helo=mail-wr1-x430.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:249204 Archived-At: 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.