Re: A unified project root interface

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Jorgen Schaefer <forcer@forcix.cx> writes:
>
>> On Sat, 23 Mar 2013 13:10:20 -0400
>> "Eric M. Ludlam" <eric@siege-engine.com> 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* '())

(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*.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.