Re: A unified project root interface

[Dmitry Gutov <dgutov@yandex.ru>]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> 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* '())

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'?