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: Re: A unified project root interface Date: Sun, 17 Mar 2013 00:16:30 +0100 Message-ID: <20130317001630.125e1987@forcix.kollektiv-hamburg.de> 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> 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 1363475799 21610 80.91.229.3 (16 Mar 2013 23:16:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Mar 2013 23:16:39 +0000 (UTC) To: David Engster , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 17 00:17:04 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 1UH0LY-0006Mp-9O for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2013 00:17:04 +0100 Original-Received: from localhost ([::1]:36892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH0LB-0006db-Fh for ged-emacs-devel@m.gmane.org; Sat, 16 Mar 2013 19:16:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH0L8-0006dR-0A for emacs-devel@gnu.org; Sat, 16 Mar 2013 19:16:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UH0L4-0000cU-4V for emacs-devel@gnu.org; Sat, 16 Mar 2013 19:16:37 -0400 Original-Received: from istinn.electusmatari.com ([83.169.37.145]:51229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UH0L3-0000cP-Uq for emacs-devel@gnu.org; Sat, 16 Mar 2013 19:16:34 -0400 Original-Received: from forcix.kollektiv-hamburg.de (hmbg-4d06c444.pool.mediaWays.net [77.6.196.68]) by istinn.electusmatari.com (Postfix) with ESMTPSA id E39BED10001E; Sun, 17 Mar 2013 00:16:32 +0100 (CET) In-Reply-To: <87ehffuf1g.fsf@engster.org> 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:157908 Archived-At: 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. In the normal case, I do not want to define a project at all. 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. As a user, I just want to Have It Work[tm] when opening a file without me defining anything. At most, if all possible heuristics fail, I can live with being asked for the project root directory. Everything more than this, and I'll just ignore that "feature" because it's cumbersome to use. Every further feature is "nice to have", and only useful if it does not require more effort than the above. And every requirement for "project" the above does not cover (like, say, multiple project roots) is a fringe use I can happily live without, as apparently can a bunch of other extension authors. 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. Regards, -- Jorgen