Re: Generalizing find-definition

[Helmut Eller]

On Sun, Nov 02 2014, Jorgen Schaefer wrote:

> Could you elaborate a bit on what you'd like to see for "a good UI"? My
> idea so far was to simply have modes provide a function that returns a
> marker or nil, while the function can check for interactive calls if it
> wants to, and use that in the usual go to location in same
> window/other window/other frame and go back. But I'm very open to ideas
> to make this better.

Let me define a bit of terminology that I use in SLIME: M-. parses the
"symbol" at point and then asks the external process to search a list of
"candidates" that match the symbol.  A candidate is a "location" with a
short description.  A location is a file:line:column triple (in the
simplest case).

The primary complication for a "good UI" is the case when there is more
than one candidate.

etags.el solves this complication by introducing the tags-loop-continue
command to cycle through the list of candidates (I think etags.el does
not compute an explicit list of candidates, but instead keeps a marker
in the TAGS buffer and tags-loop-continue will quite literally continue
the search starting from that marker).  I don't like this kind of UI.
It would be better to display the list of candidates instead of keeping
it hidden.

Displaying the list of candidates in an auxiliary buffer, make it easy to
select an interesting candidate and finally close the buffer is the job
of the UI.  Doing this well is not so easy.  I spent quite some time to
make it good in SLIME.  It's still not perfect, but IMO way better than
what etags.el offers.

Parsing the "symbol" at point for M-. will be language dependent and
some language may need to determine a lot of context (current
module/class/function etc.).  In SLIME, it's relatively easy as we only
need to determine the current package and then the symbol like in Elisp.
I think a "good UI" should, by default, determine the symbol around
point without asking each time (as find-tag does).

BTW: M-x rgrep needs to solve similar UI issues as it also needs to deal
with a "list of candidates".  Maybe there's an opportunity to
share/unify some things.

Helmut