From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: A unified project root interface Date: Wed, 20 Mar 2013 13:47:26 -0400 Message-ID: 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 X-Trace: ger.gmane.org 1363801660 28441 80.91.229.3 (20 Mar 2013 17:47:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Mar 2013 17:47:40 +0000 (UTC) Cc: emacs-devel@gnu.org, Jorgen Schaefer , "Eric M. Ludlam" To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 20 18:48:06 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 1UIN7M-0000as-AK for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2013 18:48:04 +0100 Original-Received: from localhost ([::1]:52632 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIN6z-0003tB-0V for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2013 13:47:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIN6u-0003t3-E5 for emacs-devel@gnu.org; Wed, 20 Mar 2013 13:47:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIN6t-0006Tf-4Z for emacs-devel@gnu.org; Wed, 20 Mar 2013 13:47:36 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:26576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIN6t-0006TK-0f for emacs-devel@gnu.org; Wed, 20 Mar 2013 13:47:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxKvA/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOfYQSFFYFegxM X-IPAS-Result: Av4EABK/CFFFxKvA/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOfYQSFFYFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="5374998" Original-Received: from 69-196-171-192.dsl.teksavvy.com (HELO pastel.home) ([69.196.171.192]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Mar 2013 13:47:28 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D5DB16795A; Wed, 20 Mar 2013 13:47:26 -0400 (EDT) In-Reply-To: <87ppyurpxa.fsf@engster.org> (David Engster's message of "Wed, 20 Mar 2013 17:34:09 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:157998 Archived-At: >> [ 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 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". Stefan