From: Helmut Eller <eller.helmut@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Generalizing find-definition
Date: Thu, 11 Dec 2014 09:09:51 +0100 [thread overview]
Message-ID: <m21to6ehf4.fsf@gmail.com> (raw)
In-Reply-To: <86ppbqn841.fsf@yandex.ru> (Dmitry Gutov's message of "Thu, 11 Dec 2014 06:06:06 +0200")
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
next prev parent reply other threads:[~2014-12-11 8:09 UTC|newest]
Thread overview: 172+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-02 14:15 Generalizing find-definition Jorgen Schaefer
2014-11-02 15:34 ` Stefan Monnier
2014-11-02 16:29 ` Jorgen Schaefer
2014-11-02 18:14 ` Helmut Eller
2014-11-02 18:35 ` Jorgen Schaefer
2014-11-02 19:51 ` Helmut Eller
2014-11-02 20:17 ` Jorgen Schaefer
2014-11-03 2:22 ` Stefan Monnier
2014-11-03 7:03 ` Helmut Eller
2014-11-03 7:44 ` Jorgen Schaefer
2014-11-03 14:17 ` Stephen Leake
2014-11-03 14:30 ` Stefan Monnier
2014-11-03 18:28 ` Jorgen Schaefer
2014-11-03 20:09 ` Stefan Monnier
2014-11-03 20:55 ` Jorgen Schaefer
2014-11-03 22:38 ` Stefan Monnier
2014-11-04 14:52 ` Stephen Leake
2014-11-04 18:12 ` Stefan Monnier
2014-11-04 23:13 ` Stephen Leake
2014-11-05 2:00 ` Stefan Monnier
2014-11-06 15:33 ` Dmitry Gutov
2014-11-06 19:40 ` Stephen Leake
2014-11-07 2:57 ` Yuri Khan
2014-11-07 20:56 ` Dmitry Gutov
2014-11-03 22:39 ` Stefan Monnier
2014-11-04 14:58 ` Stephen Leake
2014-11-03 23:46 ` Stephen J. Turnbull
2014-11-04 7:58 ` Jorgen Schaefer
2014-11-04 2:52 ` Yuri Khan
2014-11-04 7:41 ` Jorgen Schaefer
2014-11-06 15:22 ` Dmitry Gutov
2014-11-06 16:51 ` Stefan Monnier
2014-11-06 17:00 ` Helmut Eller
2014-11-06 17:08 ` Multiple next-error sources Jorgen Schaefer
2014-11-06 23:15 ` Stefan Monnier
2014-11-07 9:49 ` Jorgen Schaefer
2014-11-07 14:59 ` Stefan Monnier
2014-11-07 15:24 ` Daniel Colascione
2014-11-07 15:55 ` Stefan Monnier
2014-11-07 16:08 ` Daniel Colascione
2014-11-07 18:17 ` Stefan Monnier
2014-11-07 18:22 ` Daniel Colascione
2014-11-07 19:06 ` Stefan Monnier
2014-11-07 15:41 ` Jorgen Schaefer
2014-11-07 16:03 ` Stefan Monnier
2014-11-07 16:55 ` Alan Mackenzie
2014-11-07 17:10 ` Daniel Colascione
2014-11-07 17:40 ` Alan Mackenzie
2014-11-08 8:55 ` Dmitry Gutov
2014-11-07 18:08 ` Stefan Monnier
2014-11-07 18:21 ` Alan Mackenzie
2014-11-07 18:48 ` Stefan Monnier
2014-11-07 19:51 ` Alan Mackenzie
2014-11-03 14:46 ` Generalizing find-definition Stephen Leake
2014-11-03 16:42 ` Stefan Monnier
2014-11-04 15:39 ` Stephen Leake
2014-11-04 18:14 ` Stefan Monnier
2014-11-17 20:10 ` Jorgen Schaefer
2014-11-18 8:07 ` Stephen Leake
2014-11-18 11:24 ` Helmut Eller
2014-11-18 12:48 ` Dmitry Gutov
2014-11-18 12:03 ` Helmut Eller
2014-11-19 14:27 ` Stefan Monnier
2014-11-19 14:51 ` Ivan Shmakov
2014-11-19 22:31 ` Stefan Monnier
2014-11-20 0:15 ` Stephen Leake
2014-11-20 4:18 ` Stefan Monnier
2014-11-18 16:31 ` Stefan Monnier
2014-11-20 0:21 ` Stephen Leake
2014-11-20 4:19 ` Stefan Monnier
2014-11-20 20:21 ` Jorgen Schaefer
2014-11-20 13:44 ` Helmut Eller
2014-11-20 20:28 ` Jorgen Schaefer
2014-11-20 20:42 ` Helmut Eller
2014-11-20 23:27 ` Stefan Monnier
2014-11-20 23:42 ` Jorgen Schaefer
2014-11-21 3:05 ` Stefan Monnier
2014-11-21 8:24 ` martin rudalics
2014-11-30 13:29 ` Stefan Monnier
2014-11-23 13:44 ` Johan Claesson
2014-12-01 17:31 ` Helmut Eller
2014-12-04 3:13 ` Stephen Leake
2014-12-04 8:07 ` Stephen Leake
2014-12-04 12:45 ` Helmut Eller
2014-12-04 9:11 ` Helmut Eller
2014-12-04 16:19 ` Stephen Leake
2014-12-04 16:49 ` Helmut Eller
2014-12-05 9:43 ` Stephen Leake
2014-12-05 13:25 ` Helmut Eller
2014-12-05 17:41 ` Stephen Leake
2014-12-06 8:55 ` Helmut Eller
2014-12-06 18:19 ` Stephen Leake
2014-12-06 18:38 ` Drew Adams
2014-12-07 16:52 ` Stephen Leake
2014-12-06 22:57 ` Stefan Monnier
2014-12-07 9:55 ` Helmut Eller
2014-12-08 14:33 ` Stefan Monnier
2014-12-08 19:58 ` Helmut Eller
2014-12-08 21:38 ` Stefan Monnier
2014-12-08 21:58 ` Jorgen Schaefer
2014-12-09 2:33 ` Stefan Monnier
2014-12-09 2:34 ` Stefan Monnier
2014-12-09 8:40 ` Helmut Eller
2014-12-09 14:03 ` Dmitry Gutov
2014-12-09 14:47 ` Helmut Eller
2014-12-11 4:06 ` Dmitry Gutov
2014-12-11 8:09 ` Helmut Eller [this message]
2014-12-11 11:12 ` Helmut Eller
2014-12-11 18:36 ` Helmut Eller
2014-12-11 19:21 ` David Engster
2014-12-11 19:36 ` Helmut Eller
2014-12-11 21:53 ` David Engster
2014-12-11 22:04 ` David Engster
2014-12-12 7:26 ` Helmut Eller
2014-12-11 22:52 ` Dmitry Gutov
2014-12-11 23:55 ` Stefan Monnier
2014-12-11 23:59 ` Dmitry Gutov
2014-12-11 15:07 ` Stefan Monnier
2014-12-11 18:43 ` Helmut Eller
2014-12-11 20:11 ` Stefan Monnier
2014-12-11 20:31 ` Helmut Eller
2014-12-11 21:33 ` Stefan Monnier
2014-12-15 17:21 ` Dmitry Gutov
2014-12-15 21:13 ` Stefan Monnier
2014-12-15 21:24 ` Dmitry Gutov
2014-12-15 21:57 ` Helmut Eller
2014-12-15 22:06 ` Dmitry Gutov
2014-12-15 22:17 ` Helmut Eller
2014-12-15 22:26 ` Dmitry Gutov
2014-12-15 22:41 ` Helmut Eller
2014-12-15 22:54 ` Dmitry Gutov
2014-12-15 23:03 ` Helmut Eller
[not found] ` <54901FEB.1090704@yandex.ru>
[not found] ` <m2k31ric89.fsf@gmail.com>
[not found] ` <5490962D.7010105@yandex.ru>
[not found] ` <m2y4q75ntx.fsf@gmail.com>
2014-12-16 21:40 ` Dmitry Gutov
2014-12-17 7:25 ` Helmut Eller
2014-12-19 8:00 ` Dmitry Gutov
2014-12-19 8:49 ` Helmut Eller
2014-12-19 14:34 ` Dmitry Gutov
2014-12-19 8:56 ` Helmut Eller
2014-12-19 13:36 ` Dmitry Gutov
2014-12-25 20:25 ` Dmitry Gutov
2014-12-26 3:50 ` Stefan Monnier
2014-12-28 22:21 ` Dmitry Gutov
2014-12-29 0:24 ` Stefan Monnier
2014-12-29 0:38 ` Dmitry Gutov
2014-12-29 1:54 ` Dmitry Gutov
2014-12-29 14:20 ` Stefan Monnier
2014-12-29 16:17 ` Eli Zaretskii
2014-12-29 17:27 ` Dmitry Gutov
2014-12-29 17:37 ` Eli Zaretskii
2014-12-29 18:56 ` Stefan Monnier
2014-12-27 19:01 ` Stephen Leake
2014-12-27 21:22 ` Stephen Leake
2014-12-12 1:29 ` Stephen Leake
2014-12-12 3:05 ` Stefan Monnier
2014-12-12 11:15 ` Stephen Leake
2014-12-12 13:58 ` Stefan Monnier
2014-12-13 9:56 ` Dmitry Gutov
2014-12-12 5:05 ` Dmitry Gutov
2014-12-10 9:11 ` Stephen Leake
2014-12-10 13:02 ` Dmitry Gutov
2014-12-10 17:00 ` Stephen Leake
2014-12-10 19:06 ` Stefan Monnier
2014-12-12 1:03 ` Stephen Leake
2014-12-10 14:10 ` Stefan Monnier
2014-12-11 4:08 ` Dmitry Gutov
2014-12-08 22:36 ` Stephen Leake
2014-11-02 22:26 ` Stephen Leake
2014-11-03 7:31 ` Jorgen Schaefer
2014-11-03 8:13 ` Helmut Eller
2014-11-03 13:49 ` Stephen Leake
2014-11-03 17:58 ` Jorgen Schaefer
2014-11-04 15:54 ` Stephen Leake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m21to6ehf4.fsf@gmail.com \
--to=eller.helmut@gmail.com \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.