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: Mon, 18 Mar 2013 23:50:23 +0100 Message-ID: <87ppywtj9s.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1363648617 18925 80.91.229.3 (18 Mar 2013 23:16:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Mar 2013 23:16:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 19 00:17:23 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 1UHjIx-0000ft-3S for ged-emacs-devel@m.gmane.org; Tue, 19 Mar 2013 00:17:23 +0100 Original-Received: from localhost ([::1]:45274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHjIa-0006FV-2k for ged-emacs-devel@m.gmane.org; Mon, 18 Mar 2013 19:17:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHjIQ-00064U-Ef for emacs-devel@gnu.org; Mon, 18 Mar 2013 19:16:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHjIO-0001eO-Cr for emacs-devel@gnu.org; Mon, 18 Mar 2013 19:16:50 -0400 Original-Received: from randomsample.de ([83.169.19.17]:40053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHit0-00024W-7T for emacs-devel@gnu.org; Mon, 18 Mar 2013 18:50:34 -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=vwbues3HDiO956YdEBQyA3Z2KUwR2/A3JNMFp7yQLnw=; b=ujMdsED4Haj2qHnWtulzJ7+PeYd5vhp8sFFCfLigGNvSKF7kfgwGymI0Fzqa7DarIa9bh2H30f6OUebIX7grD6fugMCAB17uUQpLOCNzebT8G4wyP6qnWGlJ1kSQ9L8F; Original-Received: from dslc-082-082-167-028.pools.arcor-ip.net ([82.82.167.28] helo=spaten) by randomsample.de with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UHiss-0006ti-6Q; Mon, 18 Mar 2013 23:50:26 +0100 In-Reply-To: <20130317191817.764a44f5@forcix.kollektiv-hamburg.de> (Jorgen Schaefer's message of "Sun, 17 Mar 2013 19:18:17 +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:157934 Archived-At: --=-=-= Content-Type: text/plain Jorgen Schaefer writes: > On Sun, 17 Mar 2013 18:40:13 +0100 > David Engster wrote: >> 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). > >> [...] > >> 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. > > Opening a file in a subdirectory of a repository root does not > associate it with a project. I suspect this is a bug in this "proof of > concept" implementation more so than a conceptual problem, though :-) I've attached a new version which should hopefully work better. > I'm a bit unsure about requiring EDE, CEDET, etc. for this - it's not > unlikely that people will go "meh" and not use it because of that. (I'm > sorry to say so, but the complexity of CEDET is a recurring theme on the > Emacs IRC channel.) I'd like to stress again that querying EDE for stuff like the current root project directory does not require knowledge of EIEIO/CLOS; if you find that it does, then please report this and we fix it. Yes, functions like `ede-project-root-directory' are actually methods, but why does it matter? Just call them like any other function. What *is* a real problem at the moment is that `describe-function' does not say anything meaningful about them, but I'm in the process of fixing that. If it's still seen as too cumbersome after that, then OK, let's wrap'em. :-) I'm willing to code the necessary stuff on the EDE side of things; if it turns out too complicated to use for package maintainers, I have no problem throwing it away. > So in the end, what we need for trivial implementation: > > - Provide a default "simple project" that auto-detects the root via > VCS markers > > - Define a (project-root) that simply returns (and > ede-object-root-project (ede-project-root-directory > ede-object-root-project)) That's for the maintainers to decide. I have a hunch they'd like to have an ede- prefix... > - Define a (project-set-root DIR) that does (oset this :file DIR) for > the current project. If there is no current project, this should > create a "simple project" for that directory so other uses of > (project-root) will find it. This can be done. I will need a bit of time though, since I really need to do another CEDET merge round with current trunk first. I think I'll be able to come up with something in the coming weeks. > - Ask authors of extensions to use (ede-minor-mode 1) in their mode > function and simply use that function in their modes. Not sure if it's a good idea to enable EDE behind the user's back; I think they should enable it in their init file if they want to have project support. But IMO that's a detail; let's cross that bridge when we get there. -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) (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-check-for-vcs-dirs (dir) "Check if DIR contains one of `ede-vcs-root-directories'." (let ((dirs ede-vcs-root-directories) vcdir current) (while (and (not vcdir) (setq current (pop dirs))) (setq vcdir (when (file-exists-p (expand-file-name current dir)) (expand-file-name current dir)))) vcdir)) (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 (ede-check-for-vcs-dirs dir))) (ede-add-project-autoload (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) '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) --=-=-=--