[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: Sun, 26 Jul 2015 20:23:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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.

reply via email to

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