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: Tue, 4 Nov 2014 08:58:09 +0100 Message-ID: <20141104085809.4c13fdbf@forcix> References: <20141102151524.0d9c665c@forcix> <20141102172944.0f7944e3@forcix> <20141103084433.12117c03@forcix> <20141103192853.2702fe7a@forcix> <20141103215526.28edeb27@forcix> <87r3xjzw2u.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1415087914 29287 80.91.229.3 (4 Nov 2014 07:58:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2014 07:58:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 04 08:58: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 1XlZ0T-0007QE-UO for ged-emacs-devel@m.gmane.org; Tue, 04 Nov 2014 08:58:26 +0100 Original-Received: from localhost ([::1]:39033 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlZ0T-0006rt-LI for ged-emacs-devel@m.gmane.org; Tue, 04 Nov 2014 02:58:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlZ0L-0006qx-PY for emacs-devel@gnu.org; Tue, 04 Nov 2014 02:58:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlZ0F-0001qC-SS for emacs-devel@gnu.org; Tue, 04 Nov 2014 02:58:17 -0500 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:47268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlZ0F-0001q6-Lp for emacs-devel@gnu.org; Tue, 04 Nov 2014 02:58:11 -0500 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id AA8FB2045AD; Tue, 4 Nov 2014 08:58:10 +0100 (CET) Original-Received: from forcix (port-12461.pppoe.wtnet.de [84.46.48.221]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id DD5A42045A9; Tue, 4 Nov 2014 08:58:09 +0100 (CET) In-Reply-To: <87r3xjzw2u.fsf@uwakimon.sk.tsukuba.ac.jp> 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:176337 Archived-At: On Tue, 04 Nov 2014 08:46:33 +0900 "Stephen J. Turnbull" wrote: > Jorgen Schaefer writes: > > > 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. > > Why not? The "foo.Foo.baz" in this example would be an error at that point in the program, and not all things that are defined have such a fully qualified name in the first place. This all seems a bit counter-intuitive for something called "identifier at point". > Emacs's practical definition of "identifier at point" > doesn't need to be the same as that of the programming language's > grammar. I have no trouble taking both points of view, although > usually at different times. I have no problem with that, either - we can call it Frobble, Blubber or Moof, too, if we like. We use words so others understand us, and redefining them more or less randomly is not helping with communication. We have gone full circle and instead of asking "can an 'identifier at point' be used to find the definition of the thing at point", we have defined "identifier at point" to mean "that string (or object?) which can be used to find the definition of the thing at point". Now that is fine, mind you, we can use language however we like, but we will cause quite some confusion with that. For example, some people might think "oh hey, I have a function that returns an identifier at point, and I am supposed to be able to pass that string to the other function which returns the definitions of that identifier. Let's write a function which receives an identifier and returns where it is used." But the way we defined "identifier at point", that does not necessarily allow that. Confusion all around just because we went for re-defining a term that is usually used in other ways. > In some sense, you always need full buffer contents except for the > very simplest of programs. Exactly. Which is why I'm saying that I do not see the need or use for an indirection via a "get identifier at point" function for the proposed library. Which is pretty much all I was trying to say up to the semantics discussion on the number of ways we can define what "identifier at point" could possibly mean. So let's drop that idea and the semantics discussion. Regards, Jorgen