From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: "Write a new package" culture instead of patches? Date: Sun, 17 May 2020 16:13:00 -0700 Message-ID: References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <405FCFAB-30E4-4F98-81DA-3B09933E86D0@gnu.org> <207f6196-8df8-0941-b01f-1537c3e080e8@yandex.ru> <2A2E84A7-1737-4BAA-A603-39A328BF44B6@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bf281605a5e03086" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="114393"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , joostkremers@fastmail.fm, EMACS development team , "Alfred M. Szmidt" , Stefan Kangas , =?UTF-8?B?7KGw7ISx67mI?= , Dmitry Gutov , Eli Zaretskii , Stefan Monnier , Phillip Lord To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 18 01:33:23 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 1jaSmX-000Tde-NW for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 01:33:21 +0200 Original-Received: from localhost ([::1]:60102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaSmW-0004IF-Ej for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 19:33:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40308) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaST5-0000S6-W4 for Emacs-devel@gnu.org; Sun, 17 May 2020 19:13:17 -0400 Original-Received: from mail-yb1-xb30.google.com ([2607:f8b0:4864:20::b30]:46544) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaST4-0006a9-O9; Sun, 17 May 2020 19:13:15 -0400 Original-Received: by mail-yb1-xb30.google.com with SMTP id s37so4330598ybe.13; Sun, 17 May 2020 16:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8espAXLxEdXlyVdc2nQCw8ZCtsBSHZ6xAhOsOR4dvFc=; b=ip2pKDzNgrScQEzEX99y+/URL02m36R99hysjQvxGwF8tmgBCGf/1NrfRKqzkFqngF ehEzFACL4+rpVWHbUdLSx1Elj2o0J1GL9W3+3cc6eIIdMGQc907qI9hhe/RjIOOGJsQV tDvFjoqazu8gsjoSidTg1CkqPbHOvdhz7NwV1Z7BjksNOUom4NT/9GPeInG0Vf5GvhlT 6+ypFjseHFaVMQQrUr5tC7XeUEDPjKwUrK+29J4x+XxI05pacs51H1sve7J7f8ErUMSH 1KdOLlXpSsyri4I2rXVk7qdpYieIfkCNZ70r1LTMejghE7GebXqu617XgQjIj3tssQKE 8T0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8espAXLxEdXlyVdc2nQCw8ZCtsBSHZ6xAhOsOR4dvFc=; b=bFpdzVHup7gu0pJ+KfS0XSqOt34Kv1Y9BGMwUFUqwoAhEz+VcIVULX6uDLyEazzh/m KnZeOOhmYA1I6yRxHiJIAS+GE+L+0Qz3tAajLcvMbxDEpmuZ7csOKKmU76X/pwYMbIvE as/JNxCgW614EHvMG4++rN5/Iwr8D4LXlc4BH9aMv9pYlnYcEYzwVfmG85yFN2KwLuF7 7951nYR+ICE82c3TbSVHVpKWEoSp8HFc+5Xbwe9PmmLS4BJHSiSelq5+XIWeLoW/pgcF 6HbTjhDRQt23YZmfT/rv74xtxWOgexgJG0MyxuUO8wl5UgoN98LYzneXhWe9/dgEowrM ls7Q== X-Gm-Message-State: AOAM531qF7Xp2MB/DssAcrNw/WEUj4ZGVifNNQdtP07jTF9zToE/IQyg OfwyyTPLwR3ZuJ5+9Z2IiBvDewAG6mA764PUe8E= X-Google-Smtp-Source: ABdhPJx8NmasPIepRRHxl4RiepqfdfEkyBt4wAw255rQsJ8FJ/YYyoTRA7NqHmO7FJYdcEeWvM6LAhieY00PPONAmzk= X-Received: by 2002:a25:76ce:: with SMTP id r197mr20908476ybc.502.1589757192643; Sun, 17 May 2020 16:13:12 -0700 (PDT) In-Reply-To: <2A2E84A7-1737-4BAA-A603-39A328BF44B6@gmail.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::b30; envelope-from=yandros@gmail.com; helo=mail-yb1-xb30.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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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:250683 Archived-At: --000000000000bf281605a5e03086 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 17, 2020 at 3:38 PM Yuan Fu wrote: > > On May 17, 2020, at 3:42 PM, Dmitry Gutov wrote: > > > > On 17.05.2020 21:52, Stefan Kangas wrote: > >> Why are > >> the authors of "helpful.el" not helping us mainline some of their grea= t > >> innovation, for example? > > > > I think Wilfred worked on some patch or other, to upstream some of the > improvements. But not the whole of it. > > > > Maybe because it's a much bigger job: to port the code, to satisfy all > the historically accumulated edge cases, and to spend a few weeks arguing > with whoever thinks the previous behavior was better at least in some > respect. > > > > We don't really have a conceptual framework for assessing big breaking > changes. > > I think it=E2=80=99s just much easier to write helpful.el from scratch th= an read > all the old code and understand it and try to patch it. I could have > patched package.el to make it fetch from github repos, but instead I just > wrote a quick small package to do that and moved on, which is much easier > than reading and understanding package.el and convince people that such > change is necessary. Extending this thought even further, I think that there is a perception from people outside emacs-devel (and also some inside emacs-devel) that "big" changes are often subjected to a "trial/pilot period" on GNU ELPA. This seems entirely reasonable, but there are some important extra caveats: 1.) Almost everything that makes substantial user-visible changes in emacs is very likely to generate (small-c) conservative resistance on emacs-devel= . 2.) There doesn't seem to be any real process for taking things off of their trial/pilot period. 3.) Developers seem most likely to fall into one of two buckets. Etiher my code changes, and thus I'm happier with it in ELPA than inside emacs core, or it doesn't, and there's basically no pressure for it not to just stay inside ELPA, especially since it'll need to stay inside ELPA anyway for older emacsen (and quite a lot of people are running older emacsen, for performance and maintenance reasons). These caveats combine to suggest very little benefit for moving code out of ELPA and into core. (In fact, I think e.g. Dmitry's preference for moving things into GNU ELPA is a natural expression of the same factors.) In the specific case of helpful.el: IIRC, it was brought up and immediately ran into the tangle of these things: some interest, some conservatism, some bikeshedding, and the realization that an ELPA package was defintely required and, in practice, pretty close to sufficient. For the future, my hope is that the recent interest in the user experience of emacs for people who aren't deeply embedded in years (decades) of custom and practice will result in more of these sorts of things getting included. I've also noticed that some recent changes to emacs have pushed way more people to upgrading emacs -- emacs 27's performance for code editing compared to using LSP & LSP-like systems seems to have pushed upgrades, as has the potential of testing native-comp. That's hopeful. ~Chad --000000000000bf281605a5e03086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, May 17, 2020 at 3:38 PM Yuan Fu &= lt;casouri@gmail.com> wrote:
> On May 17, 2020, at 3:42 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 17.05.2020 21:52, Stefan Kangas wrote:
>> Why are
>> the authors of "helpful.el" not helping us mainline some= of their great
>> innovation, for example?
>
> I think Wilfred worked on some patch or other, to upstream some of the= improvements. But not the whole of it.
>
> Maybe because it's a much bigger job: to port the code, to satisfy= all the historically accumulated edge cases, and to spend a few weeks argu= ing with whoever thinks the previous behavior was better at least in some r= espect.
>
> We don't really have a conceptual framework for assessing big brea= king changes.

I think it=E2=80=99s just much easier to write helpful.el from scratch than= read all the old code and understand it and try to patch it. I could have = patched package.el to make it fetch from github repos, but instead I just w= rote a quick small package to do that and moved on, which is much easier th= an reading and understanding package.el and convince people that such chang= e is necessary.

Extending this thought even= further, I think that there is a perception from people outside emacs-deve= l (and also some inside emacs-devel) that "big" changes are often= subjected to a "trial/pilot period" on GNU ELPA. This seems enti= rely reasonable, but there are some important extra caveats:

=
1.) Almost everything that makes substantial user-visible=C2=A0c= hanges in emacs is very likely to generate (small-c) conservative resistanc= e on emacs-devel.
2.) There doesn't seem to be any real proce= ss for taking things off of their trial/pilot period.
3.) Develop= ers seem most likely to fall into one of two buckets. Etiher=C2=A0my code c= hanges, and thus I'm happier with it in ELPA than inside emacs core, or= it doesn't, and there's basically no pressure for it not to just s= tay inside ELPA, especially since it'll need to stay inside ELPA anyway= for older emacsen (and quite a lot of people are running older emacsen, fo= r performance and maintenance reasons).

These cave= ats combine to suggest very little benefit for moving code out of ELPA and = into core. (In fact, I think e.g. Dmitry's preference for moving things= into GNU ELPA is a natural expression of the same=C2=A0 factors.)

In the specific case of helpful.el: IIRC, it was brought u= p and immediately ran into the tangle of these things: some interest, some = conservatism, some bikeshedding, and the realization that an ELPA package w= as defintely=C2=A0required and, in practice, pretty close to sufficient.=C2= =A0

For the future, my hope is that the recent int= erest in the user experience of emacs for people who aren't deeply embe= dded in years (decades) of custom and practice will result in more of these= sorts of things getting included. I've also noticed that some recent c= hanges to emacs have pushed way more people to upgrading emacs -- emacs 27&= #39;s performance for code editing compared to using LSP & LSP-like sys= tems seems to have pushed upgrades, as has the potential of testing native-= comp. That's hopeful.

=C2=A0~Chad
= =C2=A0
--000000000000bf281605a5e03086--