Re: Generalizing find-definition

[Stephen Leake]

Drew Adams <address@hidden> writes:

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

Not in my use case.

I'd like to have one "goto ref" key that Does the Right Thing as much as
possible. That way I don't have to remember different keys for different
cases. 

> Doesn't a user know what kind of thing definition s?he wants
> to look up?  

Yes, but I don't want to _also_ have to know which key to invoke.

> Does s?he really need Emacs to guess what kind of thing is at point 

Not "guess", no. Determine precisely, yes.

> (a guess that is fraught with ambiguity)?

If Emacs can't figure it out, put up a list of possibilities, or report
error.

This works very well for me. I have three related keys for this kind of
thing (Emacs isn't quite as intelligent as I'd like yet);

C-c C-d for symbols, whose behavior is mostly determined by the
compiler generated cross reference info; now bound to
'xref-find-definitions'. 

C-F11 for files, whose behavior is determined by parsing the string at
point, influenced by the major mode. Mostly a wrapper around
ff-find-the-other-file.

C-F12 whose behavior is totally determined by parsing the string at
point or active region, via an alisp of regexps. Sometimes the
"at-point" version does the wrong thing; then the "active region"
version does what I actually want (and vice versa).

I started the current discussion (I changed the Subject line) to cover
implementing the C-F12 functionality in a more general way, or just make
it available in Emacs core or an ELPA package.

It might also make sense to make the C-F11 functionality available in
Emacs core.

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

Thing-at-point does that pretty well, and xref-identifier-at-point
provides a way to extend that.

I'm talking about what to do with the string after we get it, and to
some extent UI design to give more information to Emacs about what to
get and what to do with it (at point vs region, for example).

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

This might make sense, but that requires being in a prompt in the first
place; I try to avoid that whenever possible.

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

We disagree; that's fine.

-- 
-- Stephe