Re: Unified project interface

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 07/29/2015 05:27 AM, Stephen Leake wrote:
>
>>> But you do specify "custom" locations for sal,
>>> sal_gtk and standard_common in the beginning, right? Then a smart
>>> enough tool could learn that information.
>>
>> I don't know what you mean by "learn"; the user writes the project file,
>> the tools read it.
>
> Figure out somehow, based on the project file and the contents of the
> file system, hopefully without asking the user more questions.

No need to "figure it out"; the search path for project files is right
there in the file:

   for Project_Path use
     ("../../../org.stephe_leake.sal/build/release",
      "../../../org.stephe_leake.gtk/build/release",
      "../../../org.stephe_leake.makerules");

That's where the project files for sal, sal_gtk, standard_common are
found.

This is interpreted relative to the directory the project file is found
in.

> For instance, even if the project file gives no direct indication of
> which search-path elements are "proper" projects, some Elisp code
> could look inside each of those directories (and one level above,
> maybe) and see if there are project files in any of them. And those
> where there are, promote to project-roots as well.

> That might be harder for Ada, but should be totally doable for
> Java-based projects (if build.gradle doesn't provide that info).

For Ada project files, everything is crystal clear; anything mentioned
in "with" is a proper project; nothing else can be. No searching
involved.

Same for gradle; every build.gradle file defines a proper project;
nothing else does.

> But consider this: elisp-search-path is not ideal (the current project
> could be not in load-path).

I don't understand; the user sets load-path. If the user wants to use
project-* and xref-* functions with the current project, why is it not
in load-path?

That's just bad user configuration; no amount of elisp intelligence can
fix that.

xref-find-definitions for elisp relies on the code being loaded, so
using it without the code being loaded makes no sense.

>> It can still be up to the backend to decide whether they
>> are flat or require additional recursion.
>
> Err, that sounds silly. Why would you want not to recurse?

1) Because many Emacs functions don't recurse. For example, I'd like to add:

(defun project-find-file ()
  "Prompt for a file name, find it on project-search-path."
  (interactive)
  (let ((filename
         (completing-read
          "file: "
          (apply-partially
           'locate-file-completion-table
           (project-search-path (project-current))
           nil))))

    (find-file (locate-file filename (project-search-path (project-current)) 
nil))))

This works fine with "load-path" instead of "project-search-path". But
it won't work unless project-search-path is flat;
locate-file-completion-table and locate-file do not recurse.

2) As I've mentioned before, not recursing allows computing the set of
   included/excluded directories once, instead of computing it again on
   each recursion.

3) Because some tools provide and expect a flat search path (AdaCore
   tools, gcc include path, emacs load-path, compilation-search-path,
   ff-search-directories).

    It is not at all clear how to convert a flat path into a recursive path
    with ignores; the solution you have for elisp load-path is a kludge,
    and could easily be wrong for some users.
    
> The current xref-collect-matches implementation unconditionally
> recurses, and it doesn't seem particularly useful to create a variant
> that doesn't.

The backends I'm aware of require flat paths (no recursion). So unless
some plausible backend actually requires recursion, it makes more sense
to assume recursion is not required.

>> Locations are tied other things besides cross-reference; cross-reference
>> is just one way of producing a list of locations.
>>
>> find-regexp is another way.
>>
>> compilation errors is another way.
>>
>> All of those could use a common location API. 'project' is one place to
>> put it; it could be in its own 'location' namespace.
>
> I suppose you're right. But until we have a unified location API
> (which I wouldn't count on appearing anytime soon), xref is the better
> place.
>
> xref-location lives there, and it's the best purpose-agnostic location
> class that we have now.

So move it to "location" instead of "xref". The longest journey starts
with one step ...

--
-- Stephe