Re: Generalizing find-definition

[Stefan Monnier]

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

This said, one of the benefits of the generic functionality you're
suggesting is that users can easily rebind those commands and know that
this will affect consistently all packages providing the functionality.

>> M-. RET  does "find the callers of a symbol at point", AFAICT.

Duh, sorry for being dense, of course it doesn't.  etags does not offer
the needed info, so the etags.el UI doesn't have such a thing.

Helmut Eller <address@hidden> writes:
> bind it at all.  SLIME will definitely keep the M-./M-, pair, well
> knowing that it's incompatible with the binding for tags-loop-continue.

When SLIME uses the new functionality it should mess with its key
bindings at all, so the user can more easily make global changes to
those key bindings.

> In my experience, tags-loop-continue is rather hard to use and I have
> long argued to get rid of it and replace it with a better UI.
> E.g. tags-loop-continue must be pressed multiple times just to find out
> at the end that none of the offered candidates was relevant.  SLIME does
> it differently: the list of all candidates is displayed in a separate
> buffer with one candidate per line; a bit like the results of a search
> engine like Google.  The user must then move the cursor to the
> interesting line and press RET to actually jump to the definition.  If
> there's only a single candidate, then there's no need to display the
> list and we can jump to the candidate right away.  SLIME has no analog
> to tags-loop-continue (and no key binding for it) because it's not
> needed; at least nobody ever asked for such a command.

I agree that tags-loop-continue is not super convenient.
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?

> 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".
- "list uses of thing at point".
- "return to buffer/position before the last jump".

And on the backend side we have:
- identifier-at-point-function
- find-definition-function (with an argument to decide whether we want
  a whole list or just the best/first candidate).
- find-uses-function

Etags.el currently offers some additional functionality:
- jump to definition of any identifier, with TAB-completion.
- jump to file (among those listed in the TAGS file), tho currently
  without TAB-completion.
AFAICT, the first could be implemented just in the generic code, except
for TAB-completion.
And the second one is also provided by things like projectile (among
many other thingies), tho it seems that none of the bundled Emacs
packages provide a good solution for that common need.


        Stefan