[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unified project interface
From: |
Stephen Leake |
Subject: |
Re: Unified project interface |
Date: |
Sun, 26 Jul 2015 13:57:56 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) |
Dmitry Gutov <address@hidden> writes:
> In Ruby and Python communities, for instance, it's common to install
> the language runtime, with all libraries, inside the developer's home
> directory (using RVM/rbenv for Ruby, or virtualenv for Python). And I
> might edit some of files there for debugging purposes, but if I forget
> about those edits later, only bad can come of it. Likewise, I usually
> wouldn't want a global replace operation to touch them.
Then it's not "global", is it? It's "operate on this set of projects,
exclude that set". So you need a way to specify sets of projects.
>>> I'm not sure about that. It seems then the implementation will have to
>>> walk the whole project tree itself, and collect all directories that
>>> don't match the ignores (because .gitignore syntax allows not-anchored
>>> entries for directories).
>>
>> Yes. You do that once when the project is opened, and cache the result
>
> And then the user creates a new dir (or switches to a different
> branch, revision, etc), and the cache goes out of sync. How do we
> handle that?
project-cache-refresh. Only the user knows when it should be done; they
may want to keep the slightly out of date cache because something isn't
finished with the edits yet.
>> No, Emacs needs to read the Studio project file and extract the search
>> path; it's just another project file syntax.
>
> But according to you, the "search path" will be just the directories
> inside the project's tree, right?
No, I have been explicitly saying that is not the case; the search path
is whatever the project file says it is.
> What will "included projects" look like, in an average Android
> project?
A list of project names. Depending on the project manager, that implies
a list of project files in one syntax or another, each of which
specifies a set of project directories (explicitly or implicitly).
>> Yes. No different from any other Emacs project; the user has to tell
>> Emacs where it is. If that's a directory, Emacs searches for project
>> file extensions it knows about, and reads that. If it's a file, no
>> searching needed.
>
> The VC project implementation is currently based on the current
> buffer's directory. No need to explicitly specify it, Emacs find the
> repo root without user intervention.
Yes.
> If you've ever tried Projectile, it works in a similar fashion.
> Android projects could be detected like that as well.
Maybe. Depends on the project manager software. Some have a dominating
file, some do it some other way.
Why do we care? Just support whatever method the project manger backend
requires. project-find-project-file is a dispatching function on the backend.
>> Emacs should trust what the project file says; it has an explicit list of
>> "source code directories". Emacs should not care whether that contains
>> the project file itself or not; that's up to the user.
>
> Will this miss all the other directories in the project, such as
> documentation, maybe? One would expect xref-find-regexp to search
> them, too.
Trust what the project file says. The user told Emacs to use the project
file; it should not try to be smarter.
If the user wants documentation in the project, then it is in the
project file. If the project manager tool is brain-dead and can't handle
documentation, the the user can switch tools.
>> Since the external tools that use the project file can report errors in
>> its syntax, I usually include the project file in a directory that is in
>> the source path. But that's my choice, not Emacs's.
>
> One would expect xref-find-regexp to search in the project file, too.
Only if I tell it to by including it in the project file. If I tell it
to _not_ search the project file, it should do that.
>> project-root; a single absolute directory, usually containing
>> significant files for external tools (ie .git/), often the root of the
>> source tree.
>
> Would we have project-root mainly for the purpose of xref-find-regexp
> being able to search in the project file?
No. We should have project-root for tools that need a root directory.
xref-find-regexp needs a search path, not a root directory.
> If project-root is not in project-search-path, can there be other,
> unrelated files in that directory? How would we make sure
> xref-find-regexp ignores them?
xref-find-regexp searches project-search-path. project-search-path is
set by reading the project files. The project files are provided by the
user. Voila, xref-find-regexp does _exactly_ what the user wants, no
more, no less.
--
-- Stephe
- Re: Unified project interface, (continued)
- Re: Unified project interface, Dmitry Gutov, 2015/07/24
- 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 <=
- Re: Unified project interface, John Yates, 2015/07/26
- Re: Unified project interface, Dmitry Gutov, 2015/07/26
- Re: Unified project interface, Stephen Leake, 2015/07/27
- Re: Unified project interface, Dmitry Gutov, 2015/07/27
- Re: Unified project interface, Dmitry Gutov, 2015/07/27
- Re: Unified project interface, Dmitry Gutov, 2015/07/27
- Re: Unified project interface, Stephen Leake, 2015/07/27
- Re: Unified project interface, Stephen Leake, 2015/07/28
- Re: Unified project interface, Dmitry Gutov, 2015/07/28
- Re: Unified project interface, Stephen Leake, 2015/07/28