From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.devel Subject: A unified project root interface Date: Sat, 9 Mar 2013 17:44:19 +0100 Message-ID: <20130309174419.6e1cadb4@forcix.kollektiv-hamburg.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1362847474 27862 80.91.229.3 (9 Mar 2013 16:44:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Mar 2013 16:44:34 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 09 17:44:59 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 1UEMtG-0000FX-Tw for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2013 17:44:59 +0100 Original-Received: from localhost ([::1]:51036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEMsv-0004WC-0Y for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2013 11:44:37 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEMsn-0004Un-8o for emacs-devel@gnu.org; Sat, 09 Mar 2013 11:44:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UEMsi-0006pH-0M for emacs-devel@gnu.org; Sat, 09 Mar 2013 11:44:29 -0500 Original-Received: from istinn.electusmatari.com ([83.169.37.145]:50511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEMsh-0006p4-NF for emacs-devel@gnu.org; Sat, 09 Mar 2013 11:44:23 -0500 Original-Received: from forcix.kollektiv-hamburg.de (hmbg-5f765ece.pool.mediaWays.net [95.118.94.206]) by istinn.electusmatari.com (Postfix) with ESMTPSA id CB586D10001E for ; Sat, 9 Mar 2013 17:44:21 +0100 (CET) X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 83.169.37.145 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:157669 Archived-At: Hello! A growing number of extensions out there deal with "projects" as opposed to "single files", that is, a collection of files that belong together in some form or another. The usual way to define a project is via the "project root", a directory so that all files under that directory are considered part of "the project". This is not exactly difficult to write, which has lead to the situation where pretty much every extension that uses projects defines their own code to find and set the project root. Examples of this are find-file-in-project, projectile, elpy, flymake, ropemacs, nose, etc. Now, if an user wants to use two or more of those extensions together, she needs to "synchronize" the different ideas of project root manually. Which gets more complicated the more extensions that define their own project roots. It would be really useful if there was a single standard way to define the project root, so that extensions can just use that standard way without each and every one of them writing the same code over and over again. Sadly, as the code is not exactly difficult and so many projects have already used their own way, it's highly unlikely that a random third-party library would simply "emerge" as the standard way of doing things. Which makes me believe the only way to solve this is via a bit of a top-down decision to include a library in Emacs and declare it as "the default". So this is my somewhat verbose request to say "yes, let's do this" and pick a library to provide the functionality. The library itself doesn't have to be big at all, in theory a single variable `project-root' that everyone is encouraged to use would be enough. Adding some basic functionality to this would be helpful, though. If we keep the functionality to a minimum, this lets other extensions use it without being annoyed at the features they drag in. Suitable libraries exist: https://github.com/jorgenschaefer/project-el (my own proposal for this problem, GPLed, happy to assign copyright / should already have.) https://github.com/nex3/project-el (unsure about the status, it's on marmalade, though.) There are probably others. Does this sound sensible? Are there other possible approaches? What's the next step to solve this problem? Regards, -- Jorgen