Re: Project support and completions

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 25 Jan 2015 01:25:12 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
>     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.

I'd be surprised if they didn't already.

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

I agree.

However, for the purposes of this discussion, all that is needed is
for xref to expose some interface that would allow a project API to
tell xref which databases to use.  Then this interface could be used
even if no project system is in use, from user-level commands or other
features.

The important aspect of this is that at least in some situations the
set of databases to use for symbol completion should be dictated by
some code outside xref that uses an interface provided by xref, and
not necessarily inferred automatically.

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

Then this mode should also be provided.  But since it has inherent
limitations, it cannot be the only one.

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

What do you mean by "unrelated" and by "separate" here?

Suppose there's some bug when Emacs calls a GnuTLS function.  Does
working on both of them trying to solve the bug makes them "related"?
Do you agree that being able to browse and complete on symbols from
both of them might be very useful in this use case?

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

Such automatic inference is not easy.  Library dependencies come in
several forms: linking in a Makefile, dynamic loading in the sources,
dependencies in pkg-config style *.pc files, etc.  Also, some
libraries depend on other libraries.  Discovering all those
dependencies sounds like a non-trivial project to me.

More importantly, most of the time when I work on the application, I
don't care about symbols in the libraries used by an application.  So
doing what you suggest would fill my "namespace" with many symbols I
don't care about and don't want to see as completion candidates.  As
an extreme example, consider libc, the Standard C library, which any C
program uses, or the Standard C++ library.  Is it really a good idea
for xref to offer all those when the user types 'M-.'?

OTOH, when I work on an interface between the application and a
library, then I do want the symbols of that single library to appear
as completion candidates.

Once again, I don't think this can be resolved automatically in a
satisfactory manner, at least not in all important use cases.  So a
provision for manual instruction by the user is still required, IMO.