[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Generalizing find-definition

From: Dmitry Gutov
Subject: Re: Generalizing find-definition
Date: Fri, 12 Dec 2014 00:52:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]