From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Bozhidar Batsov" Newsgroups: gmane.emacs.devel Subject: Re: Adding new packages to NonGNU ELPA Date: Wed, 25 Aug 2021 18:49:09 +0300 Message-ID: <9e22f8ff-abb9-46ba-b18d-3a5e81748e01@www.fastmail.com> References: <1290e095-feae-49d3-945e-0e67a806d418@www.fastmail.com> <3c943d23-8e6e-4e7c-aea6-49f0bfc027b5@www.fastmail.com> <1264ea7a-c6e5-4f9d-8332-addd89e133af@www.fastmail.com> <87lf4p943c.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=c77b1706a1d84cd495f61544f47a788a Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15641"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.5.0-alpha0-1125-g685cec594c-fm-20210825.001-g685cec59 To: "Emacs Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 25 17:50:51 2021 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 1mIvAu-0003rN-Jr for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Aug 2021 17:50:50 +0200 Original-Received: from localhost ([::1]:46246 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mIvAt-0003q9-3B for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Aug 2021 11:50:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIv9m-0002KB-QS for emacs-devel@gnu.org; Wed, 25 Aug 2021 11:49:39 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:34597) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mIv9h-00049M-8D for emacs-devel@gnu.org; Wed, 25 Aug 2021 11:49:38 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C6C4A5C01C1 for ; Wed, 25 Aug 2021 11:49:30 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Wed, 25 Aug 2021 11:49:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=IKWyH71WR4bgmlaA9PTKZtqnp4NS7PA JErrUydhsDAc=; b=FZbJHgU9MqZS7Jrmm03NsLXQyjjQ/PWtOkeJz2ZyfBG8JVt BYLnEDHa7jup4iWwcChTherp1M3QU5MAYNDHACm1xVF2nqP8IE6XGCg78TImQU3n ckGLK2L0Y3kSKp2oApcT81EzLMZM1yKldts+U0/kf9bRpjNVk/M9OGZPsYDG6GeI g0UHrlN8FScajmYPcK0cam5C01p+FJff6BdcjNqfQM0vWgjanlQpU424/ETwTPS+ 0DW2xLZbqz7ZdwUZ7jqu3DXLbBifH0Kj0vQQ0itt45E7bP/uHAVBOImQzc2N5MIk w4x8PHM2+GtMTHS6TBCA9P3qv7JyyXKL+q+fXEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=IKWyH7 1WR4bgmlaA9PTKZtqnp4NS7PAJErrUydhsDAc=; b=lnl+uNXPqh7mPY5RuGac99 m8gOGm23b1/fGFLvRJ8lAhWvJTEQLt6OZNnOpwUhcP/fMlF7kbFZaJtDWjNwNvnk zq/nIgIqDcCkXTABSWGK6gvcdyBTSDIGRQRkCowCuOb3Qaf73uO39x45Ai3AhxkM /vstatvzktYQLnfeHEEB/Pp1jApQzs4DjLMY7MmQtRQs9690tsIg8KPxlY23+RQE hyqIjTWmQEj1S3XpesZ/vmDtIFKJ/cc8GuTCMX3vd6IP/TtEjR55m1ZaiusKMof7 viA3V3w18d/DfVgUONAIii13HjmzBbWp8mrDVNYBn0NIonzhwL4gWy3+UE7K8MRQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddtledgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeuohii hhhiuggrrhcuuegrthhsohhvfdcuoegsohiihhhiuggrrhessggrthhsohhvrdguvghvqe enucggtffrrghtthgvrhhnpeeiteeuheevvddujefhteejvdegheelhedtkefhvdethefh feefiedtkeekheeihfenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoiihhihgurghrsegs rghtshhovhdruggvvh X-ME-Proxy: Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7BDD1AC0E77; Wed, 25 Aug 2021 11:49:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <87lf4p943c.fsf@posteo.net> Received-SPF: pass client-ip=66.111.4.28; envelope-from=bozhidar@batsov.dev; helo=out4-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no 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:272983 Archived-At: --c77b1706a1d84cd495f61544f47a788a Content-Type: text/plain > One of my hopes regarding NonGNU ELPA was that certain packages, > including dependencies could be effectively deprecated. Among these I > hoped to see packages such as a (but also s, f, ht, ...). My > understanding was that these were created to either compensate > deficiencies in the build-in functions provided by older versions of > Emacs. The other reason is that some people prefer a more functional > style of programming, that the usual stateful, imperative-ish Elisp > doesn't always provide. I guess in the end of the day that mostly depends on the package maintainers. Some are quite attached to those utility libraries, even if I myself don't like them and I've always avoided them. But I happen to be the type of person who avoids external dependencies as much as possible in general. :-) It was actually me who added the most common functions from s.el to Emacs itself a few years ago. Probably something like this should be done for f.el as well at some point. For CIDER one can follow the progress of removing a.el from parseclj here https://github.com/clojure-emacs/parseclj/pull/29 Some limitations of map.el are preventing this change from being wrapped up fully, though. Still, there are no showstoppers. On Wed, Aug 25, 2021, at 2:05 PM, Philip Kaludercic wrote: > "Bozhidar Batsov" writes: > > > Here's the next batch of patches, I hope I got everything right. I've > > started with the simple packages and I'll continue with CIDER and its > > related packages, as they have a bunch of transitive deps I'll need to > > add to NonGNU ELPA as well (a, parseedn, parseclj). > > One of my hopes regarding NonGNU ELPA was that certain packages, > including dependencies could be effectively deprecated. Among these I > hoped to see packages such as a (but also s, f, ht, ...). My > understanding was that these were created to either compensate > deficiencies in the build-in functions provided by older versions of > Emacs. The other reason is that some people prefer a more functional > style of programming, that the usual stateful, imperative-ish Elisp > doesn't always provide. > > Regarding the first motivation, I think it is legitimate, because that > is how backwards compatibility can be maintained. It might therefore > make sense to provide a compatibility library-package to provide useful > but perhaps simplified/dummy definitions of new functions, macros and > variables added in newer versions of Emacs. That of course would only > make sense if there is any consensus that the community libraries > shouldn't be used. > > -- > Philip Kaludercic > > --c77b1706a1d84cd495f61544f47a788a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
One of my hopes regarding NonGNU ELPA wa= s that certain packages,
including dependencies could be e= ffectively deprecated. Among these I
hoped to see packages= such as a (but also s, f, ht, ...). My
understanding was = that these were created to either compensate
deficiencies = in the build-in functions provided by older versions of
Em= acs. The other reason is that some people prefer a more functional
style of programming, that the usual stateful, imperative-ish E= lisp
doesn't always provide.
I guess in the end of the day that mostly depends on the pa= ckage maintainers. Some are quite attached to those utility libraries, e= ven if I myself don't like them and I've always avoided them. But I happ= en to be the type of person who avoids external dependencies as much as = possible in general. :-) It was actually me who added the most common fu= nctions from s.el to Emacs itself a few years ago. Probably something li= ke this should be done for f.el as well at some point.
For CIDER one can follow the progress of removing a.el from = parseclj here https://github.com/clojure-emacs/parseclj/pull/29 Some= limitations of map.el are preventing this change from being wrapped up = fully, though. Still, there are no showstoppers.  
<= br>
On Wed, Aug 25, 2021, at 2:05 PM, Philip Kaludercic wrote:=
"Bozhidar = Batsov" <bozhidar@batsov.dev> writes:


Philip Kaludercic



--c77b1706a1d84cd495f61544f47a788a--