[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Project support and completions (Was: Re: bug#19466: 25.0.50; xref-find-

From: Dmitry Gutov
Subject: Project support and completions (Was: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions)
Date: Sat, 24 Jan 2015 20:43:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]