Re: Generalizing find-definition

[Jorgen Schaefer <forcer@forcix.cx>]

On Mon, 03 Nov 2014 15:09:40 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > For Python, there is nothing suitable for "identifier at point"
> > that I
> 
> Yet, you say that you offer a tab-completable selection of
> identifiers. So obviously, there is a suitable "identifier at point".

The tab completion I talked about is for global modules and their
contents and has no access to locally-available identifiers. It is a
feature completely unrelated to finding the definition of the
identifier at point.

> Do you mean by the above not that the concept is meaningless but that
> it's difficult to write a function that reliably returns the
> appropriate identifier at point?

I suspect we mean the same thing, but just to clarify.

Consider a piece of code like this:

    from foo import Foo

    bar = Foo()
    bar.baz_|_

M-. should go to the definition of the attribute baz of the class Foo.
But the obvious "identifier at point" is "bar.baz", which by itself
does not have any relationship to said method without the assignment
"bar = Foo()", which by itself is also not meaningful without the
import statement. The only single string that reliably would allow to
find the correct definition would be "foo.Foo.baz", but I do not think
that anyone would consider that to be "the identifier at point" here.

So what I am saying is that the only representation for "the identifier
at point" that allows finding the definition of said identifier is the
triple (file name, full buffer contents, position within the buffer
contents). There is no simpler "identifier at point".

> If so, I can definitely agree that for some modes it can be difficult,
> and it should not be necessary to write such a function if the backend
> can use a buffer-position instead (and delegate the hard work to some
> external tool).
>
> But having such an identifier-at-point-function can be useful for all
> kinds of things (typically default for minibuffer inputs of various
> commands), so it makes a lot of sense to standardize it.

Emacs can and probably should standardize it, but unless it is useful
for the interface of finding the definition of the thing at point, it
would seem like a good idea not to do it in the library being discussed
here.

> Note that such completion tables are clearly not lists of strings, but
> they're functions (actually, they're objects represented as functions,
> for lack of an object system).

What is the advantage of having the backend define a function that
returns a completion table as opposed to a function that prompts the
user for a symbol? The saved code seems minimal, and it means the
backend can not set the prompt, for example.

Regards,
Jorgen