From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Thu, 11 Dec 2014 09:09:51 +0100 Message-ID: References: <20141102151524.0d9c665c@forcix> <877fymghgb.fsf@bredband.net> <85ppc0qf9a.fsf@stephe-leake.org> <85zjb3o09d.fsf@stephe-leake.org> <85tx1amnyg.fsf@stephe-leake.org> <85egsem1u2.fsf@stephe-leake.org> <867fy0or7p.fsf@yandex.ru> <86ppbqn841.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418285433 25029 80.91.229.3 (11 Dec 2014 08:10:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2014 08:10:33 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 11 09:10:26 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XyypO-00015s-4Q for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 09:10:26 +0100 Original-Received: from localhost ([::1]:49712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyypN-0002hC-JA for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 03:10:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xyyp2-0002dY-Jr for emacs-devel@gnu.org; Thu, 11 Dec 2014 03:10:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xyyot-00078P-I7 for emacs-devel@gnu.org; Thu, 11 Dec 2014 03:10:04 -0500 Original-Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:39758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xyyot-00077H-77 for emacs-devel@gnu.org; Thu, 11 Dec 2014 03:09:55 -0500 Original-Received: by mail-wi0-f181.google.com with SMTP id r20so7739370wiv.2 for ; Thu, 11 Dec 2014 00:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=NTwBNhH0AaG83MVCSd4cf5zC3cFkX2yVAgxrpLc2d8U=; b=P3sv99RwUyIfyL+QaVX24hhy8KopRm+o7vwsybJtw5QcXess9hDJI/w1o8XATiruM/ VwQ/udz5vihrkVzbdm2ivJQGPLyZt+hgJLyq8DNRosSTRLtYnZDfv/DPaZ/DJddTOYK0 eAZxlQOLqQhFTkqe5X5XQfR32Ngajfnddp80vojW4q1Fl9lzDjyq2PzViXXEzLl9yV/H js/CRpAGrgnNY9JSkLunOMak6JXaTWPikaAX6W2DlTMFKIJV6vgR6UHJrAxfQdDecZqq 9KXZYzAItV9of46oZrwIEF9Zrs4ymH1LC2/DqS03nMecj1zjR4e7sqC5PQnTGGTvYOCt FFwQ== X-Received: by 10.194.108.202 with SMTP id hm10mr5033005wjb.72.1418285394689; Thu, 11 Dec 2014 00:09:54 -0800 (PST) Original-Received: from ix ([212.46.172.140]) by mx.google.com with ESMTPSA id ly9sm650245wjb.24.2014.12.11.00.09.53 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 11 Dec 2014 00:09:53 -0800 (PST) Original-Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Xyyop-0000uk-KH; Thu, 11 Dec 2014 09:09:52 +0100 In-Reply-To: <86ppbqn841.fsf@yandex.ru> (Dmitry Gutov's message of "Thu, 11 Dec 2014 06:06:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179724 Archived-At: 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