Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: Achim Gratz <address@hidden>
> Date: Wed, 23 Sep 2015 21:07:53 +0200
> 
> Eli Zaretskii writes:
> >> This is good, but I can't help thinking that the other way around would
> >> have been infinitely more useful.
> >
> > Useful for whom, may I ask?
> 
> Users who want to have more control over which packages and versions
> they use

They have that control now.  No package will start itself, unless the
user invokes it.

> system administrators that need to deal with multiple versions
> of Emacs on the same system or across a bunch of systems and packagers
> of distribution packets.

This is just going to be far more complex if we off-load large
portions of Emacs to elsewhere: there will be more combinations of
different versions to consider and support.

> Last but not least the very maintainers of said packages who will be
> relieved from the burden of keeping their packages in sync with
> Emacs both ways.

That burden is what allows users to be sure their packages will work
with future versions of Emacs.  Take that away, and the QA problem I
was talking about will rear its head.

> >> In other words, emacs.git wouldn't contain any other eLisp than what
> >> it needs to bootstrap and pulling in everything else as a proper
> >> ELPA package while building.
> >
> > It would be a nightmare for a small team of maintainers to keep such a
> > package in even an approximately good shape, QA-wise.  We currently
> > don't have enough manpower even for such a basic thing as timely
> > review of patches proposed by occasional contributors; how will we
> > ever be able to make sure hundreds of separately developed packages
> > could ever work together when pulled?
> 
> It works by specifying the exact Git revisions (or tags) that are paired
> up with that Emacs release (and these packages would be in the tarball
> so no extra download happens when building from those).

If we are going to tie specific versions to specific Emacs releases,
then what is this all about?  Why all the overhead?  What do we gain?

> If you look around you'll find that quite a few other projects are doing
> very similar things.  For instance, Perl bundles certain CPAN modules.
> Yes, there's a constant discussion of what should be pure CPAN, what
> should be "dual-life" modules and what should be purely core.

Yes, and whenever I need to install some package from CPAN, I end up
installing dozens of its dependencies first.  Do we really want that
for Emacs users?  I don't.

> > One of the gravest problems I see for the future of Emacs development
> > is that we slowly but steadily lose old-timers who know a lot about
> > the Emacs internals and have lots of experience hacking them, whereas
> > the (welcome) newcomers mostly prefer working on application-level
> > code in Lisp.  If this tendency continues, we will soon lose the
> > ability to make deep infrastructure changes, i.e. will be unable to
> > add new features that need non-trivial changes on the C level.
> 
> That's an entirely different discussion, and one that I do not intend to
> address in this thread.

That is the slippery slope I don't want us to take.  Not even the
first step.

> > Moving most Lisp packages out of the core will give a tremendous boost
> > to this slippery slope, by even further detaching many contributors
> > from the core and segregating the core's ever dwindling bunch.  That
> > way lies stagnation and death.
> 
> I don't see how what I proposed would even remotely cause that.

I tried to explain how.

> The same people would develop the eLisp packages in the same way
> they are doing it today and for each Emacs release the Emacs devs
> can chose which version of those packages gets bundled.  If Emacs QA
> finds out there are bugs to fix you can adress it to the package
> maintainers in the same way as today (just the commits go to a
> different repository).

Packages that are not in core get much less attention from the core
maintainers.  It starts with the fact that I don't see them compiling
on my machine each time I build Emacs, so any warnings I might have
seen and taken care of, if only be letting the maintainer know, will
be lost for me.  It goes on with me not watching commits to ELPA
packages, so I don't have a chance of timely catching problematic
code.  Etc. etc. -- the Emacs QA doesn't cover unbundled packages.

> > Please don't even think about suggesting this, unless you plan to come
> > on board and become a very active member of the core team, responsible
> > for these aspects specifically.
> 
> No offense taken, but you can't be serious about telling me what to
> think or what I can say or not under whichever conditions.

I'm not telling you anything -- that "please" was there for a reason.
And how's that different from your suggestion, anyway?  If you can
tell us that "the other way around would have been infinitely more
useful", why cannot I tell you what I did?