Re: Adding use-package to core

[Eli Zaretskii]

> Date: Tue, 15 Nov 2022 16:38:10 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org
> 
> > 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.
> 
> The problem is, more capable and powerful _compared to what?_

Compared to what we did yesterday and to what our users want or may
want us to do tomorrow.  For the latter, we keep tabs on other similar
editors and on technological developments, and consider their use in
Emacs.

> I use Emacs because I like it, not because it actually solves some
> programming problems faster.  I am aware how it actually does many
> things better after investment and when programming is your lifestyle,
> but for most it is only a task.  Note that having to invest is not an
> advantage or accomplishment, other programmable editors come very
> close to Emacs if you program the hell out of them too.

We develop Emacs for those who like it and want to use it, regardless
of their reasons.  Why people like Emacs and use it is not relevant to
this discussion, because no matter what we do, we cannot change the
basic facets and look-and-feel of Emacs and its usage.  Whoever likes
it, for whatever reasons, will keep liking it, and those who don't
will only rarely change their minds.

> > 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.
> 
> Is it though?  Vim's Bram Moolenaar seems to manage it, not to mention
> how GNU Emacs came to be; there are many more impressive software out
> there with this singular dedicated developer.

I don't know how Vim compares to Emacs from the technological POV, I
don't have time to study Vim that thoroughly.  Maybe Vim is less
complex and implements fewer technologies by itself, maybe the Vim
developer is much more talented and/or has more time than we do, maybe
something else.  One thing is sure: with Emacs, with the kind of core
developers we get for the past 30 years, this didn't happen even once,
and so I consider it impractical to hope that it can be done.  And
rational project management doesn't build on hopes for miracles.

> Aiming for a single person is indeed too bold, reducing this number
> to a few on the other hand almost feels like a low hanging fruit.

Once you have 2 or three people, it doesn't matter how many they are:
you need to discuss changes that span more than one area (and almost
all of them do), you need to be able to do forensics on code for which
you have no experts on board, etc.  This is where we are, and no
reasonable downscaling will ever be able to change that.

> my impression is that you underestimate the benefits a less complex
> project will bring

On what is that impression based?

It goes without saying that a significantly smaller project could be
easier to manage, but the important question is: how much smaller can
we make Emacs before it ceases being Emacs?  And my answer to that is
"not much".  Just review all the Lisp packages that currently see a
lot of commits, and you will arrive at the same conclusion: they are
all important.  (Packages that don't see changes aren't contributing
to difficulties in maintenance.)

> I actually agree on this mostly, what I try to suggest is to narrowing
> the scope of these applications, which must be maintained by
> emacs-devel.

It cannot be done.  If you narrow the scope, you lose the motivation
for development.  More importantly, you will begin losing
contributors, most of which are only interested in application levels,
and that is the slippery slope to death, because contributors are the
source of future Emacs developers and maintainers.

> Bidirectional editing, advanced support for programming languages
> etc. these are all great and must have features.  If something isn't
> needed by almost every programmer or writer, package it; this seems
> like a good rule of thumb?

We already make decisions based on our gut feeling what is and what
isn't important.  So if you agree with that in general, what is left
is differences in judgment calls, and those can never be usefully
argued about, because they are basically subjective.

And our experience is that the decision "what is needed by every
programmer or writer" is very non-trivial.  Emacs is so vast and
people's interests and needs are so diverse that one person's main
package in Emacs could be almost useless to someone else.  E.g., there
are people who will say that they use Emacs only because it has Org,
and others who don't use Org at all, but cannot imagine their lives
without VC or Tramp or Dired.

> I do not understand what live-ness or dead-ness mean for Emacs' case,
> as long as FSF and its support lives.

Death means slowdown of development rate, stagnation, loss of users
due to lack of maintenance, and then the project goes dark.  Cf
XEmacs.

> My overall argument here is to demonstrates why I think emacs-devel's
> methods are not as effective as they think, and should be more open to
> different approaches.  Being in this state of being immortal (or
> arguably already dead) gives you unique opportunities to be more
> experimental I think.

We do experiment, only somewhat cautiously.  This isn't an educational
student project; we have a lot of users who don't want us to make
fatal mistakes.  That's a huge responsibility.

> IIUC the vision is having as many features (that mostly work) as
> possible, instead of few superb ones.

But that's not the vision.  The vision is to have as many features we
_need_to_have_in_core_ as possible.  That's a tautological definition,
of course, like every good definition is ("GNU's not Unix" and all
that), which again brings us to the crucial point: it's a judgment
call what to include and what not to include, which technology to
adopt and which not.  That's a very large portion of what Emacs
maintenance is all about, day in and day out.