Re: Generalizing find-definition

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/11/2014 10:09 AM, Helmut Eller wrote:

> Looks pleasantly non-verbose.

Thanks, that was one of the goals.

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

That's an option. But if we require that for every action, it'll 
increase verbosity. We only care about the distinction between nil and 
"nothing" in `identifier-at-point', so far, so that would be suboptimal too.

If we have a separate identifier-at-point-function, like Stefan wrote in 
the other message, this problem largely disappears. Kind obvious, in 
hindsight.

>> 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.
> ...
 > Too bad that classes can't be autoloaded.

Right. I don't have a better suggestion here, sorry.

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

Not necessarily. The user-facing part of the API is plain functions now, 
and they can also use the xref-make-*-location function without really 
caring what they return. It's only when a user wants to add new location 
types they will really need to use the EIEIO API.

But of course, it would have to be loaded at runtime.

>> * 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 that gives it too much responsibility. What do we want from a 
location? Chiefly, a buffer-position pair.

* We don't need separate location-buffer and location-position 
accessors. Let's just have a method that returns a cons.

* Bogus locations will return nil and show a message. Or maybe signal an 
error, if you like. We can define a special kind of error, 
`xref--show-location' (a plain function) will catch it and display the 
error message, if it's so inclined. Another option is a special return 
value, like (:error . "Boo hoo").

Together with xref-location-group, this leaves just two methods. And 
without that one, it could be implemented as something like a future, I 
guess.

>>    I think `xref--show-xref-buffer' is
>>    also suspect at this stage of implementation.
>
> I'm not sure what you mean.

I mean it's fine as a possibility, but we don't have any other 
implementations, and thus don't really know what API they'd require.

If it were up to me, I'd remove it, to maybe bring back later, after the 
presently discussed feature is settled, and Stephen has experimented 
with a compilation-mode implementation.

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

Ok, maybe. It should provide some definite benefit, though, over just 
doing (funcall xref-show-xrefs-function xrefs).

> Using closures as objects is always possible but rarely desirable.

Instead of a (usually opaque) closure, it could be a struct with a 
function reference (usually symbol) and an arguments list, which would 
be passed to it together with some changing argument. That would be 
quite transparent.

But anyway, I don't mind using EIEIO either.

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

I guess that would just mean another action for the 
xref-backend-function, in terms of the API?

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

Similar, yes. With completion-at-point, the backend sees the current 
buffer and point, but also the completion table can determine where in 
the buffer the current "prefix" begins, which is usually important for 
external tools.

If the identifier-at-point is just a string (or some value that can be 
derived from a string), that would be limiting.