From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add prettify symbols to python-mode Date: Wed, 23 Sep 2015 10:13:25 +0300 Message-ID: <83bnctliay.fsf@gnu.org> References: <1442777283-27514-1-git-send-email-mvoteiza@udel.edu> <20150921005306.GA29147@holos> <87h9mlwt6l.fsf@Rainer.invalid> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1442992417 26521 80.91.229.3 (23 Sep 2015 07:13:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2015 07:13:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 23 09:13:28 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZeeF3-0007Gf-Tq for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 09:13:26 +0200 Original-Received: from localhost ([::1]:45867 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeeEy-0000AC-8v for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 03:13:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeeEv-00009q-5u for emacs-devel@gnu.org; Wed, 23 Sep 2015 03:13:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeeEr-0002cq-V8 for emacs-devel@gnu.org; Wed, 23 Sep 2015 03:13:17 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:58402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeeEr-0002at-I4 for emacs-devel@gnu.org; Wed, 23 Sep 2015 03:13:13 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NV400100BILDE00@mtaout25.012.net.il> for emacs-devel@gnu.org; Wed, 23 Sep 2015 10:10:15 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV400HULBX3ZN80@mtaout25.012.net.il>; Wed, 23 Sep 2015 10:10:15 +0300 (IDT) In-reply-to: <87h9mlwt6l.fsf@Rainer.invalid> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190271 Archived-At: > From: Achim Gratz > Date: Wed, 23 Sep 2015 08:22:58 +0200 > > Stefan Monnier writes: > > It is. Python.el's maintainer has worked on the elpa scripts so that > > GNU ELPA packages can be built directly from the emacs.git source code. > > This way packages like python.el and seq.el which want to be bundled > > with Emacs as well as distributed via GNU ELPA can do so without having > > to duplicate them between elpa.git and emacs.git. > > 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? > 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? 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. 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. 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.