Re: Generalizing find-definition

[Jorgen Schaefer]

On Tue, 04 Nov 2014 08:46:33 +0900
"Stephen J. Turnbull" <address@hidden> wrote:

> Jorgen Schaefer writes:
> 
>  > 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.
> 
> Why not?

The "foo.Foo.baz" in this example would be an error at that point in
the program, and not all things that are defined have such a fully
qualified name in the first place. This all seems a bit
counter-intuitive for something called "identifier at point".

> Emacs's practical definition of "identifier at point"
> doesn't need to be the same as that of the programming language's
> grammar.  I have no trouble taking both points of view, although
> usually at different times.

I have no problem with that, either - we can call it Frobble, Blubber
or Moof, too, if we like. We use words so others understand us, and
redefining them more or less randomly is not helping with communication.

We have gone full circle and instead of asking "can an 'identifier at
point' be used to find the definition of the thing at point", we have
defined "identifier at point" to mean "that string (or object?) which
can be used to find the definition of the thing at point". Now that is
fine, mind you, we can use language however we like, but we will cause
quite some confusion with that.

For example, some people might think "oh hey, I have a function that
returns an identifier at point, and I am supposed to be able to pass
that string to the other function which returns the definitions of that
identifier. Let's write a function which receives an identifier and
returns where it is used."

But the way we defined "identifier at point", that does not necessarily
allow that.

Confusion all around just because we went for re-defining a term that
is usually used in other ways.

> In some sense, you always need full buffer contents except for the
> very simplest of programs.

Exactly. Which is why I'm saying that I do not see the need or use for
an indirection via a "get identifier at point" function for the
proposed library. Which is pretty much all I was trying to say up to the
semantics discussion on the number of ways we can define what
"identifier at point" could possibly mean.

So let's drop that idea and the semantics discussion.

Regards,
Jorgen