Re: Unified project interface

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 07/31/2015 07:13 PM, Stephen Leake wrote:
>
>> Which is faster/friendlier depends on the details, so we'll have to wait
>> for actual implementations. All I'm asking is that we do not make design
>> decisions at the generic project API level that rule out this approach.
>
> We do have to make some decisions, though. For instance, supporting
> both recursive and non-recursive elements in search-path will require
> a separate code path for each function that uses it.
>
> 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.

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.

>> I would provide a special syntax to handle this in
>> project-add-search-path:
>>
>> (defun project-add-search-path (project path &optional make-recursive)
>>    "Add PATH (a list of directories) to the search path for PROJECT.
>>
>> If a directory in PATH ends in \"/**\", also add all directories under
>> that directory.
>>
>> If MAKE-RECURSIVE is non-nil, the full project search path is pruned so
>> that only highest-level directories are present, and all uses of
>> `project-search-path' recurse into subdirectories. In this case, it is
>> likely you will also need to specify ignored directories with
>> `project-add-ignores'.
>>
>> If MAKE-RECURSIVE is nil, uses of `project-search-path' no not recurse
>> into subdirectories."
>> ... )
>>
>> The Ada project files support the ** sytnax.
>>
> This description explains the purpose, but doesn't describe the
> resulting data structure that would hold that information. The ones
> that come to mind are rather ugly.

I have no idea what data structures come to mind for you.

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

Is that "ugly"?

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

It might be better to specify the recursive flag in the project
constructor; then this function would check it, not set it.

>> This could be handled if the user can explicitly specify project ignores
>> (not just rely on .gitignore etc; git does _not_ ignore the lisp-emacs-*
>> and ada directories). More complicated structures are harder to handle
>> with ignores; you'll end up with a long flat list of ignores, so it
>> might be simpler to have a flat list of includes instead.
>
> 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.

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

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

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

>>>> So move it to "location" instead of "xref". The longest journey starts
>>>> with one step ...
>>>
>>> Until it's used in at least two different places, creating a separate
>>> package for it is, I think, premature.
>>
>> Right. We now have those two places; xref-find-definitions,
>> project-find-regexp.
>
> 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.

-- 
-- Stephe