[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: Sat, 25 Jul 2015 02:43:32 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

Let's maybe continue this discussion?

On 06/05/2015 01:08 PM, Stephen Leake wrote:

No, xref-find-regexp should search project-source-directories.

Most real projects include other projects, so limiting the search to
only the top project is wrong in general (although that might be a
useful option in some use cases).

I suppose, and maybe I was wrong to suggest a distinction between "source" directories and the rest of them. However, here's one which could be better: directories to search vs. directories to modify.

Like, I might want to search the full system includes path, in a C project, but when performing a replacement operation (such as xref-query-replace), I should probably limit myself to the directories with code I actually own. At the moment, it's the distinction I imagine for project-search-path vs project-directories.

In addition, there might be a directory under project root that should
_not_ be searched; the object file directory for ada-mode, for example.

We have that in project-ignores now.

We can make [root] a requirement in order to use the general tool. But first
we have to justify it; ada-mode has never needed that notion; neither
has elisp. In my experience, only config management needs it.
> ...
It also points out that "project root" is poorly defined; I think that
is because it's not at all clear when and why we need it.

Here's the first use case I know of:

There's a third-party project called rspec-mode. It allows one to switch between a source file and its test, and to run tests in a compilation buffer. For both purposes, it needs to determine the directory which to build the relative paths against, and in which to run the 'rspec' program. Currently, it does a locate-dominating-file like routine (looking for Gemfile or Rakefile), but it could switch to the project API in the future.

You're probably aware of similar tools.

So, now we have both project-root and project-directories. However, the relationship between them looks murky, from the consumer's standpoint. Like, must the former always be included in the latter?

I'm considering removing project-root, and copying a part of Atom's API [0]: adding a function project-relativize-path, which will, given an arbitrary directory, if it's inside project-directories, split its file name in two and return a cons, with one of project-directories in the car, and the relative file name against it in the cdr.

Then instead of project-root, a consumer will use (car (project-relativize-path default-directory)).


[0] https://atom.io/docs/api/v1.0.2/Project#instance-relativizePath

reply via email to

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