Re: Adding use-package to core

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

This is a real answer, I thank you for it.  FWIW, no one can claim
that you are not meticulous in your community management.  It is a
tiresome and hard task rarely done well.


Nov 14, 2022, 17:39 by eliz@gnu.org:

>> 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.
>

The problem is, more capable and powerful _compared to what?_
Comparing yourself against only yourself of yesterday is a great maxim
to have, in line with an ideal world and FSF ideals.  The reality is
that almost everyone using a different editor/ide do not actually hate
Emacs and would use it instead of Electron bloatware _if_ it solved
their problems faster, which it does, seen from how things are and my
experience is also supportive of this.  We are a practical species if
nothing else.

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.

From this perspective Emacs doesn't accomplish to actually be the
better editor overall, if we compare ourselves to others.  For example
Vim's advantages in quick remote editing or availability.  That
availability is also an accomplishment over Emacs, despite it being
the GNU editor.  I agree popularity is not always a great thing to
have and most times does not bring good things to its way.  Ideally
Emacs would be both demonstrably better yet still niche and we could
revel in our l33t productivity, without others rushing in to have some
:).


>> 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.
>

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.  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.  Not every contributor has
to be in the top echelon of course, my impression is that you
underestimate the benefits a less complex project will bring and
instead decide it better for the users when there is more stuff all
together.  (I believe it is a correct assumption given you make it in
a time what Internet is not as ubiquitous as today.  Even then there
could be bigger alternative distributions that include optional
packages, mainly for less lucky parts of the Earth.)


> 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.
>

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.  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?

(I guess from the timing I sounded like I am strongly against
inclusion of use-package, but this is not the case, this was more of a
general complaint.  I am somewhat against use-package because I think
it is a band-aid over the shortcomings of existing customization
facilities, but maybe Emacs should turn towards use-package style
customization I don't know.)


> 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.
>

I do not understand what live-ness or dead-ness mean for Emacs' case,
as long as FSF and its support lives.  Because no matter what a lot of
people including me will keep using it because of its aesthetics,
community, the way it works etc.  This is indeed a great
accomplishment by itself, it is nightmarish to imagine where Emacs was
not an existing (viable) alternative.

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.

IIUC the vision is having as many features (that mostly work) as
possible, instead of few superb ones.  Doing the opposite granted Vim
"the editor wars," giving an order of magnitude larger user base and
widespread availability.