Re: Generalizing find-definition

[Dmitry Gutov]

Stefan Monnier <address@hidden> writes:

> That's the idea behind using the value t as an "identifier at point".
> It seems like a reasonable constraint on the use of
> xref-find-definitions.

Here's another example why we could reconsider using simply t or marker
as a return value there:

- Suppose, for the current backend, xref-identifier-at-point-function
  never returns strings, as described.

- User calls `xref-find-definitions' with a prefix argument, this
  triggers completing read, but we can't use anything as the initial
  input.

For a popular OOP language, the identifier completion table might
contain entries like "package.Class#method", and if the point is on
"foo.method", and if completion doesn't require prefix matching, having
"method" as the initial input would save the user some typing.

Anyway, updated patch attached. Aside from what was already discussed,
the changes are:

- Added `xref-find-apropos' and its implementation in the Etags backend,
  as a replacement for reading and jumping to a "regexp identifier".

- `xref-identifier-completion-table' ->
  `xref-identifier-table-function'. Apparently, it should be a function
  returning a completion table, for the same reason as why
  `tags-lazy-completion-table' exists. Please correct me if I'm wrong.

xref-find-function.diff
Description: Plain function API with EIEIO locations