From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Thu, 27 Feb 2014 02:11:56 +0900 Message-ID: <878usxu7c3.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <87y50z90pd.fsf@fencepost.gnu.org> <87txbn8r6x.fsf@fencepost.gnu.org> <87r46qtn8b.fsf@uwakimon.sk.tsukuba.ac.jp> <87eh2q74b4.fsf@fencepost.gnu.org> <87lhwytabr.fsf@uwakimon.sk.tsukuba.ac.jp> <8738j66rmz.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1393434740 3180 80.91.229.3 (26 Feb 2014 17:12:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2014 17:12:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 26 18:12:28 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 1WIi1z-0008Bl-7A for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 18:12:27 +0100 Original-Received: from localhost ([::1]:41931 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIi1y-0004zy-Oh for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 12:12:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIi1n-0004xa-P9 for emacs-devel@gnu.org; Wed, 26 Feb 2014 12:12:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIi1f-0006O4-8M for emacs-devel@gnu.org; Wed, 26 Feb 2014 12:12:15 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:40693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIi1W-00066h-QC; Wed, 26 Feb 2014 12:11:59 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3B613970A40; Thu, 27 Feb 2014 02:11:56 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 27F631A28E5; Thu, 27 Feb 2014 02:11:56 +0900 (JST) In-Reply-To: <8738j66rmz.fsf@fencepost.gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:169888 Archived-At: David Kastrup writes: > Really, I addressed this _exhaustively_ in Hardly. You have a hypothetical data structure containing an unspecified set of information much of which is known to be available in the AST, and unsubstantiated claims that "most" of the AST information isn't needed. For example: > But a full syntax tree is not required. I repeat: > > [...] so the basic question that likely needs solving is "given the > following source location and the following identifier, what data > structures and definitions does it refer to". Resolving identifiers > based on source location efficiently will require suitable data > structures, and any daemon answering questions accordingly will have > to get raw data for building them. "Likely." "Suitable." "Get raw data." In other words, you have no idea whether a full syntax tree is required or not. All you know is that if and when you get a spec for the data and a design for the daemon, the rest will be a SMOP. Thanks! But, well, I already knew that, that's just how programming works. > At any rate, this is hypothetical, while it would appear that > -fdump-xref isn't. There seems to be little point in fighting a lot > over it without actually looking what -fdump-xref actually does. OK.