Re: Generalizing find-definition

[Dmitry Gutov]

Helmut Eller <address@hidden> writes:

> I don't mind.  Rewrites welcome!

Ok, thanks. The modified proposal attached.

To be honest, now I can better see the appeal of using the classes here.
For instance, in the modified API a backend has to return `:none' in its
identifier-at-point implementation if not found, because otherwise the
default implementation will be called (and it's hard to implement the
overriding otherwise).

Although we could use a plist (or alist) instead of a
function-with-multiple-calling-conventions.

Suppose we end up using your implementation, do you think there could be
a reasonable case where a xref-backend-function creates a non-trivial
instance of its backend class, with instance vars, etc? Because
otherwise it'll remain an odd wart. Then the variable can just hold the
class symbol, and instantiation can be performed on-demain, or even each
time it's used: it's cheap anyway.

> Actually, the location stuff was the primary reason I started using
> EIEIO.  In SLIME we have quite a zoo of location variants (not based on
> EIEIO), e.g. file+byteoffset, file+charoffsets, search-strings, and
> something that we call "source-paths".  A source-path describes a path
> in the SEXP tree; sounds weird but works surprisingly well for Lisp
> syntax.
>
> Just want to say that locations should be very flexible.

Right, I can see how EIEIO can be useful in this case, so this is the
part I mostly left untouched, for now. However, it could be simplified:

* I'm pretty sure the default implementation of `xref-location=' will
  cover 99% of all cases.

* There's no real need for the above and `xref--unique-location'. We can
  just require the implementations to return lists without duplicates. I
  would think that most would do that even without being asked.

* What is `xref--show-location' for? Why do we want to allow certain
  types to override this behavior? I think `xref--show-xref-buffer' is
  also suspect at this stage of implementation.

`xref-location-group' is quite neat, though. But depending on whether we
really want to make this lighter-weight, the class hierarchy here can be
replaced with some ad-hoc polymorphism (so we could say that a location
can either be a (buffer position) (file line column), or, say, a closure
for the most general case).

-

I kept `etags--xref-read-identifier', but I don't particularly like it:
in other places, when we want to use a regexp, that's usually a
different command, or a prefix argument, etc. Inputting quotes to make
the contents work as a regexp is... odd.

-

The "identifier at point" and "read identifier" makes me wonder how it
would work with more complex languages, where we delegate a lot of logic
to an external server process. Will a two-request workflow become usual?
First ask the server what's at point, and then send it back with a
specific question. I guess some existing packages would be hard to adapt
to that.

-

We should probably port Jorgen's tests.

xref-plainer.diff
Description: Modified xref proposal