[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 06:22:34 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) |
Dmitry Gutov <address@hidden> 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
- 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 <=
Re: Unified project interface, Dmitry Gutov, 2015/07/26
Re: Unified project interface, Stephen Leake, 2015/07/26
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