Re: Unified project interface

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi Stephen,
>
> Sorry for the delay; I had to think on it.
>
> On 07/25/2015 03:55 AM, Stephen Leake wrote:
>
>> I would suggest the terminology "main project" vs "included projects"
>> for this; the "main project" is the code you own; the "included
>> projects" are all the others (included the system includes).
>
> There's sense in this, but is "an included project you don't own,
> which is not in system includes" a significant use case?

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

> In my own experience, either the projects on which the current one
> depends are installed in system directories, and thus are
> indistinguishable from system includes (such as Ruby gems, installed
> via "gem install"), 

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. 

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

>> should think at some point in the implementation of any "search project"
>> function you will want an explicit list of directories (and maybe files)
>> to search, which will be the union of project-search-path minus
>> project-ignores. So it seems simpler to specify that list directly.
>
> 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
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).

>> The user interface (the syntax of the project file) could be structured
>> as includes and ignores (excludes).
>
> .gitignore also supports whitelisting entries (which override the
> excludes). I haven't gotten around to writing support for those.

Right. .gitignore is part of "the project file" in this sense.

>> Recently I've been playing with Google's Android Studio (shudder; only
>> to make Emacs do what it does, I promise :). It defines a project root
>> by a dominating file.
>
> Of course. Why else one would be playing with it? ;)
>
> In this case, project-directories can return a list with one element.

No, Emacs needs to read the Studio project file and extract the search
path; it's just another project file syntax.

>> On the other hand, AdaCore GPS (an Ada-specific IDE) defines a project
>> by a project file that specifies various lists of directories (source,
>> object, executable); there is no root directory. The project file itself
>> can be anywhere, it doesn't have to be in one of the listed directories.
>> That's what Emacs Ada mode does as well.
>
> In this case, it seems, the relevant project implementation will be
> based on user explicitly telling it where the project file lives (by
> calling a particular command, with a prompt), and then the project
> will be enabled globally, for the whole Emacs session.

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.

> Would there be any significant value in project-root returning the
> directory of the project file?

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. 

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.

>> I think they are disjoint concepts. Nothing wrong with keeping both;
>> some tools will need them, some won't.
>
> That would mean documenting the distinction, so that implementers know
> what to do. I'm increasingly less clear on it.

project-root; a single absolute directory, usually containing
significant files for external tools (ie .git/), often the root of the
source tree.

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

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.

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