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: Wed, 20 Mar 2013 20:55:04 -0400 Message-ID: <514A5A68.3070907@siege-engine.com> References: <20130309174419.6e1cadb4@forcix.kollektiv-hamburg.de> <87hakh2299.fsf@fimbulvetr.bsc.es> <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> 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 1363827313 18885 80.91.229.3 (21 Mar 2013 00:55:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Mar 2013 00:55:13 +0000 (UTC) Cc: emacs-devel@gnu.org, Jorgen Schaefer , David Engster , John Yates To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 21 01:55:38 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 1UITn8-0001dQ-EE for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2013 01:55:38 +0100 Original-Received: from localhost ([::1]:48727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UITml-0008Ro-Al for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2013 20:55:15 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UITmh-0008RZ-Ou for emacs-devel@gnu.org; Wed, 20 Mar 2013 20:55:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UITme-00086w-Q6 for emacs-devel@gnu.org; Wed, 20 Mar 2013 20:55:11 -0400 Original-Received: from mail-vb0-x22b.google.com ([2607:f8b0:400c:c02::22b]:34985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UITme-00086Y-Kb for emacs-devel@gnu.org; Wed, 20 Mar 2013 20:55:08 -0400 Original-Received: by mail-vb0-f43.google.com with SMTP id fs19so1571129vbb.30 for ; Wed, 20 Mar 2013 17:55:07 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rg03rdlw5TMX9SkPp/REOTmbFByC+mlse5OYu5RYKuo=; b=EXEtqyB3C98WpDsI+YG7dyfUge6ILCR5Vu4QRl9lXBh4a6iTEW3f8jdLlv4F6TFM6k A+CjHvtaT1bn6VYEHUyw2HoYw4OPC/HUvaydzCqmyym4Uz8mdC48KHQin48Htlo+T12a sN1BfOVbRsAQgfSj2CIL3fJyhRHpN3RHCKzSU4IvqGjSPaxDn+0BmkDHPpo1xdX+lYvm D68S6n08O+bRmav3E+d3sLlbKxxTAfVxeN4ennJnq0bDTPpQGW1bpXL342gtSldPVTzB vOCG7aD2L02UmJ8jmZ8OX7jrhpCHUNSiJu7JyunnB79+VfMFr+wZFwUK086PwOaefLhl Xlnw== X-Received: by 10.220.119.147 with SMTP id z19mr10862803vcq.69.1363827307362; Wed, 20 Mar 2013 17:55:07 -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 y8sm38282212vei.5.2013.03.20.17.55.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 17:55:06 -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: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c02::22b 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:158009 Archived-At: On 03/20/2013 01:47 PM, Stefan Monnier wrote: >>> [ Actually, there are various reasons to split EIEIO, one of them would >>> be to try and fix the eval-and-compile mess. ] >> What do you mean by "splitting EIEIO"? Into what parts? > > 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? >> This won't work; you cannot detect whether a file is part of a project >> without the project's definition (which comes in the form of a class, as >> I've already written). It's a chicken/egg thing. > > I don't think so. The first part of the detection is to look for the > tell-tale files (.bzr, .dir-locals, Tupfile, you name it). > > The project definitions can setup some side table that can be preloaded > and used by a function that looks for those files. > > Some of those files will be frequent enough that we may also want to > preload some additional predicate that checks whether we really need to > load "the rest". I think all David is trying to say is that the EDE project detection system uses EIEIO classes to hold the match data. For example, the class instance contains the name of the key file to look for that identifies the project. 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. In both cases above, we'd need a simple mechanism to disable the loading of EDE project classes, and using a placeholder in the project cache instead. Alternately, perhaps I can find out why EIEIO isn't acceptable, and fix that instead. Eric