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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 24 Jan 2015 20:43:02 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel <emacs-devel@gnu.org>
> 
> > Likewise with symbols -- when the user wants only symbols from the
> > current project, or from the programming language of the current
> > buffer, that's what Emacs should show.  But there are also situations
> > where such limitations produce bad results.
> 
> Personally, I consider that handwavy thinking a problem. We can't 
> support each and every approach and expect the user not to be 
> overwhelmed trying to remember and be able to use all of them.

If we succeed in parameterizing the space of possible approaches, and
let users specify what parameters they want, then yes, we can.

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

> Even if situations where given limitations are bad can exist, as long as 
> they are rare enough, we can sacrifice certain edge cases if what's left 
> is a coherent, simple user interface.

If we must.  But I don't think this situation is one of those cases.
I think simple yet powerful solutions are at hand here.

> > The important point is we cannot limit the user to just one possible
> > context, even if it is the most frequent one.  Such a feature would be
> > too limited.
> 
> Ideally, we should provide extensible interfaces.

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