From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.devel Subject: Re: Generalizing find-definition Date: Mon, 3 Nov 2014 21:55:26 +0100 Message-ID: <20141103215526.28edeb27@forcix> References: <20141102151524.0d9c665c@forcix> <20141102172944.0f7944e3@forcix> <20141103084433.12117c03@forcix> <20141103192853.2702fe7a@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1415048153 2470 80.91.229.3 (3 Nov 2014 20:55:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2014 20:55:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 03 21:55:46 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 1XlOfC-000764-3H for ged-emacs-devel@m.gmane.org; Mon, 03 Nov 2014 21:55:46 +0100 Original-Received: from localhost ([::1]:37313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlOfB-0003i8-Os for ged-emacs-devel@m.gmane.org; Mon, 03 Nov 2014 15:55:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlOf3-0003fF-7S for emacs-devel@gnu.org; Mon, 03 Nov 2014 15:55:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlOex-0001jd-2o for emacs-devel@gnu.org; Mon, 03 Nov 2014 15:55:36 -0500 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:51977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlOew-0001jR-Qb for emacs-devel@gnu.org; Mon, 03 Nov 2014 15:55:30 -0500 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id 463592045AD; Mon, 3 Nov 2014 21:55:29 +0100 (CET) Original-Received: from forcix (port-4853.pppoe.wtnet.de [84.46.19.8]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id 5152E2045A9; Mon, 3 Nov 2014 21:55:28 +0100 (CET) In-Reply-To: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; i586-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.230.15.51 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:176315 Archived-At: On Mon, 03 Nov 2014 15:09:40 -0500 Stefan Monnier wrote: > > 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". The tab completion I talked about is for global modules and their contents and has no access to locally-available identifiers. It is a feature completely unrelated to finding the definition of the 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? I suspect we mean the same thing, but just to clarify. Consider a piece of code like this: from foo import Foo bar = Foo() bar.baz_|_ M-. should go to the definition of the attribute baz of the class Foo. But the obvious "identifier at point" is "bar.baz", which by itself does not have any relationship to said method without the assignment "bar = Foo()", which by itself is also not meaningful without the import statement. The only single string that reliably would allow to find the correct definition would be "foo.Foo.baz", but I do not think that anyone would consider that to be "the identifier at point" here. So what I am saying is that the only representation for "the identifier at point" that allows finding the definition of said identifier is the triple (file name, full buffer contents, position within the buffer contents). There is no simpler "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. Emacs can and probably should standardize it, but unless it is useful for the interface of finding the definition of the thing at point, it would seem like a good idea not to do it in the library being discussed here. > 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). What is the advantage of having the backend define a function that returns a completion table as opposed to a function that prompts the user for a symbol? The saved code seems minimal, and it means the backend can not set the prompt, for example. Regards, Jorgen