From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add prettify symbols to python-mode Date: Wed, 23 Sep 2015 21:07:53 +0200 Organization: Linux Private Site Message-ID: <87vbb154za.fsf@Rainer.invalid> References: <1442777283-27514-1-git-send-email-mvoteiza@udel.edu> <20150921005306.GA29147@holos> <87h9mlwt6l.fsf@Rainer.invalid> <83bnctliay.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443035309 11131 80.91.229.3 (23 Sep 2015 19:08:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2015 19:08:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 23 21:08:19 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 1ZepOt-000617-Kh for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 21:08:19 +0200 Original-Received: from localhost ([::1]:50133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZepOt-0003dC-3c for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 15:08:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZepOk-0003Sr-W4 for emacs-devel@gnu.org; Wed, 23 Sep 2015 15:08:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZepOg-0008Uy-0f for emacs-devel@gnu.org; Wed, 23 Sep 2015 15:08:10 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:51407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZepOf-0008Uq-Oe for emacs-devel@gnu.org; Wed, 23 Sep 2015 15:08:05 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZepOd-0005k8-BI for emacs-devel@gnu.org; Wed, 23 Sep 2015 21:08:03 +0200 Original-Received: from p54b7e5f8.dip0.t-ipconnect.de ([84.183.229.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Sep 2015 21:08:03 +0200 Original-Received: from Stromeko by p54b7e5f8.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Sep 2015 21:08:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p54b7e5f8.dip0.t-ipconnect.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:IqjhmiZMxD5OTTwR4vhX/IqiqSU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:190303 Archived-At: 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, 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. 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. >> 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 it's all in ELPA anyway and already maintained from outside Emacs, then why should these be copied again in emacs.git? 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. > 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. > 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. 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). > 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds