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

[Dmitry Gutov <dgutov@yandex.ru>]

On 01/24/2015 11:40 AM, Eli Zaretskii wrote:

>> The easiest example is code completion.  In emacs-lisp-mode, it will
>> parse the current buffer context and offer completions from obarray,
>> somewhat filtered. If you have a README in the same directory as
>> foo.el (so we might consider them to be in the same project), when
>> you open it, you definitely won't get the same completions as in
>> emacs-lisp-mode. In fact, if there's no current tags file visited,
>> in the default Emacs configuration you won't get any completions at
>> all.
>>
>> Similarly for python-mode (python-shell-completion-at-point only works
>> in Python buffers, and only when an inferior shell is running). Likewise
>> for Octave, and I just haven't looked at Guile, Awk and GDB support.
>
> I'm not sure what completions are alluded to here.  Completions are
> context-dependent, i.e. their DWIM-ish nature should depend on what is
> being completed, and for what purposes.

Code completion, like the first sentence says. Or completions for text, 
if we're talking about that README file.

Since external completion tools are usually already wedded to specific 
notions of projects, let's consider "all words in buffers" (a la 
dabbrev). Arguably, such completion source should use the words from all 
buffers belonging to the same project, as well as some limited 
dictionary that's applicable everywhere.

elisp-completion-at-point only considers the local buffer contents and 
currently loaded symbols (which if fine by me, but that exactly follows 
the pattern).

tags-completion-at-point-function, which is the default, has a different 
problem: it will be used in any buffer, even those not within the 
current tag file(s)'s subtree(s).

> For example, I hope you'd
> agree that it would be bad in general for completion in "C-x C-f" to
> show only files from the current project.

That's neither here no there. `find-file' is a plainly different function.

> By contrast, a specialized
> command that is meant to find files only from the current project
> should probably limit the candidates to the project.

Yes, and that's one feature that would use the current project. When 
used with a completing-read-function that provides some kind of fuzzy 
matching, it can be very handy: type a few letters and have the file you 
were thinking of at your fingertips.

Not so with the default completing-read, though.

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

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.

An extreme example, I'd say, is Icicles (sorry, Drew). Just looking at 
the documentation makes my head spin. And even if there can be 
situations in my life where I could use each option, I'd rather do the 
work manually rather than look for it, or generally live with an 
interface that does so many things at once.

> 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. The backend logic that 
xref uses is swappable, and an interested user can write their take on 
the indexing and navigation logic, then share their code, and other 
like-minded users will benefit. Some would be included in Emacs, and 
would be used by enabling a specific minor mode.