Re: Unified project interface

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 08/01/2015 12:50 PM, Stephen Leake wrote:
>
>> This could be implemented with a root projects type:
>>
>> (cl-defstruct (projects)
>>    user-search-path ;; list of directories added to project-search-path
>>    user-ignores ;; list of ignores added to project-ignores
>>    recursive-search-path
>>    ;; if non-nil, project-search-path is treated as recursive in all usees
>>    ...
>>    )
>
> That doesn't tell me what values project-search-path would return, for
> every kind of configuration. That's the important part.

(cl-defgeneric project-search-path (project)
  "..."
  (project--prune-directories
   (nconc (project-user-search-path project)
          (funcall project-search-path-function)
          ;; Include these, because we don't know any better.
          ;; But a specialized implementation may include only some of
          ;; the project's subdirectories, if there are no source
          ;; files at the top level.
          (project-directories project))))

>> Is that "ugly"?
>
> Depends on how you feel about double negatives. There should be just
> one way to express whether a given directory should be traversed
> recursively.

There is; the boolean flag recursive-search-path.

> (cl-defstruct (projects)
>   flat-search-path
>   recursive-search-path
>

I'm guessing that here "flat-search-path" is a list of directories,
intended to be used non-recursively. A comment would really help;
guessing is dangerous in this discussion.

And then "recursive-search-path" is a list of directories, intended to
be used recursively.

So they contain redundant information; they are each a cache of the
result of the current `project-search-path' (with and without pruning).

> would be one option for the implementation, but what would it mean for
> the API? If we have both project-flat-search-path and
> project-recursive-search-path as accessors, there's high probability
> that some functions will only look up and handle one of them. That's
> bad.

Yes, it would be nice if we could agree that either flat or recursive is
the baseline; any function that needs the other can convert.

So far, I think we have these arguments on each side:

- elisp load-path is already mostly flat

    it needs to be expanded to handle path/file style requires

- Ada project paths are flat

    This is actually AdaCore project paths; they support C++ and C as well.

- Some other project paths are recursive

- Converting between them (while also converting the corresponding
  includes) is possible
  
- Using find-grep and similar external programs allows recursive search
  to display first results immediately
  
>>> I've just started to write about this... Yes indeed, I think every
>>> flat structure can be translated into path/to/dir, plus path/to/dir/*/
>>> in the ignores. The translation function shouldn't take too much work
>>> to write.
>>
>> The reverse is also true; it is possible to convert recursive
>> path/ignores into flat path/ignores.
>
> Not without drawbacks. First, it's more computationally intensive
> (Emacs would have to traverse the actual directory tree). 

You have to traverse the tree at some point; either during the use of
the recursive path, or to convert the path.

Converting it once is cheaper overall.

But, as I've said before, this is an optimization issue. If it turns out
that the performance either way is acceptable, it's not important.

> Second, like
> I mentioned before, that loses information: in particular, we won't
> know which directories were the root ones.

If that is useful information, obviously it can be saved. That's what
project-roots is for.

>>> There's no need to produce the list of ignores manually.
>>
>> Only if you ignore the use cases I posted. There are situations where
>> the algorithm will not do what the user wants.
>
> What algorithm? 

The algorithm that automatically produces the list of ignores.

> I don't see why you can't write an algorithm that will
> both handle flat directories via ignores, as well as honor the user's
> wishes.

The user has to have a way of expressing those wishes. That's what
project-add-ignores is for.

>> The fact that you don't like them does not mean they are not valid.
>>
>> Would it be such a problem to provide 'project-add-ignores'?
>
> I don't understand why you would state this question here? It doesn't
> seem relevant.

I'll take that as agreeing to add the functions project-add-search-path
and project-add-ignores to project.el

Given all of the above, I'll make an attempt to write Ada and JDEE
project backends, using recursive paths. We'll see how that goes.

-- 
-- Stephe