Re: Generalizing find-definition

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/16/2014 10:42 PM, Helmut Eller wrote:
> Not everything needs to be entered by the user.  The namespace part
> could comes from the buffer (inferred)

But what if they want to jump to a symbol defined in a different 
package/namespace?

I would imagine that jumping to a symbol in the current package would be 
relatively infrequent (in one-file-per-class languages), or at least not 
as important (in other languages, where Imenu probably covers that).

Admittedly, if the language requires all used external symbols (classes, 
or functions) to be declared at the top of the file, for all symbols 
mentioned in the current file "jump to definition" could just be based 
on the local name (maybe imported alias) and the name of the current 
unit of computation (package or class, like in Java), but that discounts 
all symbols that aren't referenced in the current file.

I think allowing to jump to an arbitrary symbol (not just the one near 
point, or even in the same package) is the main goal for the identifier 
completion table.

 > and the user shouldn't be forced to type fully qualified names.

Ideally, right. We want to offer the user defaults for both the package 
part (current), and the symbol name (symbol at point), both of which the 
user could override conveniently.

But maybe offering current.package/symbol-at-point as one default value, 
in one completing-read invocation, would be good enough?

The benefit of a backend being able to decide to call `completing-read' 
twice is being able to cleanly offer these two defaults, separately.

The drawback: personally, I can't really choose which part to prompt for 
first. The best result probably depends on whether the user is looking 
for a symbol (and isn't sure about the package), or knows the package 
and wants to explore the symbols it it.

If we're completing both a the same time, the user can choose which part 
to edit, with completion. I'm not sure, though, if the backend would be 
able to actually filter completions for the first part (package) based 
on the text of the second part (symbol name) thus far entered. But 
that's an implementation detail.

To recount, here are arguments in favor of having identifier completion 
table as a part of the backend API, from the older discussion:

- Partial-completion style will let you complete "js.fo" to anything 
that matches "js*.fo*".

- It means the UI can use it for various kinds of completion (e.g. for
completion-at-point-function).

- ...the general rule that the backend should not do UI tasks and 
prompting is definitely a UI operation.