Re: Generalizing find-definition

[Jorgen Schaefer <forcer@forcix.cx>]

On Sun, 02 Nov 2014 21:22:03 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > The idea would be to simply swap M-, and M-*, so M-* would then be
> > `tags-loop-continue'.
> 
> I'm not sure what would be the benefit of such a swap.

The only benefit would be that M-, is now "go back after M-.", which is
what a lot of the packages that redefine M-. do to the key. Hence the
suggestion to swap the two keys, to unify that apparently rather
widespread use of M-,. If Emacs would prefer to keep M-, as is, that is
fine with me, too.

> What key-binding does SLIME use to get this list buffer (which would
> most naturally be implemented as a kind of grep/compilation-mode
> buffer)? Would C-u M-. be usable for that?

All of SLIME, slime-nav, Geiser and Cider use C-u M-. to prompt the
user for a symbol name to go to instead of using the symbol at point,
so that might be a useful generalized function if we do not need the
prefix for the "next" feature of etags.

> > ada-mode also has "show all references of name at point", which
> > currently pops up a buffer in compilation-mode, showing
> > compilation-style locations of all uses.  That's similar
> > functionality to find-tag/tags-loop-continue, and similar UI to
> > SLIME.
> 
> Sounds like we agree.
> 
> So on the UI side we mostly have:
> - "jump to *the* definition of thing at point".
> - "list definitions of thing at point".

Agreed. So far, I would say this is the same key binding (M-.)
which then either jumps to the definition if there is one, or lists them
if there is more than one.

> - "list uses of thing at point".

What key binding would you suggest for that? SLIME apparently uses M-_
and M-? (i.e. the key right of . in different keyboard layouts).

> - "return to buffer/position before the last jump".

Agreed.

> 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.

> - 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?

> 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.

Regards,
Jorgen