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: New Package for NonGNU-ELPA: clojure-ts-mode Date: Tue, 29 Aug 2023 10:33:59 +0300 Message-ID: <39c0d8e2-2caf-4368-b0b3-0fbd76fcb731@app.fastmail.com> References: <87il9kksqz.fsf@dfreeman.email> <83350ncbns.fsf@gnu.org> <87cyzrjbd8.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <87wmxj27fn.fsf@dfreeman.email> <831qfrptiq.fsf@gnu.org> <57429221-d9be-5791-e975-b3539905e2f6@gutov.dev> <83a5udlj47.fsf@gnu.org> <87a5udk1co.fsf@posteo.net> <835y51kslv.fsf@gnu.org> <7a82c524-1aa1-e755-e377-673ebb107a44@gutov.dev> <83r0nok8s4.fsf@gnu.org> <87il90znco.fsf@yahoo.com> <1977fbef-307b-bcf4-9448-64f26916dd65@gutov.dev> <87edjozlqq.fsf@yahoo.com> <43ddad10-49dd-1c49-ebfe-51689780b315@gutov.dev> <87msyciplu.fsf@posteo.net> <83h6okk3oe.fsf@gnu.org> <87edjoindn.fsf@posteo.net> <83bkesjwuk.fsf@gnu.org> <83bkeri1cz.fsf@gnu.org> <833502inw2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=081597155ea544228c49e656061c9d67 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27111"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.9.0-alpha0-701-g9b2f44d3ee-fm-20230823.001-g9b2f44d3 Cc: "Philip Kaludercic" , "Dmitry Gutov" , "Po Lu" , "Danny Freeman" , "Stefan Kangas" , "Emacs Devel" , "Manuel Uberti" To: "Eli Zaretskii" , "Lynn Winebarger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 29 09:35:12 2023 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 1qatFm-0006m5-Ol for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Aug 2023 09:35:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qatFF-0006Jv-M9; Tue, 29 Aug 2023 03:34:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qatF8-0006J9-U5 for emacs-devel@gnu.org; Tue, 29 Aug 2023 03:34:33 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qatF5-000847-0e; Tue, 29 Aug 2023 03:34:30 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 720525C00E4; Tue, 29 Aug 2023 03:34:24 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Tue, 29 Aug 2023 03:34:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1693294464; x=1693380864; bh=x6 CRW4Pgxs5HhkT/xwwwdrcwCclc5EGPaMpgK1FR6+E=; b=WxZsP7+9ptU6Sr+pCL M0tj14aUMbKNpxmHDhe7O2m80xbbvKyeWMgonJQD0GsxNdNhsHoKqUtdeujCu7Ab 7LvHmdY5ljToqpTEiVF9f8ECopvCSj2KFYR/1decmVtg1bAm6RfisRinXBwf7plo 7YJb6Nv6aVEJB0wXGcDM5D8vaM25W9DSZs+W3F+A33qowUiZ3cr2xo3NERSdD8Uv 6McniBftYwtNtPjwZO1pa49gto6dVYF955wtcGpNPNIkxKmbZdIBl8uuGQGgOjKP oaPvcaQlcRWxp8eVtrjbOqk6K+5iu84UStTY9OpKjEqmC5mbdmsq9o3Z0GHb3PS5 2IiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1693294464; x=1693380864; bh=x6CRW4Pgxs5Hh kT/xwwwdrcwCclc5EGPaMpgK1FR6+E=; b=f5qwYa2oi3sKz+1YawHLVTCZtDd9O qrl5TD9vuN50yVxu/CHUj4knzD+s+EFPYAoEkYTctTTMtvpWbZ9Pb7GfteisfgZh /Q72MyewQB3ZI3img16I8USLB3lJY2dy5iW3SB19VLbgyXULhFnXMqkn65hHMRmI H5AlEsSmUwCdgy3gqF3IZjj5gi2Tc7YbXPlUNPsHY9SOGG42bHJhOmgeJKxZNyDV eSr2BGdS9FZAitXopO3XP/u9ZVYknMdi/irMVLWBbkYwevwLje2H/nyIXkZfDQnj Uc4mke7kFyyeOAqPbXwxRF0TCfbZv19wfRo6MxwpV07OYDF3pfY8CQ9dQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefhedguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreertdenucfhrhhomhepfdeu ohiihhhiuggrrhcuuegrthhsohhvfdcuoegsohiihhhiuggrrhessggrthhsohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeeftdekgfdvgfehueffheejudehkefgffffheektdet vdejgfelheeiiefhffffgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegsohiihhhiuggrrhessggrthhsohhvrdguvghv X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 41A8A2D4008F; Tue, 29 Aug 2023 03:34:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <833502inw2.fsf@gnu.org> 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.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309479 Archived-At: --081597155ea544228c49e656061c9d67 Content-Type: text/plain > That's formally true, but doing this over the objections of the > original authors would be IMO rude, and I would not agree to that > lightly. I agree that'd be rude. I also think that'd be quite confusing for the end users and will make some of the operations (e.g. submission of bugs) a total mess. Neither the Clojure, nor the Emacs communities are big enough to engage lightly in time-wasting activities. And, I'll say it once more - in case this was missed in the conversations. Personal misgivings about the mechanics of Emacs's development aside, I think it's not prudent to keep growing its core, which is already huge. Obviously it's up to the Emacs developers to decide what to do, but I'd be moving more things into packages and bundling less things with Emacs. You might have seen this trend in some programming languages - e.g. Ruby has slimmed down its core a lot and this helped channel the efforts of the core team. I think by now pretty much every user of an editor or a programming language is used to installing packages to augment the core functionality, so I'm not buying the argument that we need to have more things OOTB. IMO the core of Emacs should consist of fewer, but truly essential packages. Someone mentioned it'd be nice if Emacs suggested packages to install for certain (unsupported OOTB) file types and I think that'd be a nice way to help with package discovery. Perhaps packages can just mention this in their metadata? On Tue, Aug 29, 2023, at 5:27 AM, Eli Zaretskii wrote: > > From: Lynn Winebarger > > Date: Mon, 28 Aug 2023 16:03:27 -0400 > > Cc: bozhidar@batsov.dev, philipk@posteo.net, dmitry@gutov.dev, > > luangruo@yahoo.com, danny@dfreeman.email, stefankangas@gmail.com, > > emacs-devel@gnu.org, manuel.uberti@inventati.org > > > > Whatever authority Bozhidar has is over the project he's a maintainer > > of, not over emacs or clojure features incorporated in it, or even, > > frankly, the software produced by his project. It is licensed as free > > software, after all. The only meaningful constraint on the creation of > > a fork, major or minor, of free software is the pain involved in > > maintaining such forks. > > That's formally true, but doing this over the objections of the > original authors would be IMO rude, and I would not agree to that > lightly. > > > I'm not sure why you would assume the project that > > created/maintains/develops an external package would necessarily want > > to contribute the additional labor required to participate in the > > emacs development process. If the emacs project wants to incorporate > > such a package in core, it's not unreasonable to expect it to provide > > the resources required rather than expecting the additional labor be > > done by the external project. > > The Emacs project can and does provide additional labor, but not when > the authors object to including their package. > > --081597155ea544228c49e656061c9d67 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
That's formally true, but doing this ove= r the objections of the
original authors would be IMO rude= , and I would not agree to that
lightly.

I agree that'd be rude. I also think that'd be = quite confusing for the end users and will make some of the operations (= e.g. submission of bugs) a total mess. Neither the Clojure, nor the Emac= s communities are big enough to engage lightly in time-wasting activitie= s.

And, I'll say it once more - in case th= is was missed in the conversations. Personal misgivings about the mechan= ics of Emacs's development aside, I think it's not prudent to keep growi= ng its core, which is already huge. Obviously it's up to the Emacs devel= opers to decide what to do, but I'd be moving more things into packages = and bundling less things with Emacs. You might have seen this trend in s= ome programming languages - e.g. Ruby has slimmed down its core a lot an= d this helped channel the efforts of the core team.

<= /div>
I think by now pretty much every user of an editor or a progra= mming language is used to installing packages to augment the core functi= onality, so I'm not buying the argument that we need to have more things= OOTB. IMO the core of Emacs should consist of fewer, but truly essentia= l packages.

Someone mentioned it'd be nice= if Emacs suggested packages to install for certain (unsupported OOTB) f= ile types and I think that'd be a nice way to help with package discover= y. Perhaps packages can just mention this in their metadata?
<= div>
On Tue, Aug 29, 2023, at 5:27 AM, Eli Zaretskii wrote= :
> From= : Lynn Winebarger <owinebar@gma= il.com>
> Date: Mon, 28 Aug 2023 16:03:27 -0400<= br>
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> frankly, the software produced by his project.  It is license= d as free
> software, after all. The only meaningful co= nstraint on the creation of
> a fork, major or minor, o= f free software is the pain involved in
> maintaining s= uch forks.

That's formally true, but doing = this over the objections of the
original authors would be = IMO rude, and I would not agree to that
lightly.
=

> I'm not sure why you would assume the project t= hat
> created/maintains/develops an external package wo= uld necessarily want
> to contribute the additional lab= or required to participate in the
> emacs development p= rocess.  If the emacs project wants to incorporate
&g= t; such a package in core, it's not unreasonable to expect it to provide=
> the resources required rather than expecting the add= itional labor be
> done by the external project.

The Emacs project can and does provide additional= labor, but not when
the authors object to including their= package.