Re: Unified project interface

[Dmitry Gutov <dgutov@yandex.ru>]

On 07/26/2015 02:22 PM, Stephen Leake wrote:

> Yes; any third party library that you should not edit, because the
> sources are controlled upstream.

Is it common to have its sources checked out in a directory nearby?

> Ok. I don't see the notion of "system directories" as important here;
> the important point is whether the libraries are read-only or
> read/write. We should not rely on where they happen to reside to decide
> that; sometimes I edit "system directories" when working on patches for
> upstream.

There is a difference, from my perspective: usually, there are no object 
files in system libraries, no build files, or .gitignore files.

> Or just ignore the read-only issue in the project code; file permissions
> are good enough.

Maybe ignoring that is fine (are we backtracking on the separation of 
the directories for the purposes of search and edit operations?), but 
file permissions won't help in a lot of cases.

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.

>> 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?

On the other hand, delegating the scan of the filesystem to 'find' seems 
performant enough. Someone correct me if I'm wrong, but most of the time 
is spent in Grep anyway.

> in the variable project-search-path. Then all code that searches
> projects is simpler; it deals with a simple list of directories, plus a
> list of file extensions (just as locate-file does).

locate-file seems to use a whitelist of suffixes, which is distinctly 
less powerful than with what's offered by .gitignore. I think keeping 
compatibility with it (and similar .bzrignore and .hgignore) is valuable.

> 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? That can be determined solely on the 
location of that file.

What will "included projects" look like, in an average Android project?

> 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.

If you've ever tried Projectile, it works in a similar fashion. Android 
projects could be detected like that as well.

> 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.

> 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.

> 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?

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?

Seems like any other tool that would use it would be specific to that 
kind of project (such as project file checker). Maybe the path to the 
project file should be set via metadata, using a key like ada-project-file.

>      note that the _only_ requirement here is that it is a single
>      absolute directory; the rest is just suggestions.

That's a problem, IMO. If project-root is loosely defined, it's not 
useful to third-party code that doesn't know much more about your kind 
of project.

And as per below, we're be including source directories from both the 
current project and the included projects into project-search-path, 
right? Seemingly on equal rights. But then, each of those projects 
likely has a .gitignore, a build file, and so on, but project-root will 
only return the location of project files for the current project? That 
seems inconsistent.

> project-search-path; a list of directories, containing files related to
> the project. This will normally include project-root. It may also
> contain included projects.

So, this tries to combine project-search-path and project-directories, 
as they're defined now? From the previous email, I imagined a 
project-specific project-search-path plus an accessor like 
project-dependencies, which would contain a list of project objects 
corresponding to the included projects.

>      this might want to be split into project-source-search-path,
>      project-object-search-path, but since Emacs is mostly interested in
>      editing sources, only the source path is interesting.

Right. I'd call it project-directories, though.