emacs-devel
[Top][All Lists]
Advanced

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

Re: Bad moves with xref-find-definitions


From: Dmitry Gutov
Subject: Re: Bad moves with xref-find-definitions
Date: Sun, 26 Apr 2015 18:20:13 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

On 04/26/2015 02:31 PM, Vitalie Spinu wrote:

What do you currently do if there are multiple matching definitions of
the "thing-at-point"? Prompt?

Show them all in the xref buffer. But if the backend is smart enough, it will include the disambiguating context information as text properties on the "thing-at-point" string.

That kind of string (probably) can't be present in the completion table, though.

All I was trying to say is that tags are commonly useful alongside
dynamic backends. Blindly replacing tags with an even very good backend
is not the right direction IMW. Expecting from end users to solve this
problem with add-function :before is unacceptable if there are way to
fix it at Emacs level.

It doesn't have to come down to users. Completion packages could take care of it as well.

As to prompting, if you try to accommodate multiple backends, then
merging completion candidates from multiple backends is a simple task
when you prompt.

Not if you want to avoid duplicates. Currently, file opening and nagivation to the exact positions is being done lazily (which improves overall performance quite a bit). So you can simply call `delete-dups' on the xref elements when they come from different backends.

If you try instead to "bypass the minibuffer" it's
likely to be a much more difficult task.

How does it make any difference?



reply via email to

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