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: Project systems (again) Date: Fri, 18 Apr 2014 09:37:00 +0300 Message-ID: <83y4z3gn3n.fsf@gnu.org> References: <53504D2C.7070504@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1397803032 1024 80.91.229.3 (18 Apr 2014 06:37:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Apr 2014 06:37:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 18 08:37:05 2014 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 1Wb2Q3-0003ib-D1 for ged-emacs-devel@m.gmane.org; Fri, 18 Apr 2014 08:37:03 +0200 Original-Received: from localhost ([::1]:36557 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wb2Q2-0006wS-Op for ged-emacs-devel@m.gmane.org; Fri, 18 Apr 2014 02:37:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wb2Pu-0006vR-1l for emacs-devel@gnu.org; Fri, 18 Apr 2014 02:37:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wb2Pn-0007cJ-J7 for emacs-devel@gnu.org; Fri, 18 Apr 2014 02:36:54 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:39943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wb2Pn-0007bO-B0 for emacs-devel@gnu.org; Fri, 18 Apr 2014 02:36:47 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N4700700RE7U700@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 18 Apr 2014 09:36:45 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N47007NVRP8KA60@a-mtaout20.012.net.il>; Fri, 18 Apr 2014 09:36:45 +0300 (IDT) In-reply-to: <53504D2C.7070504@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:171481 Archived-At: > Date: Thu, 17 Apr 2014 14:52:44 -0700 > From: Daniel Colascione > > I'd like to include a good, minimal "project system" in Emacs 24.5 and > turn it on by default. IMO, this would be a very good progress, thanks. > EDE already provides some of the functionality I've described above, but > I don't like the way it does it. It's very complicated and embeds > uncommon features into the core. EDE's reliance on EIEIO and its large > feature-set create difficulties dumping the system with Emacs. And have > you tried actually creating a new EDE project type? It's surprisingly > and disappointingly difficult. Ad-hoc extensibility with EDE is hard > because of its EIEIO use, and I don't think EIEIO is buying us anything, > really. > > EDE also includes many features that are not generally useful (like > makefile generation) and that complicate the codebase. EDE being > developed out-of-tree makes it hard to fix these issues. I'd rather have > a minimal and more idiomatically Emacs-ish core facility that EDE can > build on. EDE is also not currently integrated with VC, and it doesn't > provide nice user interfaces (ede-find-file, for example, doesn't do > completion.) FWIW, I'd prefer that you work with EDE developers to improve and extend what they have; starting from scratch (or almost from scratch) sounds like waste of effort, especially since some of the EDE is already in Emacs. I find the Makefile generation feature useful (e.g., when you need to develop on one platform, then build the same code and run it on another, where the full development environment is not necessarily installed). In any case, I don't see how unused features could get in your way too much, unless their design is wrong.