[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A unified project root interface
From: |
Dmitry Gutov |
Subject: |
Re: A unified project root interface |
Date: |
Sun, 24 Mar 2013 08:25:38 +0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) |
"Pascal J. Bourguignon" <address@hidden> writes:
> Dmitry Gutov <address@hidden> writes:
>
>> Jorgen Schaefer <address@hidden> writes:
>>
>>> On Sat, 23 Mar 2013 13:10:20 -0400
>>> "Eric M. Ludlam" <address@hidden> 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'?
- Re: A unified project root interface, (continued)
- Re: A unified project root interface, David Engster, 2013/03/21
- Re: A unified project root interface, Eric M. Ludlam, 2013/03/21
- Re: A unified project root interface, David Engster, 2013/03/22
- Re: A unified project root interface, Eric M. Ludlam, 2013/03/23
- Re: A unified project root interface, Jorgen Schaefer, 2013/03/23
- Re: A unified project root interface, Dmitry Gutov, 2013/03/23
- Re: A unified project root interface, Pascal J. Bourguignon, 2013/03/23
- Re: A unified project root interface,
Dmitry Gutov <=
- Re: A unified project root interface, Jorgen Schaefer, 2013/03/24
- Re: A unified project root interface, Jorgen Schaefer, 2013/03/20
- Re: A unified project root interface, Jorgen Schaefer, 2013/03/19
- Re: A unified project root interface, joakim, 2013/03/17
- Re: A unified project root interface, Phil Hagelberg, 2013/03/16
Re: A unified project root interface, Sudish Joseph, 2013/03/12
Re: A unified project root interface, Ted Zlatanov, 2013/03/12