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: Sun, 17 Mar 2013 18:40:13 +0100 Message-ID: <87y5dmsz5u.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1363542020 32223 80.91.229.3 (17 Mar 2013 17:40:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Mar 2013 17:40:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 17 18:40:45 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 1UHHZc-0003mV-3z for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2013 18:40:44 +0100 Original-Received: from localhost ([::1]:32907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHHZF-0001b3-9l for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2013 13:40:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHHZB-0001Zc-5H for emacs-devel@gnu.org; Sun, 17 Mar 2013 13:40:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHHZ9-0001AB-PE for emacs-devel@gnu.org; Sun, 17 Mar 2013 13:40:17 -0400 Original-Received: from randomsample.de ([83.169.19.17]:47380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHHZ9-00018M-9E for emacs-devel@gnu.org; Sun, 17 Mar 2013 13:40:15 -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=S0y7qdys6HqKJOjLhAgVsV07nf42WyLDeYLP7L7aiZw=; b=fggEYqa14mcucwwTeE9eYLBfAeV4CVl2dTYQHUlMq14WLNmR/KPiHPTm5/5bV901rIzaSzODIe3R5ZlD615kHO3GCzVi7NIXW4+Dw4wbbGCx+ef3kTEt/DtEzST3NHFs; Original-Received: from dslc-082-082-166-112.pools.arcor-ip.net ([82.82.166.112] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UHHZ7-0001TC-QH; Sun, 17 Mar 2013 18:40:14 +0100 In-Reply-To: <20130317001630.125e1987@forcix.kollektiv-hamburg.de> (Jorgen Schaefer's message of "Sun, 17 Mar 2013 00:16:30 +0100") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.93 (gnu/linux) Mail-Followup-To: Jorgen Schaefer , emacs-devel@gnu.org 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:157915 Archived-At: --=-=-= Content-Type: text/plain Jorgen Schaefer writes: > On Sat, 16 Mar 2013 23:59:39 +0100 > David Engster wrote: > >> I think our C/C++ project wrapper is a >> good example for this, where you define a project like this: >> >> (ede-cpp-root-project "NAME" >> :file "~/myproject/Makefile" >> :include-path '( "/include" "../include" "/c/include" ) >> :system-include-path '( "/usr/include/c++/3.2.2/" ) >> :spp-table '( ("OS_GNU_LINUX" . "1") )) >> >> I'd argue this is already similar to how projects are defined in >> project-root.el. > > I have no idea what project-root.el is or why anyone brought it up. The > two project libraries I linked in the first post of this thread and > described therein do not require such cumbersome extra effort. This is just a matter of providing default project types, which are activated at startup. You do not have to explicitly specify projects like this. EDE already ships with such default projects, for example for detecting the Emacs source, or the Linux kernel. It is very easy to do something similar for version controlled files (see below), similar to what your project.el does. project-root.el is just a slightly more generic version than your project.el. Most importantly, it allows to define different types of projects, so that a package author can for example add some functionality only for Perl projects, excluding all the others. > In the normal case, I do not want to define a project at all. Fair enough, but while this may be the "normal" case, the ability to define own project types is not an exotic demand, IMO. I like how project-root handles this. > As an extension author, I just want to call (project-root) in my > extension and have it magically return a directory that's the root > directory of the project. In EDE, you have a buffer-local variable `ede-object-root-project', which holds the root project. I can be queried through methods, for instance (ede-project-root-directory ede-object-root-project) will get you the root directory. > The problem I raised in this thread is that too many packages write > their own solution because using any of the possible standard solutions > is too cumbersome. Saying "there is a cumbersome standard solution" > does not solve the problem. I do not say that. To hopefully prove my point, I've hacked together a small EDE project for detecting files under git/hg/bzr version control, very similar to how you do it in your project.el (I've dropped the CVS/.svn detection for the moment). Just load Emacs with emacs -Q -f global-ede-mode -l vcs-root.el and load some file under a git/hg/bzr versioned directory. There is an example function `my-get-project-root' to print the project's root. While you might not like the CLOS-like syntax, I hope it can be seen that this is not difficult and fairly short (most of it is just boilerplate), and you directly profit from stuff like caching that EDE does (as Eric has already mentioned in this thread). Just to be clear: I do *not* expect that users write this stuff; instead, Emacs should provide projects like this as defaults. -David --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=vcs-root.el Content-Transfer-Encoding: quoted-printable (require 'ede) (defvar ede-vcs-root-directories '(".git" ".hg" ".bzr")) (defvar ede-vcs-root-project-list nil) (defclass ede-vcs-root-project (ede-project eieio-instance-tracker) ((tracking-symbol :initform 'ede-vcs-root-project-list) ) "Project Type for detecting roots of VCS handled files." :method-invocation-order :depth-first) (defmethod ede-project-root-directory ((this ede-vcs-root-project) &optional file) "Return root directory for this project." (oref this :file)) (defun ede-vcs-root-dir (&optional dir) "Get root directory for current file if under version control." (when (not dir) (setq dir default-directory)) (let ((dirs ede-vcs-root-directories) root current) (while (and (not root) (setq current (pop dirs))) (setq root (locate-dominating-file dir current))) root)) (defun ede-vcs-root-load (dir &optional rootproj) "Create object for vcs-root project." (ede-vcs-root-project dir :name dir :directory dir :targets nil :file (expand-file-name "." dir))) (ede-add-project-autoload (ede-project-autoload "vcs-root" :name "VCS ROOT" :file 'vcs-root :proj-file "." :proj-root 'ede-vcs-root-dir :class-sym 'ede-vcs-root-project :load-type 'ede-vcs-root-load :new-p nil :safe-p t) 'generic) (defun my-get-project-root () (interactive) (let ((proj ede-object-root-project)) (if proj (message "Project root: %s" (ede-project-root-directory proj)) (message "No project for this buffer.")))) (provide 'vcs-root) --=-=-=--