On 04/17/2014 11:37 PM, Eli Zaretskii wrote: >> 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; If EIEIO can't be preloaded (or, equivalent morally, autoloaded on find-file), there's no point in pursuing EDE improvements. An EIEIO-less EDE would be an EDE rewrite anyway. Plus, I don't think the problem space really warrants a complex object system: conventional elisp idioms are adequate. > starting from scratch (or almost from scratch) > sounds like waste of effort, especially since some of the EDE is > already in Emacs. I really don't want to start from scratch, but I think it's the best option. A project system is one of those systems for which the hard part isn't the coding, but agreeing on having a single interface to the code. I think we need something much simpler than what exists. > 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). There's no reason that a system like that couldn't be built on top of a minimal project architecture, or why you couldn't use EDE's current implementation. (I hope it's easy to see how EDE could plug into a more generic system.) > In any case, I don't see how unused > features could get in your way too much, unless their design is wrong. I find the abstractions in EDE to be much more confusing than they are useful. For something that, at its core, ought to be very simple, there are too many concepts --- target, project, sub-project, config, project placeholder, too much shared state, and too few opportunities for ad-hoc customization. The system feels specialized for a project based on nested autoconf files that build C and C++, and the documentation reflects that. I understand that EDE started simple and grew functionality, but this functionality belongs in separate layers, not mingled into the core.