Re: Adding use-package to core

[xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>]

Nov 14, 2022, 10:47 by luangruo@yahoo.com:
> xenodasein@tutanota.de writes:
> > Something changes or it doesn't, I have no clue what you mean.
>
> Most changes break nothing.
>
> > Anyway, 'statistics' in my head formed after looking through lisp files,
> > how many of them there, and the fact that how few people are maintaining
> > these, anyone can see this thanks to git.
>
> I don't see that. What I see instead is the same as with any other
> mature, well-established software: most of our code is finished and does
> not require constant changes.

Practically all the programming languages or programs we support keep
evolving yet our code is finished?  Surely you can see how this
contradicts the whole point of software lifecycle wisdom?

> > Problem is over time commits to core packages keep making assumptions
> > about each other's existence and that inter-dependency does not seem
> > to encourage anyone to work on them, even their original writers.
>
> Any specific examples?

The example is the commit history, and the number of people rushing in
to help maintain old Emacs code they didn't originally write.

> Anyway, once a package is included with Emacs, and its minimum Emacs
> requirement also bumped, it is fine for it to rely on the rest of Emacs
> being present. But if its maintainer decides to support older versions
> of Emacs as well, then everyone else does not interfere. See TRAMP for
> an example of one such package.

Crucial point here being Michael A. actually does the hard work and
TRAMP is not one of the orphans.

> > Even you are in your own X corner and not touching that issue, except
> > for nay-saying on this list.
>
> It might not seem like it, but I have a job to keep me busy, and the
> amount of time I can spend on Emacs is quite limited.

That is why keeping the core as simple and easy to maintain as possible
is very important.

> Add to that the fact that Emacs 29 is about to be released, and the
> major changes to the GUI code in it have inevitably led to regressions
> that have to be ironed out, and you will see why most of my changes in
> the past two months have been limited to minor refactorings and bug
> fixes. That approach seems to have paid off. For example, it has led
> to bugs that have lain unfound for almost 30 years being fixed (see for
> example 25c6bc7a3.)

Your fixes are numerous and very helpful, thanks a lot.

> > Yeah? Who he is going to put in the cold hard work hours into
> >  maintaining all that?
>
> Presumably whoever wrote the package and has *asked* us to include it
> into Emacs.

My whole complaint is that this is not happening, so the trend here
should be reducing lines of code, but opposite is happening.  This
not a good direction.

> > Furthermore after certain complexity it is of no help even having
> > numerous developers.
> > [...]
> > These are well documented and understood facts of software development
> > and when someone keeps denying these things without substantial
> > argument it displays blatant incompetence.
>
> So by changing the repository in which some code is placed, other code
> is made more complex? By what, magic?

By their interdependence increasing over time.  All code being in the
same place and the nature of free software without strict rules, seem to
lead to this result, I believe it is easy to observe from Emacs source.

Quoting from some other mail I've sense to list:
"Same reason emacs-devel is not responsible for every single line of
Elisp code on the Internet?  External packages seem to get more love
from their developers.  If not, something new replaces them, people
migrate, and nobody complains to Emacs bug list about it."

> > I don't see how bundling millions of lines of code together when there
> > is already a system to distribute these as external packages is a
> > shortcut to usefulness for everyone (what does that even mean?)
>
> You cannot seriously claim it is easier to run several commands to
> unpack and install a package in the ELPA directory than to do nothing at
> all.

Technically it is not easier but also how much harder it is to install
them is so minuscule that the maintenance burden it causes it is not
worth it.  All that effort is better spent improving Elisp, minibuffer,
simple, cc-mode... i.e. "the good parts" and let convenience projects
get externally maintained.