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: Thu, 21 Mar 2013 20:47:16 -0400 Message-ID: <514BAA14.7060702@siege-engine.com> References: <20130309174419.6e1cadb4@forcix.kollektiv-hamburg.de> <513FBA1C.5040100@siege-engine.com> <87vc8vyy66.fsf@engster.org> <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> 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 1363913253 30768 80.91.229.3 (22 Mar 2013 00:47:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Mar 2013 00:47:33 +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 Fri Mar 22 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 1UIq9F-0006RQ-LX for ged-emacs-devel@m.gmane.org; Fri, 22 Mar 2013 01:47:57 +0100 Original-Received: from localhost ([::1]:45652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIq8r-0005H0-NM for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2013 20:47:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIq8i-0005Fl-VY for emacs-devel@gnu.org; Thu, 21 Mar 2013 20:47:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIq8d-0002Jb-Tp for emacs-devel@gnu.org; Thu, 21 Mar 2013 20:47:24 -0400 Original-Received: from mail-vc0-f171.google.com ([209.85.220.171]:38848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIq8d-0002JV-Og for emacs-devel@gnu.org; Thu, 21 Mar 2013 20:47:19 -0400 Original-Received: by mail-vc0-f171.google.com with SMTP id ha11so2868200vcb.30 for ; Thu, 21 Mar 2013 17:47:19 -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=CA3QMBum7v9CfK8eDQ3dRybVvGJI4bmAdB06AzPMDeM=; b=YmeqhoV6XAMX1CHCeF9ObPf/UbGw6BFwNlGs42zlIB1dh0+R7MAOARoKFGLtdKfssO tPD10wMp8zTkA5kOcrHfLt4bMLmfJfiMLm+IJMbt9n65h8XK7BvXWsB2HfnG60GupRsI t7u9++iCHoJ6IwQbXX7Dde6wBds/AVrN+RpZfJA5irteimvm5kJ5/rSXRhA5SsUtsrSa 9f+2mw/qXAfH4PMy82M3F7g3KSFrYRXhf4cM12B/4pDekjqvaLYw5+TDWnwyvZhcNkGl FvmZbvMS4BA2lskWFZoa+0RIu0wt4JKINEjC93g/mymklWWAKsTBoxG5aZNh2LJksraN +5Qg== X-Received: by 10.52.20.144 with SMTP id n16mr5335772vde.15.1363913239297; Thu, 21 Mar 2013 17:47:19 -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 dz9sm377871vdc.4.2013.03.21.17.47.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 17:47:18 -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: <87hak4af33.fsf@engster.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.171 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:158046 Archived-At: On 03/21/2013 12:32 PM, David Engster wrote: > Eric M. Ludlam writes: > W> On 03/20/2013 01:47 PM, Stefan Monnier wrote: >>> Sorry, I mostly meant "split eieio.el". What parts? Well, that's >>> a good question. I think if I knew, I'd have done that already ;-) >>> Maybe a first split would be "all the code in eieio.el up until the end >>> of the first big eval-and-compile". >>> At least, if the aim is to get rid of those nasty eval-and-compile. >> >> This email, and browsing in eieio.el in the CEDET repository gave me >> an a-ha moment. I think I know how to "split" eieio such that the >> eval-and-compile elements are fixed, and have a much nicer eieio.el in >> the process. My initial experiments show I'm on the right track. >> >> David, is there something that needs merging from Emacs to CEDET I >> need to worry about before making massive structural changes in EIEIO? > > No, it's all already merged to upstream, including the renames by > Stefan. Great! Thanks. >> If the goal is to use EDE's detection scheme and data, but not load >> EDE project classes, then we are all set already since the EDE project >> classes are not directly involved in detecting the projects. If the >> goal is to not use EIEIO at all, then we'd end up just using a plist >> other random data structure instead of using EIEIO to do it. This >> wouldn't be a big deal because AFAIK, these classes aren't subclassed, >> so impact would be small. > > Let's talk examples, then. Say we have > > (ede-project-autoload "vcs-root" > :name "VCS ROOT" > :file 'vcs-root > :proj-file 'ede-check-for-vcs-dirs > :proj-root 'ede-vcs-root-dir > :proj-root-dirmatch "NONE" > :class-sym 'ede-vcs-root-project > :load-type 'ede-vcs-root-load > :new-p nil > :safe-p t) > > So from that we'd take the list of slots, which is practically a plist, > and would write something akin to ede-dir-to-projectfile, but using > plist-get/set instead of oref/oset? Yes, basically. Seems odd to swap one data type form for another, but there it is. Since the class name is used as a function, no code using it will need to change. Perhaps. > 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. Once that is working, I had originally thought we could use the ede-project-placeholder as a starting point since it was designed to be swapped out for a real project later, but that is still an EIEIO class. Instead, probably another small list left as a buffer-local variable that can be tracked. I imagine it would hold the root of the project, and some misc :key describing the nature of the matched project. That would be used instead of ede-object for quick project detection. I think it would also need a couple new hooks, including ede-new-project-detected-hook. EDE would use that to actually load a project instead of doing so directly from the auto-loader. Another option is to hand-craft an EIEIO object vector. They are all just vectors, so if we had an EIEIO class that had a small number of slots (smaller than the existing placeholder object) it could be created by hand with (vector ... ) and used to track projects. Once EIEIO was loaded, more complex code could just keep using it, but as an object. I wouldn't do that if there were more than 2 or 3 slots in it though. As code changed, the indices might change, and maintenance would be a pain. As for a transition strategy though, it might make things easier. As for ede-check-for-vcs-dirs, it would need to provide data to the auto-loader that doesn't need to be called to detect the project. There is a bit of logic that says "If the :file isn't loaded yet, try this other thing". That way if it is loaded, it can use one of the handy functions which often have caches of their own for detection and makes things faster. On the flip side, perhaps this is an opportunity to simplify. There is a bunch of historical baggage in the loader. I'll bet there are some options that could be fixed/removed, simplifying the whole thing. Anyway, the key is that the autoloader could be recycled into something EIEIO free, and a simple hook would give EDE what it needs to keep going, without it's current custom autoloader, and it might be possible to keep old registration fcns working in the process. Eric