[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 07:05:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 12/11/2014 05:07 PM, Stefan Monnier wrote:

    (add-function :around (local xref-backend) #'elisp-xref-backend)

Okay, thanks for the reminder about nadvice.

I guess with this approach to function inheritance, there would be a different, bare-bones default value of xref-find-function, because I don't think I want to delegate to etags-xref-find from elisp-xref-find (and all other backends).

Anyway, having a separate xref-identifier-at-point-function should solve this problem in a different way.

This should be called `xref-backend-function', to follow usual practice.

Right, thanks.

Rename xref--xref to xref-xref, since it's clearly part of the API.

Or we can keep the class name private, and document that the function should return a list of xref values, using `xref-make'.

A few comments:
- As discussed earlier, `read-identifier' is probably a bad idea.
   Replace it with a `completion-table' method, so the completing-read is
   not in the backend but in xref.el.

Ok, apparently I missed some things in the older thread.

- identifier-at-point should document more clearly that the return value
   may be something else than a string.  AFAIK the only interesting
   non-string non-nil case is to return a special value (e.g. a marker
   or just `t' to stand to (point)) which stands for "let the
   find-definitions code figure out the identifier at that place".
- If we restrict identifier to "a string or nil or t", then we can get
   rid of identifier-to-string.

All right, let's go with this, until a better idea comes up.

But note that AFAIK 99% of the time the identifier at point and prefix+suffix used by completion-at-point will be one and the same. Maybe it will make sense to unify these: for example, by naming the function identifier-bounds, and requiring it to return the beginning and the end of the identifier.

This pair of numbers (or maybe markers) would be useful to both find-definition functions that expect a string (just call buffer-substring beforehand), as well as those that need a buffer position.

   a single backend function, but adding the other methods makes it
   scream "I want to use OO", just like completion-tables do.

I wasn't aware they're considered a bad design already. :) That API is complicated, but not just because a function has many calling conventions.

   then we need to split `xref-backend' into several variables:
   - xref-find-function (can be used both for the `definitions' and for
     the `references').
   - xref-identifier-at-point-function.
   - xref-identifier-completion-table.

Ok. (I should send the updated patch tonight).

reply via email to

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