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 22:42:58 +0300 Message-ID: <83h9mkkjlp.fsf@gnu.org> References: <1442777283-27514-1-git-send-email-mvoteiza@udel.edu> <20150921005306.GA29147@holos> <87h9mlwt6l.fsf@Rainer.invalid> <83bnctliay.fsf@gnu.org> <87vbb154za.fsf@Rainer.invalid> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443037404 12149 80.91.229.3 (23 Sep 2015 19:43:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2015 19:43:24 +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 21:43:15 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 1Zepwh-0002NQ-A4 for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 21:43:15 +0200 Original-Received: from localhost ([::1]:50309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zepwb-0002fH-LG for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 15:43:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZepwW-0002cc-Cr for emacs-devel@gnu.org; Wed, 23 Sep 2015 15:43:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZepwR-0001o2-VA for emacs-devel@gnu.org; Wed, 23 Sep 2015 15:43:04 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:37237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZepwR-0001nn-IW for emacs-devel@gnu.org; Wed, 23 Sep 2015 15:42:59 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NV500700AHJ6R00@mtaout29.012.net.il> for emacs-devel@gnu.org; Wed, 23 Sep 2015 22:43:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV5007S8ASRLH00@mtaout29.012.net.il>; Wed, 23 Sep 2015 22:43:39 +0300 (IDT) In-reply-to: <87vbb154za.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.185 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:190307 Archived-At: > From: Achim Gratz > 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?