Re: Project support and completions (Was: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions)

[Dmitry Gutov]

On 01/25/2015 12:26 AM, Eli Zaretskii wrote:

> For example, it sounds to me that by having an "add project" and
> "remove project" commands, we can give the user the ability to tell

A specific project solution could provide those commands.

> which projects' databases of symbols are relevant to what she is doing
> now.  Then Emacs can select completion candidates from the list of
> projects currently in the active set.

This introduces a new constraint on the potential "project" API. While 
we want to be able to list files or buffers (and maybe do something with 
their contents) from all current projects, there are commands in 
Projectile that necessarily work just on one directory, such as:

- Visit project in Dired.
- Run a build tool, ag, grep, or any plain shell command in root.
- Run vc-dir in root.
- (Might or might not also fit the description) Regenerate tags.

So the project API either has to be able to designate one project as the 
"main one" while implementing "list all files" differently, or 
dynamically look up the real current project root, to use in those commands.

> Such a paradigm will not
> overwhelm users, since knowing which packages one is working on at any
> given time is something we all do anyway.

I believe some would still prefer just having it inferred.

> Ideally, the popular extensions should already be there.  Working on
> several packages at the same time is not an uncommon use case.

If the projects are unrelated, personally I'd rather keep them separate.

Or, in the example you've given before (application and a library it 
uses), at least with certain languages/environments the project solution 
could automatically infer all the libraries used by the current 
application, as well as their current sources, from the project file. 
That would make add-project and remove-project commands unnecessary, 
leaving only select-project.