[Top][All Lists]

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

Re: Generalizing find-definition

From: Stefan Monnier
Subject: Re: Generalizing find-definition
Date: Mon, 03 Nov 2014 15:09:40 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> For Python, there is nothing suitable for "identifier at point" that I

Yet, you say that you offer a tab-completable selection of identifiers.
So obviously, there is a suitable "identifier at point".

Do you mean by the above not that the concept is meaningless but that
it's difficult to write a function that reliably returns the appropriate
identifier at point?

If so, I can definitely agree that for some modes it can be difficult,
and it should not be necessary to write such a function if the backend
can use a buffer-position instead (and delegate the hard work to some
external tool).

But having such an identifier-at-point-function can be useful for all
kinds of things (typically default for minibuffer inputs of various
commands), so it makes a lot of sense to standardize it.

> For Python, I do provide a tab-completable list of identifiers
> (currently only for pydoc, but the code should be reusable for this),
> but it is not a simple list of identifiers, but a tree. The tab
> completion starts with top-level modules (like "json"), but when you
> add a ".", it will continue to complete attributes of the module or
> class etc.. Providing the full list of possible completions right
> away would take a very long time.

Of course.  But such completion is nothing new.  File names are
completed this way.  Bzr revision names are completed this way as well.
No need for a special completion command, you can do that just fine with
just a completion-table (and then partial-completion style will let you
complete "js.fo" to anything that matches "js*.fo*").

Note that such completion tables are clearly not lists of strings, but
they're functions (actually, they're objects represented as functions,
for lack of an object system).

> This is getting extremely complex and I do not see how this would
> benefit the user much.

As long as the "set of use-kinds" and the "set of identifier categories"
is determined by the backend itself, I don't think it increases
complexity of the backends or the backend API very much.

And there are clearly example of existing systems which do provide such
refinements (e.g. find-variable vs find-function on Elisp, and the C-c
C-w s versus C-c C-w b versus C-c C-w r in SLIME), so it makes sense to
include it in the design of the backend API.

> There are definitions of an identifier, and uses of an identifier.

Yes, clearly this is the main distinction and we should focus on this
functionality w.r.t designing the UI.


reply via email to

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