Re: Generalizing find-definition

[Helmut Eller]

On Thu, Dec 11 2014, Dmitry Gutov wrote:

> Ok, thanks. The modified proposal attached.

Looks pleasantly non-verbose.

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

Maybe you could switch the roles around: return :not-implemented when a
backend has no implementation and make nil an ordinary return value.

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

A cache or a socket connection to an external indexer could reasonably
be stored in a slot of a backend object.  But that is as far as my
imagination goes.

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

Good idea!  Hadn't thought of that.

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

Which kinda defeats the argument that API users shouldn't have to know
EIEIO.

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

You're probably right.

> * What is `xref--show-location' for? Why do we want to allow certain
>   types to override this behavior?

xref-bogus-locations had to be handled somehow and using a GF is just as
good as a if/typecase statement.

>   I think `xref--show-xref-buffer' is
>   also suspect at this stage of implementation.

I'm not sure what you mean.

What I can see is that xref--show-xrefs should be have a cleaner arglist
and be part of the API, because there will be language specific commands
that would like to reuse the UI.

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

Using closures as objects is always possible but rarely desirable.

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

ert-run-tests-interactively uses quotes to distinguish regexps from
symbols.  But I agree: a generalized apropos might be better than
forcing regexps into find-definition.

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

It seems to me that this situation is similar to a completion-at-point
command that asks an external process for possible completions.
Something that existing packages often do.  Despite that, nobody can
foresee all problems; instead we fix them as they come along.

Helmut