Re: Generalizing find-definition

[Stephen Leake]

Jorgen Schaefer <address@hidden> writes:

> Stefan Monnier <address@hidden> wrote:
>
>> And on the backend side we have:
>> - identifier-at-point-function
>
> Why do we need this? It does not make much sense for this functionality
> in languages with combined identifiers. For example, in Python,
> "foo.bar()" can be pretty much anything, it depends heavily on the
> context. Libraries for introspection expect a position in a file/buffer,
> not an identifier, to find the definitions.

ada-mode has ada-identifier-at-point; it returns a string suitable for
the external cross-reference engine.

On the other hand, 'ada-goto-declaration' (which would be used for
'find-definition-function') calls ada-identifier-at-point (and similarly
for other cases), so I don't think this needs to be split out as an API
function.

>> - find-definition-function (with an argument to decide whether we want
>>   a whole list or just the best/first candidate).
>
> I am not sure if it is generally easily possible to sort the list of
> candidates like that. I guess tags often has the problem of knowing
> more than one possible candidate, so it would be preferable for tags to
> default to a single destination?

I don't ever want the back-end to guess for me without giving me the
option to override; if there's a list, I want to see it, either as an
icomplete style completion list, or in a buffer.

If the backend can put some order on the list (last used is usually
good), that is fine.

>> Etags.el currently offers some additional functionality:
>> - jump to definition of any identifier, with TAB-completion.
>
> C-u M-. could call a separate function when set, which would be
> provided by the mode author to prompt for an identifier (with tab
> completion if possible) and goes to the definition of that symbol.

It might also be useful to have find-definition-function take an
optional 'identifier' argument. Then other code that finds identifiers
could use it.

-- 
-- Stephe