From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Sat, 09 May 2020 09:59:25 -0400 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87wo5mc04t.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="112297"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: joostkremers@fastmail.fm, rms@gnu.org, emacs-devel@gnu.org To: ams@gnu.org (Alfred M. Szmidt) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 16:00:04 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 1jXQ1M-000T7x-E5 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 16:00:04 +0200 Original-Received: from localhost ([::1]:44056 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXQ1K-0000Ts-W2 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 10:00:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53292) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXQ0q-0008MZ-4f for emacs-devel@gnu.org; Sat, 09 May 2020 09:59:32 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65428) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXQ0o-00082r-PT; Sat, 09 May 2020 09:59:31 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E823C814D9; Sat, 9 May 2020 09:59:28 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 34A1A8107A; Sat, 9 May 2020 09:59:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1589032767; bh=FNsn58OP2YN+mRw1f3qIoXFztE+IGCFyo89tp4s/PzY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=kfC3HH78eQJnuBGyV67erX1OGPxz+SgdjlhQvBxoW4QhzjEs+dc4CVxee6Cjg2exV 6Egp+rmM6l0g4Iu8/k8zjCp+QnMFXLZ9Uk/ra7zLc2K/BYdjmuhSkua4M9K3f5nyf7 WkeSngUWbPCas2yrxA0IsF686U/zSq4Lw3p4OLtIyVblIoz7VuLw2pej8N31HfZvo/ gL9dYKLDzH2m58UfSIYeXTm+PAe6XrLnR94V7XhEfDNseCJ4EOanpNVn7UxE92WAgT xwrdY0/idNPSKiM7SKxdVuq5q/Vov+KO8u5dIWcACAPx+Zx771f8bnNHVl6y9ciU91 DYH/Zq2QWNAvQ== Original-Received: from alfajor (unknown [216.154.3.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7EB91120779; Sat, 9 May 2020 09:59:26 -0400 (EDT) In-Reply-To: (Alfred M. Szmidt's message of "Sat, 09 May 2020 04:35:41 -0400") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/09 09:45:08 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:249437 Archived-At: > - As far as I know you are the only one who objected strongly against > s.el in ELPA (others please voice your opinion if you think like > Richard). > > 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. > and makes code harder to read if people use such constructs in the > form that they are now, encouraging people to use s-titleize instead > of capitalize is going backwards, not forwards. I highly doubt including it in GNU ELPA will make much difference w.r.t encouraging people to use it. > I haven't seen anyone objecting from adding some of the more > complicated functions and making them follow a more Emacs-y form, or > even on a case-by-case basis renaming some string functions to make > more sense. That's a completely different discussion (which affects Emacs's core but doesn't help clear the obstacles for inclusion of other packages into GNU ELPA). > So why this forceful insistance of adding a s.el? Why not try to make > Emacs as a whole better by suggesting the better parts of s.el that > can be added to Emacs, or finding functions that could be renamed? Whether s.el is included into GNU ELPA has no bearing on whether or not we'll want to include some of its ideas into Emacs's core string functions. Stefan