From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: A unified project root interface Date: Sat, 23 Mar 2013 13:10:20 -0400 Message-ID: <514DE1FC.4020805@siege-engine.com> References: <20130309174419.6e1cadb4@forcix.kollektiv-hamburg.de> <5143C11D.8070705@siege-engine.com> <87sj3vv35h.fsf@engster.org> <20130316160203.6b889aba@forcix.kollektiv-hamburg.de> <87ehffuf1g.fsf@engster.org> <20130317001630.125e1987@forcix.kollektiv-hamburg.de> <87y5dmsz5u.fsf@engster.org> <20130317191817.764a44f5@forcix.kollektiv-hamburg.de> <87ppywtj9s.fsf@engster.org> <87li9juabi.fsf@engster.org> <87d2uvtdeb.fsf@engster.org> <874ng6tugb.fsf@engster.org> <87ppyurpxa.fsf@engster.org> <514A5A68.3070907@siege-engine.com> <87hak4af33.fsf@engster.org> <514BAA14.7060702@siege-engine.com> <87li9fyy6v.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1364058629 4606 80.91.229.3 (23 Mar 2013 17:10:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Mar 2013 17:10:29 +0000 (UTC) To: Stefan Monnier , John Yates , emacs-devel@gnu.org, Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 23 18:10:55 2013 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 1UJRy2-0007p1-5j for ged-emacs-devel@m.gmane.org; Sat, 23 Mar 2013 18:10:54 +0100 Original-Received: from localhost ([::1]:42723 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJRxe-0002sO-EZ for ged-emacs-devel@m.gmane.org; Sat, 23 Mar 2013 13:10:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJRxa-0002rZ-KX for emacs-devel@gnu.org; Sat, 23 Mar 2013 13:10:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJRxY-0006yQ-V6 for emacs-devel@gnu.org; Sat, 23 Mar 2013 13:10:26 -0400 Original-Received: from mail-ve0-f175.google.com ([209.85.128.175]:39777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJRxY-0006yF-QK for emacs-devel@gnu.org; Sat, 23 Mar 2013 13:10:24 -0400 Original-Received: by mail-ve0-f175.google.com with SMTP id pb11so1035211veb.20 for ; Sat, 23 Mar 2013 10:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qepmih/t6MSBilGHH6IVdpGBG9z7kLHKVlQpPQ1vX2c=; b=yp5Zf4wuDhyA2UQERx342tc248XNdgk5R35Z3hh9/Z+IxACOhrIIBf7Z0f+XhRPJn/ zjXLUIzo++mNV3hgSY44pN9cOpUdnIhPNZuK9kxZhtAyTclG5EFbaxOpM6Z/NN/jKYox +JkxfJXo9g3iFwLNPDfn65wffNAsvPG9a6tX/vfbhvooWIHvf3gJJ8PF+RkRB80YAh2X 4xVDyefqGamI1yMTTGbWrPLYpsnfUL/76Yd57Mqz0OApL0C3p7ddoo6m6Isfsqo0Q867 y8lt4pIv0VACe9vrJ6XmDOUk+3qQsxBNy6z7XyOxs7bSqD7+A3Yc+lK3yLh4zKLgPw0u 8u9Q== X-Received: by 10.220.223.202 with SMTP id il10mr8069371vcb.4.1364058623914; Sat, 23 Mar 2013 10:10:23 -0700 (PDT) Original-Received: from [192.168.1.201] (pool-72-74-140-235.bstnma.fios.verizon.net. [72.74.140.235]) by mx.google.com with ESMTPS id dz9sm9921807vdc.4.2013.03.23.10.10.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 10:10:22 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <87li9fyy6v.fsf@engster.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.128.175 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:158085 Archived-At: On 03/22/2013 04:30 PM, David Engster wrote: > Eric M. Ludlam writes: >> On 03/21/2013 12:32 PM, David Engster wrote: >>> And what would happen when `ede-check-for-vcs-dirs' returns t? Would >>> that load EDE then, or would we try to go on to provide the basic >>> functionality (like getting the root) with a class-less version? >> >> I think this will be a bit of a challenge. The project detection, and >> then project hash are the key important pieces. If the goal is to get >> something that will be dumped w/ Emacs, and Fast, we'd need to start >> by refactoring ede/files.el to split out the parts that track the >> directory-to-project associations from all the misc EDE related file >> finding routines. > > Frankly, I don't think this is the right approach. To cite from Jorgen's > initial post which started this whole thread: > > "The usual way to define a project is via the "project root", a > directory so that all files under that directory are considered part of > "the project"." > > As he also stresses, this is *not* a complex problem to solve, quite the > contrary. > > Therefore, I don't think it is necessary or even desirable to rewrite > the whole EDE project autodetection into a class-less version, which > then by all means tries to delay loading the "real" EDE as long as > possible. It is not necessary that an 'emacs -Q' can detect all kinds of > projects from Linux kernel trees to the Emacs source. If people need > this, they should just put 'global-ede-mode' in their init file (which > takes about 0.1 seconds on my machine) and use the full-fledged EDE. To be plain, I agree. What Jorgen described is not the EDE project loader. Here's the deal though. EDE's project loader was once what Jorgen described, without all the classes and stuff. It just detected the project, found the root, and moved on. Different projects need different features though, and things evolved. If a simple project system is put into Emacs core, it will satisfy the primary use case. Then over time the case+1 will evolve it until it is just as messy as the EDE one. Case: simple.el is 6000+ lines of code. Everything from set-variable (pretty simple) to compose-mail-other-frame (what ??). If this project concept is created as a simple thing, that's fine, but EDE won't be able to use it, though it could contribute. If that's the overall story where simple uses need the simple project, and EDE is used when you need more, that seems like a fine compromise, but it won't simplify the plethora of project projects. Of course, that's a good thing too. Eric