[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unified project interface

From: Dmitry Gutov
Subject: Re: Unified project interface
Date: Fri, 31 Jul 2015 03:15:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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."
   (let ((filename
          "file: "
           (project-search-path (project-current))

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

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,

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]