[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)).
Thoughts?
[0] https://atom.io/docs/api/v1.0.2/Project#instance-relativizePath
- Re: Unified project interface,
Dmitry Gutov <=
- Re: Unified project interface, Dmitry Gutov, 2015/07/25
- Re: Unified project interface, Stephen Leake, 2015/07/26
- Re: Unified project interface, Dmitry Gutov, 2015/07/26
- Re: Unified project interface, Stephen Leake, 2015/07/26
- Re: Unified project interface, John Yates, 2015/07/26