Re: Unified project interface

[Dmitry Gutov]

On 08/01/2015 12:50 PM, Stephen Leake wrote:

> > As such, it will require a separate code path in xref-collect-matches
> > and an alternative for xref--rgrep-command.
>
> Or they could abort; that would be ok while we are experimenting. It may
> be that one or the other will turn out to be The Right Way.

That's not helpful. Of course we want the API be straightforward and 
usable for as many callers as possible. It's the main goal.

I'm not sure how The Right Way would supposedly present itself.

> A backend that uses flat paths doesn't have to use those functions. Or,
> the people writing that backend can modify them if that seems better
> than putting similar code elsewhere. That would be part of the cost of
> that design decision.

It's a high cost.

If the author of such backend intends to reimplement or rewrite every 
feature like that, they can just as well not bother with implementing 
the Project API. As you can see, there's not much code in project.el, so 
they won't miss much if they don't value interoperability.

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

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

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

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.

> > The /** syntax is rather nifty. But why do you propose to have it and
> > MAKE-RECURSIVE at the same time? We could just interpret /** as the
> > recursive marker. Then the result could be a list of strings.
>
> Because you never need both. If you are used to using recursive paths,
> adding ** in the path to tell the code that will seem odd. So it seems
> best to have an explicit flag.

The user could specify the paths in any way they like, are used to, etc. 
What's important is what the project backend returns in project-search-path.

> > 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). Second, like I 
mentioned before, that loses information: in particular, we won't know 
which directories were the root ones.

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

> > > Me, and many other teams at NASA - structures similar to the above,
> > > where the non-included directories can also be release version,
> > > debug/release options, target hardware/os option, compiler
> > > vendor/version, etc.
> >
> > There can be different opinions about this.
>
> Yes, precisely. And Emacs core should not be enforcing any opinions!

Err, some opinions are worth being enforced. But anyway, the Ada project 
backend can behave any way you wish, in this respect.

> > Both still use xref for display. The location values aren't consumed
> > by anything else. So that's just one place.
>
> They both display locations. The code that displays locations should
> also be in the locations namespace, not the xref one.

What's left for xref, then? Most of the code there deals with displaying 
xrefs in the buffer.