Re: "Write a new package" culture instead of patches?

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3176 bytes --]

On Sun, May 17, 2020 at 3:38 PM Yuan Fu <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 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’s 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
> 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

[-- Attachment #2: Type: text/html, Size: 3803 bytes --]