emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

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