From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Wed, 13 May 2020 00:07:32 -0400 Message-ID: References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <83d07984ux.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="126180"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joostkremers@fastmail.fm, Emacs-devel@gnu.org, ams@gnu.org, pcr910303@icloud.com, eliz@gnu.org, phillip.lord@russet.org.uk To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 13 06:08:22 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 1jYigv-000WjA-V7 for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 06:08:21 +0200 Original-Received: from localhost ([::1]:44608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYigv-0003Mr-0I for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 00:08:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYigD-00029c-EQ for Emacs-devel@gnu.org; Wed, 13 May 2020 00:07:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57404) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYigD-0001mK-52; Wed, 13 May 2020 00:07:37 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jYig8-0007zU-AK; Wed, 13 May 2020 00:07:32 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 12 May 2020 14:42:09 -0400) 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:250091 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > We can simply refuse to incorporate `s.el` into core and then any > package which wants to be in core will first have to sop using `s.el`. > Accepting `s.el` into GNU ELPA does not mean we will accept it > into core. Emacs and GNU ELP are both under our control, but we don't > need to (and we don't) apply the same rules to the two. Keeping s.el out of the core would not avoid the problem that s.el causes. Simply having it in GNU ELPA causes the problems. The problems are that (1) we have two incogruent series of string functions, and (2) we are compelled to cede control of the s-... name space to people who con't coordinate with us. Even in the core, we would have to treat the s-... name space as reserved simply because "many packages" use s.el. The only way I can see to fix this problem is with symbol renamings. If we fix it that way, we could have s.el in GNU ELPA and even in the core. At least I think so. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)