From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: A unified project root interface Date: Wed, 20 Mar 2013 17:34:09 +0100 Message-ID: <87ppyurpxa.fsf@engster.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1363797268 11169 80.91.229.3 (20 Mar 2013 16:34:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Mar 2013 16:34:28 +0000 (UTC) Cc: "Eric M. Ludlam" , emacs-devel@gnu.org, Jorgen Schaefer , John Yates To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 20 17:34:48 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 1UILyP-0008Lu-9e for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2013 17:34:45 +0100 Original-Received: from localhost ([::1]:56992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UILy2-0008Jo-2p for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2013 12:34:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UILxv-0008Fj-4u for emacs-devel@gnu.org; Wed, 20 Mar 2013 12:34:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UILxt-0004Cm-PM for emacs-devel@gnu.org; Wed, 20 Mar 2013 12:34:15 -0400 Original-Received: from randomsample.de ([83.169.19.17]:51499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UILxt-0004CS-Dv for emacs-devel@gnu.org; Wed, 20 Mar 2013 12:34:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=vErdVSKecKHpXUGvYjas6jUazKmvOCp1lL3NUaLKwUM=; b=IFvK8jL0FDVk3QnoYPEgVmdoVxuj1qrKlPJiceh9zeOX8FpNiwDPxCKJQT7Z79Lu+Fvfqb4cYd1CGLqY1HsbB8mvEAM7Pj6A0/9x4z//OQUo6GARmxi3wyUk/4UMVIat; Original-Received: from dslc-082-083-058-027.pools.arcor-ip.net ([82.83.58.27] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UILxq-0000Vx-3G; Wed, 20 Mar 2013 17:34:10 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 20 Mar 2013 08:57:16 -0400") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.93 (gnu/linux) Mail-Followup-To: Stefan Monnier , John Yates , "Eric M. Ludlam" , emacs-devel@gnu.org, Jorgen Schaefer X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 83.169.19.17 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:157996 Archived-At: Stefan Monnier writes: >>> That might require splitting EIEIO, or some other approach, maybe, >>> I don't know. >> I don't think that's a practical approach. In EDE, a project *is* a >> class. > > [ 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? >> I would however like to ask if such a 'project-root' feature is >> absolutely needed right at startup time. I'm not sure about the overhead >> involved when loading files, which might be annoying to people who don't >> need it. OTOH, we already have vc-find-file-hook enabled by default, >> which I guess renders such questions moot... > > Right, one possible approach is to try and delay the use of > project-root, as is done for VC: have a preloaded ede-hooks.el file > which is just enough to try and detect projects that use EDE, and then > only load EDE if/when opening a file in such a project. 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. Yes, there are projects which save their state in a file 'Project.ede'; these could be detected, but that's a special case. So again, if such a 'project-root' feature is needed at startup, EDE is out. Separating EDE from EIEIO would mean rewriting it. Instead, I'd vote for a very simple approach which at least takes EDE projects into account, among other things. Roughly like this: (defun project-root-ede (file) (when (and (featurep' ede) (with-current-buffer file ede-object-root-project)) ... return EDE root ... )) (defun project-root-vc (file) (when (vc-file-registered file) ... return root from VC ... )) (defvar project-root-detect-functions '(project-root-ede project-root-vc)) (defun project-root () (run-hook-with-args-until-success project-root-detect-functions (buffer-file-name (current-buffer)))) -David