[Top][All Lists]


Re: Generalizing find-definition

From: Dmitry Gutov
Subject: Re: Generalizing find-definition
Date: Tue, 16 Dec 2014 23:40:05 +0200

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

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

reply via email to

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