Re: Adding use-package to core

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 14 Nov 2022 15:47:43 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> 
> > You are entitled to your opinions, but we disagree, and we have many
> > years of experience to present as evidence.
> >
> > Given such stark differences of assumptions, opinions, and experience
> > in Emacs development, I see no reason to keep arguing about this.
> 
> Experience in accomplishing what exactly?  How can I examine this
> evidence?  I don't know what are your goals, is going down from 5%
> percent to 4% on StackOverflow's survey this year is one of them?

The overall goal is, and always has been, to make Emacs more powerful,
more capable of supporting text-editing and text-processing
applications in more and more areas where people need such
capabilities and applications.  Examine the NEWS files over the last
20 years and ask yourself if that is not happening with every new
major release.

As for the evidence, it's right before your eyes: show me another
similar platform that lived for so many years, and after all these
years still gets developed at the same, if not higher, rate.  What
other evidence do you need?  5000 commits each year for the past 20
years cannot just come from a small band of like-thinking weirdos who
are detached from their users.

> I really want to see this story of success, but wherever I look
> that has numbers tells that you can't compare numbers even with
> Notepad++.

We develop Emacs for those who want and need to use it.  What matters
to us is not the percentage of our users between editors and IDEs,
what matters is where our users want us to advance, and which new
technologies will allow us to provide them with new and improved
capabilities, infrastructure, and applications.

> I find it hard to understand how leaving whoever comes after you an
> even bigger Emacs despite having said currently no one understands
> all parts of it.

No matter how small we make Emacs, no one will ever be able to
understand all of it.  It spans and uses too many too wide areas of
computer processing technologies for any single person to be able to
understand it.  Apart of the "usual" CS stuff, we have Unicode and
character properties, GUI and TTY display, text shaping, font
selection, image processing and display, Lisp and its compilation,
file I/O, regular expressions, and that's just a sample.  Who could
possible be an expert in all of that?

So this is a red herring.

As for "even bigger Emacs" part -- if you really believe Emacs can be
divided into core and the rest, I think you don't understand the
spirit and the heart of Emacs and its development.  (Which I can
totally feel for, since it takes a lot of time and personal
involvement to really grasp that.)  See, separating the Emacs core
from applications built on that core makes no sense, and if you try,
you will most probably kill Emacs.  If you examine carefully every
significant development in the Emacs core, you will see that each and
every one of them was always about some application or class of
applications.  Take the recent addition of tree-sitter, for example:
it would make no sense to develop that if font-lock for many
programming languages was not in core, because who in their right mind
would do all that hard work if it couldn't be immediately applied to
existing applications that are part of Emacs, and do it Right, using
all the expertise of "doing it Right" we have on board?

You should arrive at the same conclusion if you examine carefully
"core" Lisp packages, like subr.el, simple.el, etc. -- every single
part of them is there because we needed it for some application in
Emacs itself.  How could that happen if the applications were outside
of Emacs?  It is a fact that developers of 3rd-party applications tend
to solve the problem by themselves, almost never asking us to provide
new core features to help them solve those problems.  If most of Emacs
applications were outside the project, we could never have progressed
and extended our basic capabilities and infrastructure as we have them
now.

This intimate bond between the internals and the core infrastructure
on the one hand, and the applications that are built on top of that
OTOH -- this is our main strength, it's what keeps drawing in new core
developers over the years, thus keeping the project alive and kicking,
and developing at a mind-blowing rate.

And yes, this presents a problem: where do we draw the line, how do we
avoid making Emacs "too big" by adding "everything"?  Well, that's
what takes experience and intuition and gut feeling -- and a lot of
arguments like this one.  But by and large, we succeed, as the state
of Emacs today should tell us.

Whatever the difficulties to make the decision in each case, the
opinion that we should generally go in the opposite direction,
i.e. progressively remove more and more application-level code from
Emacs -- that opinion is completely wrong.  IMNSHO, anyway.