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: Fri, 15 Mar 2013 20:47:25 -0400 Message-ID: <5143C11D.8070705@siege-engine.com> References: <20130309174419.6e1cadb4@forcix.kollektiv-hamburg.de> <87hakh2299.fsf@fimbulvetr.bsc.es> <513FBA1C.5040100@siege-engine.com> <87vc8vyy66.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: 8bit X-Trace: ger.gmane.org 1363394853 6405 80.91.229.3 (16 Mar 2013 00:47:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Mar 2013 00:47:33 +0000 (UTC) To: emacs-devel@gnu.org, David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 16 01:47:59 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 1UGfHy-0002mz-B9 for ged-emacs-devel@m.gmane.org; Sat, 16 Mar 2013 01:47:58 +0100 Original-Received: from localhost ([::1]:36996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGfHb-0002ek-Gr for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2013 20:47:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGfHX-0002ec-6Q for emacs-devel@gnu.org; Fri, 15 Mar 2013 20:47:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGfHV-0007EM-U8 for emacs-devel@gnu.org; Fri, 15 Mar 2013 20:47:31 -0400 Original-Received: from mail-ob0-x232.google.com ([2607:f8b0:4003:c01::232]:61126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGfHV-0007EF-Op for emacs-devel@gnu.org; Fri, 15 Mar 2013 20:47:29 -0400 Original-Received: by mail-ob0-f178.google.com with SMTP id wd20so3824366obb.37 for ; Fri, 15 Mar 2013 17:47:29 -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=hpQXYRzNZzrRM8TmAXc2HjAnmVPJvMIcfI9yA0vAp7k=; b=QiEovKu1lJ2ZVjzBEzWbjY6aBpEE86QwUF2GO4hC7bwR84SWKICQ0k6AP1gIWzhDfq P5/0grSqzT41k9fLKXdEURh8xPOmRfIuW/MzEZGUi7ARQBfhaN/Kx2s6EDKghlFjJkjt SvjfCCWwL903/jZxVtlUb7HLGK0K7b/Gph77uw2GD7J2j38fgYIXxOgEEm7knqmRjps9 2HenOxM/SZJie23lp9vZYmTEjlpEdBep499/CCqDTrzCTCnWUku5Mliza+YxsIW5Nvuf yv4yERrXj5VNyVJbABoVP5DN8qkKWiqxZU4JFwE+Czt1dKXohpQWEDnVLPw7IOUZyZGW y4Rg== X-Received: by 10.60.29.129 with SMTP id k1mr3995936oeh.8.1363394848863; Fri, 15 Mar 2013 17:47:28 -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 v8sm4691317oea.4.2013.03.15.17.47.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 17:47:27 -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: <87vc8vyy66.fsf@engster.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::232 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:157896 Archived-At: On 03/13/2013 02:03 PM, David Engster wrote: > Eric M. Ludlam writes: >> On 03/11/2013 02:57 PM, Lluís wrote: >>> CEDET provides this in two ways (as part of the EDE subsystem): >>> >>> * If a Project.ede file exists, that's the root (similar to .dir-locals.el in >>> this context) >>> >>> * If signs of a "project-like" structure exist (e.g., (auto)makefiles, scons, >>> java, etc), uses system-specific knowledge to automatically >>> detect the project >>> root. >>> I'm commenting this because, first, managing projects is the purpose of EDE >>> (although it tries to do more than just identifying their root) and it's >>> integrated in Emacs; and second, because the auto-detection could help in making >>> the process simpler and, in the best case, auto-magical. >> >> I, of course, agree with Lluis. EDE is already setup to automatically >> find projects as was requested. Adding new projects through the >> generic' system is a pretty simple prospect. > > Yes, but we cannot envision all the kinds of projects people would want > and create those for them beforehand. And defining own projects with > ede-generic is simple, but not simple enough for end users. Let's take > the example for defining those simple projects in project-roots.el, > given by Sudish Joseph in this thread: > > ("Perl Project" > :root-contains-files ("t" "lib") > :on-hit (lambda (p) (message (car p)))) > > You can create a project like this with ede-generic, but then you have > to write a little defclass inheriting from ede-generic, call > ede-generic-new-autoloader, and to actually *do* something when the > project is loaded you have to define methods like > `ede-generic-setup-configuration'. This is just too much boilerplate for > such a simple thing like the above. Also, even most Emacs developers are > not familiar with the CLOS-like syntax that's needed to define those > things. > > There's no doubt that EDE can do all what's needed, but is has to be > wrapped in something that's easier to use, at least for simple stuff > like what project-roots.el does. Ok, I can buy that. EDE was never simple. I just know that if an "official" project mechanism is built, I'll have some work to do. ;) In particular, if a system for detecting projects is developed, it would be great if EDE could stop detecting projects (ie - I delete some code), and instead use a hook to say "hey, let me know if you found a project", after which it can do its bit of magic for projects it also knows about. Also be aware that I ran into a lot of performance issues I had to work through with EDE project detection. Once other code starts asking where it is in a project, it's amazing how often that stuff gets called. A project cache is a super handy thing, and was one of the key performance improvements I made back when i was trying to speed up smart completion. Eric