> On May 17, 2020, at 3:42 PM, Dmitry Gutov <address@hidden> 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