|
From: | Dmitry Gutov |
Subject: | bug#19468: 25.0.50; UI inconveniences with M-. |
Date: | Fri, 1 May 2015 17:51:14 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 |
On 05/01/2015 03:57 PM, Eli Zaretskii wrote:
Sorry, I don't understand what "Elisp environment at runtime" means in practice, or how it's used to affect what results are returned for a query.
find-func knows about defined functions and defined variables. elisp-mode knows that a function usually goes after a paren, and a variable - after a space (to simplify things).
Thus, elisp-xref-find could narrow the search space based on whether there is a paren before the symbol at point (we don't do that, partially because the situation is more complicated; but we should, in the future). A language-agnostic UI won't ever be able to do so.
That's the case where the UI should instruct the back-end what it needs, because the back-end doesn't know which of these alternatives is the right one. If the user wants all bar functions, or maybe those whose parent class matches some regexp, not just the one from the class instance at point, then producing only one match would be wrong, and the UI won't be able to correct that.
If the user calls xref-find-definitions, we consider that to see the definition of the function called at point (or definitions, if virtual dispatch is unavoidable, such as in case of a Java interface, and there are several options), but not more.
For more lax matching options, the user will call xref-find-apropos.
[Prev in Thread] | Current Thread | [Next in Thread] |