RE: Generalizing find-definition

[Drew Adams]

> A problem seems to be that xref-identifier-at-point would need a
> possibly complicated heuristic to determine if we are at such a
> filename or a "normal" identifier. Maybe it's easier to have a
> separate xref-file-name-at-point which would by default do what
> ffap-guess-file-name-at-point does.  For ELisp it should
> additionally recognize (require 'foo) and somehow reuse find-library.

And..., and somehow..., and..., and somehow...

In general, this is the wrong approach, I think.

Q. When does reuse of a file name or a URL or... at point make
   sense?
A. As input to a command that acts on a file name or a URL or...

The *particular command* already knows what kind of thing it
expects.  All that's needed, as a *general* mechanism, is a
general way to pull text at point into the minibuffer.

That's where the design effort should be, IMO.  And this
mechanism should be entirely decoupled from any particular
use of the grabbed text.  That's my main point here.

In particular, `find-definition' itself might be misguided.
I cannot really speak to whether it is, but that's my hunch.

Doesn't a user know what kind of thing definition s?he wants
to look up?  Does s?he really need Emacs to guess what kind
of thing is at point (a guess that is fraught with ambiguity)?

The problem comes down, I think, to providing a key (or keys)
that will *grab what the user wants at point*.

We should then bind that key in `minibuffer-local-map' so that
it is available *always*, regardless of the minibuffer-reading
command and the particular way of reading (with completion or
not, and for any kind of completion).

There is room for imagination and invention here, and that is
where the effort should be placed, IMHO.

Let's suppose that we start by trying for just a single key -
`M-.', for instance.  Clearly, adding more "grab" keys would
make it easier for a user to make known to Emacs what to grab,
but it would also make users know more keys etc.  We can always
add more.  Let's see what can be done with one, for starters.

As food for thought, here is a description of what `M-.' does
in Icicles, from the minibuffer.  I don't claim that this is
the full solution - at all.  As I said, I think there is plenty
of room for invention, to come up with good ways for a user to
tell Emacs what thing(s) to grab at point.

Icicles currently uses a single key, `M-.', to grab stuff into
the minibuffer from point.  You customize what your general
preferences are in this regard.

The choice you make is whether repeated use of `M-.' should,
by default, grab (a) additional stuff of the same type or
(b) alternative stuff of different types (i.e., replacing,
in the minibuffer, what the previous invocation grabbed).

You can override your general preference (alternatives vs
more-of-the-same) on the fly when you use `M-.', by
providing a prefix arg.

For example, if you generally prefer that repeated `M-.'
grab different kinds of thing at point (default behavior),
then `C-u M-.' switches the behavior temporarily so that
repeating `M-.' grabs successive occurrences of the same
kind of thing.

There is additional, more complex behavior available as
well.  You can customize the sequence of functions used to
grab different kinds of thing.  You can grab successive
things of the same type to the left or to the right of
point.  You can grab alternative things at point and
insert not the grabbed text but the result of evaluating
it as a Lisp sexp.

This page describes the behavior of `M-.' in Icicles:
http://www.emacswiki.org/Icicles_-_Inserting_Text_from_Cursor
And this part describes the details outlined above:
http://www.emacswiki.org/Icicles_-_Inserting_Text_from_Cursor#RepeatedM.

To be clear, I am not at all proposing this same behavior
for Emacs.  I point to it as food for thought.

What I am suggesting is only this:

1. It makes sense to concentrate on coming up with a
   useful, general-purpose grab-text-at-point minibuffer
   command, not with a general-purpose `find-definition'
   top-level command.

2. What Icicles does in this regard might serve as some
   food for thought.  But there are surely more and
   better possibilities.

3. Everything useful need not be combined in a single
   minibuffer command (such as Icicles tries to do with
   `M-.').  Having different, easily understood behaviors
   on separate keys can also be a good way to go.

HTH.