bug#22692: docstring for xref-find-definitions

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 22692@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 19 Feb 2016 15:01:46 +0200
> 
> On 02/18/2016 06:50 PM, Eli Zaretskii wrote:
> 
> > Failing that, the only band-aid I can offer is something like
> >
> >    Find the definition of the identifier at or near point.
> >
> > If you think it's better, we can make that change now.
> 
> Do we really want to codify that behavior? I've switched to use 
> find-tag--default because it seemed appropriate for the etags backend, 
> but the "near point" aspect looks fairly awkward to me, and I imagine 
> third-party backends might choose to omit it.
> 
> I'd prefer to use the more precise behavior in find-tag-default-bounds 
> as well. And if there's general agreement here, I wouldn't mind taking 
> care of that patch.

Making such a change is fine with me, thanks.

> > Did you use M-. in Emacs 24 and before?  Because that's exactly what
> > it did in this case, it would say this in the echo area:
> >
> >    Find tag (default 1):
> >
> > The reason is that this is what etags.el does when asked to find "the
> > identifier at or near point".  Patches to make it smarter are welcome.
> > (The relevant function is find-tag-default-bounds.)
> 
> Not necessarily. Every major mode that knows better should define its 
> own find-tag-default-function (but none do, so far). See the dispatch 
> inside find-tag--default.

If find-tag-default-function is also used by xref-find-references,
then it won't be TRT to reject constants up front.  A request to find
all the places where a certain constant is used is a valid use case.
It is indeed unlikely to have such a request for the constant 1, but
think about constants like 3.14159 or 3.0e+8.