From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: A unified project root interface Date: Sun, 24 Mar 2013 08:25:38 +0400 Message-ID: <87li9d2zlp.fsf@yandex.ru> References: <20130309174419.6e1cadb4@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> <87ppyurpxa.fsf@engster.org> <514A5A68.3070907@siege-engine.com> <87hak4af33.fsf@engster.org> <514BAA14.7060702@siege-engine.com> <87li9fyy6v.fsf@engster.org> <514DE1FC.4020805@siege-engine.com> <20130323182648.059f2e2a@forcix.kollektiv-hamburg.de> <87d2uqkna5.fsf@yandex.ru> <87d2upon55.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1364099163 1577 80.91.229.3 (24 Mar 2013 04:26:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2013 04:26:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Pascal J. Bourguignon" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 24 05:26:29 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 1UJcVl-0007Bz-Kt for ged-emacs-devel@m.gmane.org; Sun, 24 Mar 2013 05:26:25 +0100 Original-Received: from localhost ([::1]:40777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJcVN-0005rW-7W for ged-emacs-devel@m.gmane.org; Sun, 24 Mar 2013 00:26:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJcVE-0005qd-3q for emacs-devel@gnu.org; Sun, 24 Mar 2013 00:25:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJcV9-0005Ff-4C for emacs-devel@gnu.org; Sun, 24 Mar 2013 00:25:52 -0400 Original-Received: from mail-la0-x233.google.com ([2a00:1450:4010:c03::233]:55385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJcV8-0005E3-JT for emacs-devel@gnu.org; Sun, 24 Mar 2013 00:25:47 -0400 Original-Received: by mail-la0-f51.google.com with SMTP id fo13so9569118lab.38 for ; Sat, 23 Mar 2013 21:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type:x-antivirus :x-antivirus-status; bh=0lIHYckXNa/ttplONyvtKto1rrcZUa5bo4s08Rep81g=; b=fdPEJPKQOgI8yyQyyTfEFhyRjhZBc4IYzpmXUHyN05L9TM1Pq2sgqMPIHYHOjlzzhX RAG95cTDPwMWXwJ9xpmYxLubdWkY0dwi7MqZG6Czg9wk3aNXpFsjz2CDJtJV6PuGey6n R+MCbP1S21+Zx/We9R7qunFuLqG6GXwr6XlRSWPQSrSy/VsCHDvhSFWHXoCsuq7d/KsE /wlq5CnpuFIE4IMbw0eaGvt8ThuXMIzbUdnY0fESgV1huYrmwcSqwO3/gT+RxH3THwgi LoajueL84DslLk2U4kvgD++3BkeUb66WAPc1gBXg45F9lmQw+PFM00HRAAxyxbeSCG0F qT/Q== X-Received: by 10.112.83.133 with SMTP id q5mr3746077lby.25.1364099145555; Sat, 23 Mar 2013 21:25:45 -0700 (PDT) Original-Received: from SOL ([178.252.98.87]) by mx.google.com with ESMTPS id m1sm3167980lbh.5.2013.03.23.21.25.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 21:25:44 -0700 (PDT) In-Reply-To: <87d2upon55.fsf@kuiper.lan.informatimago.com> (Pascal J. Bourguignon's message of "Sat, 23 Mar 2013 21:51:34 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) X-Antivirus: avast! (VPS 130323-2, 23.03.2013), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::233 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:158102 Archived-At: "Pascal J. Bourguignon" writes: > Dmitry Gutov writes: > >> Jorgen Schaefer writes: >> >>> On Sat, 23 Mar 2013 13:10:20 -0400 >>> "Eric M. Ludlam" wrote: >>> >>>> If this project concept is created as a simple thing, that's fine, >>>> but EDE won't be able to use it, though it could contribute. If >>>> that's the overall story where simple uses need the simple project, >>>> and EDE is used when you need more, that seems like a fine >>>> compromise, but it won't simplify the plethora of project projects. >>> >>> Let's say we create two primary API functions >>> >>> - (project-root) >>> - (project-set-root DIR) >> >> I think it would work better if insted of the second function, we'll >> have a variable `project-root-functions', along the lines of >> `completion-at-point-functions'. > > Not instead, but as hooks: > > (defvar *current-project-dir* nil) > (defvar *resign-current-project-hook* '()) > (defvar *become-current-project-hook* '()) The presence of hooks would be independent of what I'm suggesting. The idea is that `project-root' calls all functions in `project-root-functions', and as soon as one of them returns a meaningful value, `project-root' (being the caller) uses it to set the value of `current-project-dir', and then probably caches it. The difference is like between "push" and "pull" designs. With "push" design, it harder to understand which functions and under which circumstances should call `project-set-root'. > (defun project-set-root (dir) > (when *current-project-dir* > (run-hook-with-args *resign-current-project-hook* *current-project-dir*)) > (do-default-project-set-root dir) > (assert (eq *current-project-dir* dir)) > (run-hook-with-args *become-current-project-hook* *current-project-dir*)) > > >> It will contain some simple function by default (that will look for >> .dir-locals.el, for example), and EDE, when loaded, can push its own >> function on top. > > Indeed, (do-default-project-set-root dir) could just set > *current-project-dir*, and allt the rest could be done in > *become-current-project-hook*. Imagine you're writing a third-party library that would like to know the project root of the current buffer. What function should it call? Just `project-root'? Who is going to call `do-default-project-set-root'?