Re: Unified project interface

[Dmitry Gutov]

On 07/30/2015 11:17 AM, Stephen Leake wrote:

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

Fantastic, then Ada gives you all you need to implement both 
project-search-path and project-roots.

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

It's not always the current practice, AFAIK. And adding it to load-path 
interactively is not something we should force the users to do.

Consider that when xref-find-references doesn't find anything, it will 
say "nothing found", without further explanations, leaving the user to 
puzzle out why and what. We should err on the side of showing too much, 
rather than too little.

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

One can also load the code without adding the file to load-path. For 
instance, via eval-buffer.

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

I guess you'd need to implement a "flattening" function for that, 
indeed. I don't really see myself using this command, though.

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

And I countered that, for many commands, computing that set is unlikely 
to be the bottleneck. And cache invalidation is not user-friendly.

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

That's not really true.

There are many directories inside /usr/include, but C_INCLUDE_PATH won't 
mention most of them. Instead, #include <postgresql/pg_config> will use 
/usr/include/postgresql/pg_config.h, as long as /usr/include is in 
C_INCLUDE_PATH.

There's only one directory in Emacs load-path with "cedet" in its name, 
but (require 'semantic/db) will load lisp/cedet/semantic/db.el.

You're right about compilation-search-path and ff-search-directories, 
though.

It seems to be true for the Ada source search path as well, but since 
/usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude/ has no subdirectories, the 
point is moot. Traversing it recursively wouldn't make anything worse.

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

I'd like to see one of those users first.

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

Until it's used in at least two different places, creating a separate 
package for it is, I think, premature.